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

Re: [leafnode-list] "cannot obtain group list" error running



William Grinolds schrieb am Mittwoch, den 11. September 2002:

> >That depends. If you lose files through file system corruption, it
> >depends on how smart your fsck program is. With modern Linux file
> >systems (ext3fs, patched reiserfs) with data=ordered or data=journal,
> or
> >with BSD softupdates or non-async ffs, such things should never happen
> >except for power failures that happen while the hard disk has its write
> >cache switched on -- most ship this way though :-(
> 
> I'm not sure exactly what all that means - the partition is a simple
> ext2fs partition, not sure what data=ordered or data=journal means.  I
> also use e2fsprogs-1.27, which comes with Slackware 8.1/9.0 beta, so
> it's fairly up-to-date.

With ext2fs, all this does not apply, ext2fs cannot make any guarantees
what happens when your computer crashes (power loss, kernel bug lets it
freeze, hardware trouble of your TV card, you name it).

data=ordered and data=journal are mount options, available with ext3fs
as of recent Linux-2.4 kernels, and also available with reiserfs when
using Chris Mason's patches (that are distributed separately, not sure
if they will go into Linux' 2.4.20 or 2.4.21 kernel versions, if at
all).

These options can improve data integrity on your file system (provided
that either your hard disk does not do caching[*]) by putting disk block
writes into a certain order. ext2fs will write real file data or
administration data in any order it likes, which makes it possible for
file data to be written before the file name, which then makes the file
show up in lost+found if the machine crashes too soon. This is avoided
with data=ordered or data=journal. These options come at a cost though:
they can adversely affect the drive's speed. They can also improve it
for other application profiles. It depends. I like it because it
avoid a certain amount of file system corruption.

[*] That's simplified. With "write barrier" support, the kernel can
still use the write cache without risking data loss from the
application's point of view. I cannot go into too much detail here,
that's beyond the scope of the list. At any rate, switching the write
cache of the drive off is the safe approach, but it can cause your disk
writes to be only half as fast as before.

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list