On Fri, Jan 07, 2005 at 02:26:03PM -0600, Dave Kleikamp wrote: > On Fri, 2005-01-07 at 13:49 -0600, John Goerzen wrote: > > > I'm not sure how I would address this in jfs. I don't know about ext3, > > > > Well, in ext3 one has some options (mount(8) quoted below). When I > > mount it data=ordered, things seem fine. General wisdom holds that this > > is the preferred way to go. It sounds like JFS is approximating > > data-journal. > > Actually, jfs does the equivalent of data=writeback. In the 2.4 kernel, > it does the equivalent of data=ordered, but I changed the behavior do > avoid a deadlock in 2.6 which I never found the correct fix for.
You might consider this one vote for the data=ordered behavior. This is probably why I haven't noticed this problem from ext3 filesystems. > The data=ordered behavior would prevent random data from showing up in a > file, but it would not prevent the blocks of NULLs that you reported (if > these are really file holes as I suspect). These would be caused when a > file written non-sequentially was committed before it was completely > written to. I believe -- but can't prove at the moment -- that these files would have been written to sequentially. In any case, if the file was written to non-sequentially, couldn't you resort to the old data in the file instead of the NULLs? And if you mean a sparse file -- where the program seeks past the end, then writes -- the NULLs do seem to be the proper behavior there. > I'll have to look again at implementing the data=ordered behavior. That would be great, thanks! I wonder -- does anyone know what the other journaling filesystems (XFS, Reiser3/4, etc.) are doing? FWIW, the original reason I switched to JFS was because Reiser was doing this same thing, just much worse :-) -- John _______________________________________________ Jfs-discussion mailing list [email protected] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
