> 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. >> Is there any chance to prevent such thing to happen? > Currrently no. Well, that's incomplete as you know. 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. 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'. ------------------------------------------------------------------------- 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
