Date: Fri, 2 Jul 2004 11:49:27 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Q <q_dolan@yahoo.com.au> Cc: Sam Lawrance <boris@brooknet.com.au> Subject: Re: writing to RW-mounted UFS2 snapshots - confirmed. Message-ID: <Pine.NEB.3.96L.1040702114806.5661C-100000@fledge.watson.org> In-Reply-To: <0FAC476E-CB27-11D8-9145-000D9335C6A0@yahoo.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 1 Jul 2004, Q wrote: > >> This is unexpected. You can successfully mount the snapshot > >> read/write and create and write to files in that snapshot. You can > >> also write to files that existed in the snapshot prior to mounting it > >> read/write. > > > > Perhaps the writing is done from a point where the schg flag is not > > checked or obeyed? > > While this may not be "expected" behavior, I am curious why this is > something that should be prevented, rather than verified for > correctness? By "correct" I mean, that the copy on write process is > performed correctly and modifications made to the snapshot don't modify > the underlying filesystem elements also. > > To me this has the potential to allow snapshots to be used in reverse as > a sort of an "undo drive", similar to unionfs, where you can make > changes to a snapshot without the changes being permanently applied to > the live filesystem. This might be useful for testing an upgrade or > database recovery on a "staging" snapshot before attempting to modify > the real thing. Having checked with Kirk yesterday here at USENIX, the reason this is undesirable is that he didn't intend it to work that way, and therefore hasn't written the necessary bookkeeping. I.e., while one could argue the feature should work that way, one would want it to be intentional :-). This is probably a bug in our md code, I'll try to take a look at it today sometime, now that I've pinned kirk down on how it's supposed to work. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040702114806.5661C-100000>