On Sun, 2008-07-06 at 22:30 +0100, Peter Grandi wrote: > > JFS doesn't journal data, just metadata, so if the > > configuration file was very recently created, its metadata > > could be intact, but the file data may have been lost, > > exposing whatever data was in the data blocks previously. > > >> Now I'm wondering: When the computer just crashes, is it ok > >> for jfs to call the fs "clean" on the next reboot? > > > After it replays the journal, it will assume the file system > > is clean, as long as no errors were seen. > > To make this more obvious: "clean" means that the *metadata* is > believed to be clean. The JFS code manages the integrity of the > metadata, the persistence of the data is the responsibility of > the applications (see below). > > [ ... ] > > > The data itself isn't journaled, so newly created files may > > have random data after a crash. > > That's not quite right, as who writes this knows but is perhaps > too tired to add: newly created files that haven't been properly > committed by the application that created them may have random > data.
It's possible that the application can do everything right, and a system crash can still result in the metadata being committed before the data is written to disk. > >> Is there any chance to prevent such thing to happen? > > > Currrently no. > > Well, that's incomplete as you know. Yeah. Lazy answer. That's what happens when I try to answer email during the weekend when I'm not really thinking. > There are at least three > ways to minimize or avoid that: > > * Mount the filesystem with '-o sync'. This will not be good > for performance though. > > * Increase the frequency with which the system page cache > flusher runs. This will not always avoid the problem, but > the performance impact will be lower. > > * Use POSIX/UNIX/Linux API functions like 'fsync' or 'fdatasync' > to explicitly commit data. This is the right way because if > the application does not use this, the OS will not guarantee > when data or metadata is saved to disk, which can have both > persistence and performance issues. This may not completely solve the problem. A system crash can occur between the time the data is written and the call to fsync completes. In some cases, updating a file by making a copy, fsync'ing the copy, then renaming the copy to to original name can be completely safe. > The bigger issue is the vast number of people who ignore the > persistence model of the POSIX/UNIX/Linux APIs and think that it > is the job of the filesystem to ensure persistence of their data > at any one time, somehow clairvoyantly figuring out when to > commit that data. > > Telling these guys that the issue really is the lack of > something like "data=ordered" and not their lack of basic > understanding of how file system IO is supposed to work just > perpetuates that issue. > > > jfs doesn't support the data=ordered mode that ext3 and some > > other file systems support. This would ensure that data is > > written before metadata is committed. > > It's not just 'data=ordered', but also and more importantly > perhaps the 'commit=N' option of 'ext3' that works around buggy > application that don't issue explicit commits with 'fsync' or > 'fdatasync'. I might have over-emphasized the need for data=ordered in jfs, but I do believe it is a feature that should be added. This used to be the default (and only) behavior of jfs back on AIX, OS/2, and even the 2.4 linux kernel. A long time ago it caused a deadlock, and I took the easy way out an "temporarily" changed to behavior on the 2.6 (or was it 2.5) kernel. Probably about time I looked at it again. I also feel that people reporting problems such as this don't always have the ability to fix the applications they are running, so saying that the application is at fault isn't necessarily helpful. Thanks for answering the questions more completely. Shaggy -- David Kleikamp IBM Linux Technology Center ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
