Re: Snapshots in tmpfs

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

On Wed, Feb 29, 2012 at 06:45:41PM -0600, David Young wrote:
 > > > Oh, my mistake, since there was concern about filesystem type I
 > > > thought you were talking about raw flash, but apparently CompactFlash
 > > > is not raw flash, same as USB sticks aren't.
 > > > 
 > > > In that case, just use wapbl.
 > > 
 > > That doubles the write rate for the common "create new version of
 > > file and rename into place" pattern...

(no it doesn't)

 > > Translation layer or not, doubling the write rate to any type of
 > > flash is not a great idea.
 > 
 > One way to hold writes to flash down to a very low rate is to keep files
 > that change in a tmpfs, and everything else in a read-only FFS.
 > 
 > Sometimes the files that change need to persist across reboots and power
 > failures.  One way to make them persist is to periodically write a
 > checkpoint of the tmpfs containing those files to flash.  After a reset
 > or power failure, use the last checkpoint to restore the tmpfs.
 > 
 > One way to store the checkpoints is to reserve a partition on flash for
 > receiving them.  You don't put a filesystem on the checkpoint partition,
 > but you treat it like a (circular) tape with big blocks.  Ideally, the
 > block size is a multiple of the biggest block size that the flash uses.
 > [...]

The problem with that scheme is that you rewrite everything to the
flash over and over again anytime something changes, which is going to
generate vastly more write cycles than just using a normal fs.

Sure, you can write incremental updates to the flash (you can probably
even use dump to generate them) but by the time you've sorted that all
out and debugged it all, you've done a lot of work to get roughly the
same results you'd get just by using a normal fs.

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