Re: Snapshots in tmpfs

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Mar 05, 2012 at 01:12:43PM -0600, David Young wrote:
> On Mon, Mar 05, 2012 at 06:14:04AM +0000, David Holland wrote:
> > 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.
> 
> This scheme doesn't write anytime something changes, it writes
> periodically.  The number of write cycles over/under a normal fs depends

Practically speaking, that requires the rest of the device runtime to
know that all configuration updates are to be batched together.  Generally
speaking, that requires enough coordination that it's not really any
harder to then tar up the tmpfs and put it aside somewhere (like a raw
partition, which is what some Linux embedded environments do) -- no kernel
code required.

Also, even when done carefully, this can result in writes of huge
numbers of blocks when only a few really change.

On another subject, though, I do want to talk about the question of
whether running FFS with WAPBL for /etc on flash devices causes double
write load for common cases.  Here is why I believe it does:

        * The typical application pattern for config file updates is
          to create a temporary file -- one transaction written to the
          journal, plus the data blocks which must be written,
          then move it into place -- another transaction written to the
          journal.  Many applications also fsync the temporary file
          first.

        * Without journaling, this looks like, pretending it's a 1 block
          file:

                * 1 write for the data block
                * 1 write for the file-create metadata change
                * 1 write for the rename metadata change

        * With journaling, though:

                * 1 write into the journal for the file create
                * 1 write for the data blocks
                * possibly a journal flush caused by the fsync
                * 1 write into the journal for the rename
                * 2 writes for the actual metadata changes
                * 1 write to mark the journal entries as done

Is that not the case?

Thor