On Tue, Nov 21, 2006 at 10:38:45AM -0500, Douglas Tutty wrote: > On Mon, Nov 20, 2006 at 09:52:26PM -0500, [EMAIL PROTECTED] wrote: > > On Mon, Nov 20, 2006 at 06:43:06PM -0500, Johan Kullstam wrote: > > > > >From what I hear, reiserfs and ext3 are both reasonably protected > > against panic reboots -- the hard drives will have written or not > > written the journal, and remounting the file system will figure out what > > happened. What they have a hard time with is panic powerdowns -- > > because of the behaviour of some IDE drives -- apparently they report > > data transfer complete when they have merely buffered it internally, > > expecting it to be written real soon now. If the power fails before > > this happens, the file system will assume data have been written which > > in fact have not been written, and this could caouse journal failure. > > > > > ext2, I'm told, has just enough extra redundancy that is is possible to > > make a reasonable guess as th owhat's wrong by an fsck. rumour has it > > that reiser, which stored data in a tree structure that's somewhat > > independent of the file-system structure, is more vulnerable to problens > > like confusing data with file-system structure. > > > > I don't know what the situatin is with JFS. Anybody know? > > > > All I know is what I've experienced and what I have taken on faith: > > Reiserfs looses files on panic powerdowns (power failure) even if the > filesystem structure survives. Reiserfsck doesn't fix this. This, for > me, has been small files (unfortunaly, typically those in /etc) even > though they weren't being written at the time of the power failure.
That sounds right. > > IBM says they designed JFS to allow a server to get back to work quickly > after a power failure, which includes fixing problems so that it __can__ > work. I have enough experience with IBM to trust that when they design > something to put their name on it (and use it in AIX) that it will do > what they say it will do. The hard part of this is, of course, to deal with disk drives that lie about whether they have written. I have respect for IBM too. When a third-party developer decided to rely on IBM's specs for OS/2's high-performance file system to write a disk optimiser/defragmenter or some such, they build partitions with the file system root in a valid-according-to-spec place that was different from the place IBM had been putting it. OS/2 had troubel reading these partitions. IBM fixed their HPFS implementation so that it would work to spec. A similar story with Microsoft: When an independently written-to-spec utility failed to handle NTFS properly, Bill Gates is reported to have said, "Looks kike they haven't figured out all the intricacies of our file system yet." > > I tried to stress-test JFS by __moving__ directories from one drive to > another and one partition to another and cutting the power in the > middle. The move would only be partially complete but no files were > lost; they either existed on one drive or the other, nothing got lost in > limbo. That sounds competent. > > Until I got my new Athlon system, I have always used old/slow hardware. > Looking at the benchmark comparisions, reiserfs may be faster with small > files because it embeds them in the directory structure but to do that > it needs a lot more CPU overhead. So on my hardware, JFS has been > faster than reiserfs. > > So I use JFS for everything. > > Doug. I'm at the point of replacing one of my reiserfs's on an NFS server with something else for reliability. (reliability is the *primary* criterion for this server, by the way. I'd happily give up some speed for reliability) I was going to go to ext3 because of its venerable age. Now you hae me wondering about JFS. DO you have any more relevant facts? or links to facts? -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
