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

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Thu, 18 Aug 2016, David Holland wrote:

> some quibbles:
> 
> On Thu, Aug 18, 2016 at 05:24:53PM +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.

>  > The problem is that LFS is less a product than a research project:
>  > 
>  > 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.

> 
>  > o The rollback code is quite sketchy.  It doesn't really work so well, so 
>  > LFS has problems recovering from failures.  
> 
> Rolling *back* to the last snapshot is easy. It's the roll-forward
> code that's dodgy, isn't it?

In my experience the rollback code also has issues.  I've seen it get 
badly confused.

Eduardo