Subject: Re: Which snapshot strategy to use? was: How to capture all file
To: gabriel rosenkoetter <gr@eclipsed.net>
From: Greywolf <greywolf@starwolf.com>
List: tech-kern
Date: 10/23/2003 15:02:27
Thus spake gabriel rosenkoetter ("gr> ") sometime Today...

gr> Don't think log. Think copy-on-write into a buffer that you have
gr> every intention of flushing back to the underlying file system on a
gr> block (whether that means disk block or virtual block) basis, not on
gr> replaying like you do a log.

Begging pardon, but isn't that a matter of semantics?  And wouldn't the
buffer actually have to be a working copy of the FS, in a way?  How
would it handle the scenario of:

	# freeze writes to /fs
	# mkdir -p /fs/tmp/foo
	# cp /etc/passwd /fs/tmp/foo/bar
	# mv /fs/tmp/foo/bar /fs/tmp/foo/grill
	# rm /fs/tmp/foo/grill

Whether you're buffering fs ops, or you're keeping a log of said fs ops,
isn't it the same?  You still have to do a more or less sequential update
of the information, or you need to maintain a true shadow fs on which the
operations handle and figure out a way to meld the changes.

For the record, I'm sure not against snapshots!  It would make it SO much
easier to take a backup of a live system.  And I'm not trying to be dense,
here, but I'm stuck with the hopeless feeling that I'm really missing
an important piece of the puzzle.

If you don't have a full backing store of the fs, what do you do when
your suspended write-through (for lack of a more available term) buffer
fills before your snapshot or desired operations on the filesystem
are finished?  Do you block writes at that point and leave the behaviour
up to whether the writes are blocking/nonblocking?

I have to wonder about that, since holding full backing store of a
near-full 120G fs is not exactly your average cup of coffee.

				--*greywolf;
--
NetBSD, Net Profit.