FreeBSD UFS2 snapshots, and math ... - resolved, but two more Qs

Gayn Winters gayn.winters at bristolsystems.com
Thu Oct 20 14:23:21 PDT 2005



> -----Original Message-----
> From: user [mailto:user at dhp.com] 
> Sent: Thursday, October 20, 2005 1:51 PM
> To: Gayn Winters
> Cc: 'Andrew P.'; freebsd-questions at freebsd.org
> Subject: RE: FreeBSD UFS2 snapshots, and math ... - resolved, 
> but two more Qs
> 
> 
> 
> Folks,
> 
> On Thu, 20 Oct 2005, Gayn Winters wrote:
> 
> > > Imagine that each data block is marked with labels
> > > on change. It doesn't matter how many labels there
> > > are, there will be only one data block saved.
> > 
> > In trying to follow this thread, I started looking around 
> for a precise
> > definition of snapshot.
> > Man mksnap_ffs
> > wasn't too helpful, and googling for "snapshot" etc. wasn't 
> fruitful.
> > I'm guessing that the original author of the thread (user 
> at dhp.com)
> > may also need such a definition.  Can someone provide a pointer to a
> > specification or at least an RFC-like paper?
> 
> 
> I found one:
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/README.s
> napshot?rev=1.4
> 
> and further, I did some tests and discovered that what I was 
> being told
> (by you folks) was indeed correct.
> 
> No matter how many snapshots you have, the changes in blocks since the
> tiem before the first snapshot is only recorded in one of 
> them.  That is
> to say, if I do the following:
> 
> - create 4 1gig /dev/zero filled files
> - create a snapshot
> - overwrite one of those 1gig files with /dev/random
> 
> My free space will have decreased by 1gig.  So far so good.
> 
> If I then:
> 
> - create a second snapshot
> - overwrite a different 1gig file with /dev/random
> 
> My free space merely decreases by another 1gig.  It makes 
> sense to me now
> because it has occurred to me that since the second file had 
> not changed
> between the creation of the first and second snapshot, there 
> is no reason
> for _both_ snapshots to _both_ say "this 1gig random file used to be
> filled with zeros" - it would be redundant.
> 
> So that's great ... but I am curious, how do they know ?  I think my
> previous assumption (that the first _and_ the second snapshot 
> file would
> _both_ have to record the change of file #2 from zero to 
> random) was based
> on the notion that these snapshot files were totally autonomous and
> independent, and had no general organization behind them.  If 
> that was the
> case, then I am still fairly certain both snapshots would 
> need to record
> the change of the second file.
> 
> So what is the behind the scenes organization that makes it 
> possible for
> the snapshot files to not duplicate data like that ?
> 
> ALSO,
> 
> I have noticed that if you:
> 
> - dd 1gig /dev/zero file
> - create snapshot
> - overwrite that 1gig file with /dev/random
> 
> (free space decreases by 1gig, as expected)
> 
> - rewrite that 1gig file with /dev/zero again
> 
> You _don't_ get that 1gig of free space back ... which 
> surprises me, since
> it was all zeros before, and its all zeros now ... how does 
> the snapshot
> know those are "different zeros" ?  And what ramifications 
> does this have
> for restoring, etc., if identical files do not get counted as 
> identical in
> the snapshot ?
> 
> thanks.
> 

I just finished skimming an old paper by McKusick on Soft Updates:
http://www.usenix.org/publications/library/proceedings/usenix99/full_pap
ers/mckusick/mckusick.pdf
This paper is dated 1999.  Does anyone know if it accurately reflects
how soft updates and snapshots in FreeBSD 5.4 are implemented?  If so,
it would answer the above questions.

-gayn




More information about the freebsd-questions mailing list