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