bmouring
Distinguished
- May 6, 2006
- 1,215
- 0
- 19,360
Nono, I just know that some people don't really care to know too much about this kinda stuff (they want it to "Just Work TM").
Basically, as the filesystem portion of the kernel is working with files, quite often all this is happening in system memory and not the actual disk (as you probably know). When this data does get flushed to the disk, if some of the structural data of the filesystem is only partially written to the on-disk structures it can lead to broken structures (corrupted data, bad pointers, you get the idea). The idea of a journal is to write down an atomic group of actions to dispatch (or a cache flush).
The order follows as such:
1) Write the actions to a journal
2) Upon completion of the jounal dispatch unit, mark it as completely written to the journal
3) Begin modifying the actual on-disk structures
4) Upon completing, mark the dispatch unit in the journal as completely written to disk
5) Begin loading new unit to flush.
If the system crashes before 1) All data is lost and the jounal record isn't valid (since there's nothing in it) (XFS caches a lot of data, as such in the even of a crash that's why a lot of data is lost). A little data loss but life is good.
If it crashes between 1) and 2), there's actions to perform in the journal but it hasn't been marked as "good", so it could lead to an inconsistent system (think of first moving a file chunk and then updating the pointer to it, if it crashes between those steps you are now missing data) and as such, the journal is ignored. Life is good.
If a crash happens between 2) and 3), we have a good journal but nothing's taken place on the actual disk. On restart, the actions listed in the journal are replayed and the journal is marked "completely written to disk". Life is good.
If a crash occurs between 3) and 4), we have partially updated the on-disk structures but not completely. As such, like above, the entire journal is replayed. Some file data might be lost, but the filesystem is coherent. Life is again good.
If a crash occurs between 4) and 5), on next boot the filesystem portion of the kernel sees that the last transaction was complete, even if the filesystem itself is marked "dirty" (when unmounting a filesystem, it is marked "clean" to let the kernel know that a check is not necessary). The replay is skipped (as there is nothing to replay) and life is good.
Now, some really cools stuff is the so-called log filesystems, they use this same concept but with the entire filesystem instead of just the metadata of the filesystem. Updates to file data result in moving the data as a whole and the log keeps track of the location of the file contents as they move around. As you can probably imagine, since old data isn't initially overwritten (it is later by a "garbage collector" of sorts), it allows for trivial implimentation of filesystem-wide versioning.
As boring as it might seem to some, as you could probably tell, I think filesystems are pretty damn cool.
Basically, as the filesystem portion of the kernel is working with files, quite often all this is happening in system memory and not the actual disk (as you probably know). When this data does get flushed to the disk, if some of the structural data of the filesystem is only partially written to the on-disk structures it can lead to broken structures (corrupted data, bad pointers, you get the idea). The idea of a journal is to write down an atomic group of actions to dispatch (or a cache flush).
The order follows as such:
1) Write the actions to a journal
2) Upon completion of the jounal dispatch unit, mark it as completely written to the journal
3) Begin modifying the actual on-disk structures
4) Upon completing, mark the dispatch unit in the journal as completely written to disk
5) Begin loading new unit to flush.
If the system crashes before 1) All data is lost and the jounal record isn't valid (since there's nothing in it) (XFS caches a lot of data, as such in the even of a crash that's why a lot of data is lost). A little data loss but life is good.
If it crashes between 1) and 2), there's actions to perform in the journal but it hasn't been marked as "good", so it could lead to an inconsistent system (think of first moving a file chunk and then updating the pointer to it, if it crashes between those steps you are now missing data) and as such, the journal is ignored. Life is good.
If a crash happens between 2) and 3), we have a good journal but nothing's taken place on the actual disk. On restart, the actions listed in the journal are replayed and the journal is marked "completely written to disk". Life is good.
If a crash occurs between 3) and 4), we have partially updated the on-disk structures but not completely. As such, like above, the entire journal is replayed. Some file data might be lost, but the filesystem is coherent. Life is again good.
If a crash occurs between 4) and 5), on next boot the filesystem portion of the kernel sees that the last transaction was complete, even if the filesystem itself is marked "dirty" (when unmounting a filesystem, it is marked "clean" to let the kernel know that a check is not necessary). The replay is skipped (as there is nothing to replay) and life is good.
Now, some really cools stuff is the so-called log filesystems, they use this same concept but with the entire filesystem instead of just the metadata of the filesystem. Updates to file data result in moving the data as a whole and the log keeps track of the location of the file contents as they move around. As you can probably imagine, since old data isn't initially overwritten (it is later by a "garbage collector" of sorts), it allows for trivial implimentation of filesystem-wide versioning.
As boring as it might seem to some, as you could probably tell, I think filesystems are pretty damn cool.
Facebook
Twitter
Instagram