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, Jose Luis Rodriguez Garcia wrote:

> I would like to implement this in LFS:
> 
> Write full stripes to RAID 5/6 from LFS using a NVRAM card or similar:
> 
> For this, the segment would be written to a NVRAM card or similar.
> When the full segment is written to the NVRAM card, it would be
> written to the raid as a full strip, without penalizing because of the
> raid. I have have thought for easy implementation in increase/decrease
> the size of segment on LFS, for that it is multiple of the stripe of
> the RAID device.
> 
> Question: Is it a small/medium/big project?

Ummm... It's probably a big project.  And I'm not sure it buys you much if 
anything.

A regular unix filesystem will use synchronous metadata writes to keep the 
FS image consistent if the box crashes or loses power.  NVRAM will speed 
up those operations.

LFS writes the metadata at the same time, in the same place as the data.  
No synchronous writes necessary.  In theory, if there is a failure you 
just roll back the log to an earlier synchronization point.  You lose the 
data after that point, but that should be fairly small, and you would have 
lost it anyway with a regular FS.  And you should be able to roll back the 
filesystem to snapshots of any earlier synchronization points.

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.

o The rollback code is quite sketchy.  It doesn't really work so well, so 
LFS has problems recovering from failures.  

o LFS keeps all of its inodes in a file called the ifile.  It's a regular 
LFS file, so in theory you can scan back to recover earlier revisions of 
that file.  Also, fsck_lfs should be able to reconstruct the ifile from 
scrach by scanning the disk.  This is yet another feature that has not 
been implemented yet.

LFS writes data in what's called a subsegment.  This is essentially an 
atomic operation which contains data and metadata.  The subsegments are 
collected into segments, which contain more metadata, such as a current 
snapshot of the ifile.  All the disk sectors in a subsegment are 
checksummed, so partial writes can be detected.  If the checksums on the 
subsegment is incorrect, LFS should roll back to a previous subsegment 
that does have a correct checksum.  I don't think that code exists, or if 
it does I don't think it works.

Anyway, hacking on LFS is lots of fun.  Enjoy!

Eduardo