--- Saifi <[EMAIL PROTECTED]> wrote: > Hi Narender: > > That was a great overview of ext3fs as I had no idea about how ext3fs works. > > I am still keen to know, what is the difference between "ordered" and > "writeback" ? > > May be Namita can help us out here. > > thanks > Saifi. > >
Hi, When something changes on a file system, it may require changes to data and metadata. There could be multiple metadata changes for a single file system change. Eg. If a file is deleted, then the occupied data blocks must be marked as unallocated, file inode information must be removed from inode table, directory information must be updated etc. One challenge that FS writers face is to make sure that an irrecoverable damage is not done to the FS if a system crash occurs, as these changes are made. Using our example above: If data block is marked as reusable/unallocated and then crash occurs. Now the inode still exists and points to the data block. But since the data block is marked unallocated it will be reused and some other data will soon be written on it. This will render the FS inconsistent. How to solve this problem ? There are many ways of doing this, but for this email thread, we will only consider ordering and journaling. And talk a little about writeback too. Ordering: The metadata and data writes are ordered in such a way that either inconsitency does not take place or it is managed (which means FS can recover at reboot by running fsck - file system check) Using our example above: The order in which we make the change to FS is : First, modify directory information, then remove inode from allocation table, then make data blocks available. This way if there is a crash in between the changes, fsck can identify that there was an inconsistency between directory and inode table information and rectify the problem. If crash occured after directory and inode information is changed then there would be orphan allocated blocks which would be returned to the available/unallocated/reusable list. Journaling: Using the above approach would mean that if there is a system crash, fsck would need to check all metadata for all files and directories to make sure that no inconsistencies are present. For a large partition (eg 80GB), this is time consuming. One approach to solving this problem is journaling. Journaling means writing all metadata changes to a log instead of actually doing it. At regular intervals the metadata changes mentioned in the logs is actually made. Once it is made that point in the log/journal is marked as the consistent/commit point. The next time the 'log is run' (changes mentioned in the log are actually made), only those changes which are after the commit point are made and a new commit point is marked. So if a system crashes, fsck just needs to make all the changes mentioned in the log after the last commit point. This reduces recovery time drastically. Note that in journaling filesystems only metadata changes are logged / journaled. Data changes are written immediately. (There exist log structured filesstems where data changes are also logged). When we say that data changes are written immediately, they may either be written to the disk or may be written to filesystem buffers (in memory). These buffers are kept in memory for faster access and are synced to the disk at regular intervals. As you might have guessed, if a crash occurs before it is synced we have inconsistent data - which is what happens if you choose the 'writeback' option. However when you choose the 'ordered' option, the data is synced to the disk when we run the logs and mark the commit point (i.e. data is written on disk when the metadata changes are actually made). Given the above explanation, please re-read Narendar's mail. It will now make more sense. Hope this helps, Namita
