Talk:Log-structured file system

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

Roll-backward vs. Roll-forward

OK, so why does an LSFS (Log-Structured File System) do roll-forward instead of roll-back? I'll try to explain it, it's actually very simple. An LSFS works by creating checkpoints. I.e. it writes to the disk from the beginning to the end, in a linear fashion. Every X seconds, or every Y blocks written, it flushes all buffers to disk and creates a checkpoint. This checkpoint contains updated references to all on-disk structures (directory entries etc.) that have been written in the last X seconds (or Y blocks).

So, immmediately after creating this checkpoint, the on-disk structure is consistent and clean. This is marked in the superblock (or somewhere else), by setting a "pointer" to this newly created checkpoint.

But now, as new data is written to the disk, some of the consistent structures are superceeded by new blocks (e.g. new directory entries are created, which invalidate the references stored in the checkpoint - remember that an LSFS can't simply change the already-written blocks, it has to append the updated data at the end). Now, imagine the system crashes and needs to recover on the next boot.

All it has to do is to take the "pointer" stored in the superblock, and look at the checkpoint there. All data written "before" this checkpoint is now immediately "recovered". Now, the fsck program walks over the blocks which come _after_ the checkpoint, to see if there is any updated data. And there it finds all new and invalidated structures, which can then be integrated into the consistent data of the last checkpoint.

So, the direction the fsck program takes when scanning for "lost" writes, is forward from the last checkpoint on.

For those who want to know more, take a look at "The Design and Implementation of a Log-Structured File System", by M. Rosenblum and J.K. Ousterhout from 1991, which is available here. It's already referenced in the main article, the crash recovery is described in chapter 4. --Michael Drüing

Thank you for this clear explanation! --Doc aberdeen 04:53, 28 October 2006 (UTC)[reply]

Currently the article links to this explanation on the talk page. Articles aren't supposed to link to talk pages. If this explanation is an important part of the content, it should be put in the article. Otherwise, the link to it should be removed. Jibjibjib 02:19, 2 January 2007 (UTC)[reply]

You took the words right out of my mouth. Roll-forward deserves it's own article with the above description included. I'm busy now but I'll do it later if no one else does. Robert Brockway 16:25, 5 February 2007 (UTC)[reply]

ZFS is not a log-structured file system

The article claims that ZFS is a log-structured filesystem. I dispute that. ZFS is a Copy-on-Write FS, without logging except in the ZIL area (to efficiently manage synchronous writes).

If nobody disagree, I will delete that section in a few days. Jcea 18:07, 21 March 2007 (UTC)[reply]

Well I'm in 2 minds. I've referred to is as a LSF for sometime and have heard Sun engineers use the same terminology. Having said this you may well be right. I'd prefer to see a reference (from Sun?) which clearly supports one position or the other. Robert Brockway 06:42, 2 April 2007 (UTC)[reply]

fixed broken Links

in reference, the earlier page was referencing links from www.hhh.org can which seems to be broken or were wrongly added as an act of vandalism(?) Armybrat 15:03, 11 July 2007 (UTC)[reply]

BTRFS?

Isn't BTRFS a log-structured file-system as well? Tzafrir (talk) 11:46, 21 April 2009 (UTC)[reply]