Re: IIs factible to implement full writes of strips to raid using NVRAM memory in LFS?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Aug 18, 2016 at 07:00:02PM +0000, Eduardo Horvath wrote:
 > > > And you should be able to roll back the 
 > > > filesystem to snapshots of any earlier synchronization points.
 > > 
 > > In LFS there are only two snapshots and in practice often one of
 > > them's not valid (because it was halfway through being taken when the
 > > machine went down) so rolling further back isn't that feasible.
 > 
 > I don't remember seeing any code that overwrites old snapshots, so most of 
 > them are still on disk.  It's just a question of finding them, which is 
 > where the first and last superblock come into play.

Ok, partly I was mixing things up with the Sprite LFS, which has two
largish checkpoint areas it alternates between.

In BSD LFS the checkpoint space is small and in the superblock, but as
noted it still only uses two of them to checkpoint into. So I'm not
sure what you mean by old snapshots.

 > > > o Although there are multiple super blocks scattered across the
 > > >   disk just like FFS, LFS only uses the first and last one.  If
 > > >   both of those are corrupt, the filesystem image cannot be
 > > >   recovered.  LFS should be enhanced to cycle through all the
 > > >   different super blocks for enhanced robustness.
 > >
 > > This should be left to fsck, like it is in ffs. I don't remember if
 > > fsck_lfs supports recovering from an alternate superblock, but it
 > > isn't going to be that hard.
 > 
 > The LFS super block contains a pointer to the end of the log.  Since LFS 
 > only ever updates that pointer on the firt and last superblock, if you try 
 > to use any other superblock to recover the filesystem you essentially roll 
 > it back to just after the newfs_lfs ran.

Only if you robotically march off the cliff. Like in FFS, if you have
a superblock (any of them) that tells you critical things about how
the FS is laid out. That tells you where the segments are, and that
lets you identify the segment headers.

Once you have that you can reassemble the rest. The segment headers
contain enough information to rebuild the checkpoint data. The
critical thing is to be able to detect and ignore a segment that was
only half written, but the design provides for that. (And also to not
accidentally process a stale segment header left on disk after a
newfs, but perseant fixed that.)

I don't know if the fsck_lfs we have can do this, though.

-- 
David A. Holland
dholland%netbsd.org@localhost