[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: implementation of package pools



erayo@cs.bilkent.edu.tr (Eray Ozkural)  wrote on 21.10.00 in <39F0F1B3.90B0F9C8@cs.bilkent.edu.tr>:

> What can a human do about massive filesystem corruption?

Repair it. I've done that several times so far, you know. Including  
repairing a Netware server that had no backups after a harware failure  
(bad SCSI cable) flattened the partition tables *and* maybe half the  
directories, without ever having seen a Netware filesystem before, with no  
other tool than a disk editor and a VREPAIR that wanted to delete anything  
that wasn't perfect, and in the end losing less than 0.01% of the  
contents. Took me a very long day.

> Do you go and review every i-node manually?

Something like that, yes. Or you build customised software to do parts of  
it, after you have figured out what you need for the particular desaster  
at hand. I once wrote a C program to locate ext2 partitions after the OS/2  
fdisk corrupted the partition table.

> you can do that when your specification is complete. the stuff we're
> talking about doesn't seem to require any theorem prover.

Ha.

> > Try this, design a B-Tree structure that stores a set of words. The
> > underlying hardware you are running on destroys 0.001% of all your
> > 'pointers' in an unpredicable way. Design an algorithim to operate 100%
> > correctly and a seperate one to operate 99% correctly, but allow a human
> > to fix the tree structure if necessary. Which is longer? Which is slower?
> > If you could use another datastructure besides a B-Tree could you get 100%
> > reliability? (perhaps one that did not use 'pointers')
>
> use redundant data and error correcting codes, that will do it. a

You don't seem to understand the theory behind error correcting codes:  
they *don't* get you 100%. *Nothing* gets you 100%.

> B-Tree implementation may have has such concerns. I'm not very interested in
> file organization, though.

I see.

> ext2 isn't a good filesystem. and linux isn't a good kernel. the fact

Well, they sure beat the alternatives I've actually seen in action, free  
and commercial alike. Not always in all respects, but always in the bottom  
line by a very solid margin.

Improvement is always possible, of course.

MfG Kai



Reply to: