On Mon, 3 Dec 2001, Karl J. Runge wrote: > If you are running ext3 (or xfs) on a, say, 20GB partition, and you pull > the power plug out and then back in, how much longer is the boot process > over that of a clean boot?
Longer? It should be *much* shorter. To understand what a journaling filesystem gets you, you have to understand how things work without a journaling filesystem. You will also need to understand what metadata is. So what is metadata? Basically, the on-disk organization of files and directories. Metadata is the information that says things like "Directory 'a' contains file 'b', which is located at location 'c' on disk", and so on. If the metadata gets corrupted, all your data may still be there, but you will not be able to access it. One easy way for the metadata to get corrupted is if a system crash occurs during a disk write. The system may be half-way though re-writing a directory, for example. The second half will never be written to disk, and the entries in that directory lost. This is why the system runs "fsck" automatically at reboot after a crash -- the filesystem may be in an inconsistent state, and the system needs to run though the whole thing to make sure everything is sane. Enter journaling filesystems. Say you do something (like append to a file) which requires an update to the filesystem metadata. Here is the sequence of events with a journaling filesystem: 1. The transaction is started by a user program 2. The transaction is written to the journal 3. The transaction is written to the filesystem itself 4. The journal is checkpointed to indicate the transaction is complete If the system crashes before the transaction is committed to the journal, the system can discard the changes upon reboot. If the transaction is committed to the journal, but not the filesystem, the system can "replay" the journal to finish the transaction. Since the system is always sure of the state of the filesystem, the usual after-crash "fsck" can be skipped. Since, on a multi-hundred-gigabyte filesystem, "fsck" can takes *several hours* to run, this is a huge win. Note that many of the journaling filesystems available for Linux also have other features to increase performance and availability, and those features generally exist independently of journaling. > Also, suppose, as an expt, I was untarring a big 100MB tarball when I > pulled the plug. Any notable plusses over the state of the file system > after reboot vs. the same expt done on ext2 (and after ext2's fsck)? There is less of a chance of logical corruption of the filesystem metadata. Some filesystems also journal userdata, in addition to metadata. I know ext3 can. I know ReiserFS cannot. I am not sure about XFS. What does journaling userdata get you? Well, with ReiserFS, for example, after a crash, you may find the contents of any file being written to when the crash occurred are corrupted. This is because only the filesystem itself, and not the data in the files, is protected by the journal. ext3 with userdata journaling, on the other hand, should preserve the file in its last sync'ed state. Of course, if the system crashed while a file was being written to, the file is likely to be corrupt anyway, so there is some question as to how useful this actually is. :-) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
