Dec 12, 2002, 2:37 PM
Post #7 of 12
(4114 views)
Permalink
> My question about file folding (after reading about it here and on NOW)...
>
> Why would a block end up in a snapshot if it is the same as the previous
> snapshot? Isn't the point of snapshots only to save the 'old version' of
> blocks that have been changed?
Snapshots do not copy any blocks, so including the same block in
multiple snapshots incurs no overhead. It works like this. Each
data block in a volume has associated with it a bit map of length 32
(20 on older releases) These bits correspond to snapshots. For example,
if bit #3 is set, then the block is part of snapshot #3. The filer
keeps track of which logical name (eg "hourly.0") is associated with each
bit. The size of the bit map limits the number of snapshots that can
exist in a volume.
Here's what happens when you create a snapshot. The filer picks an
unused snapshot number and sets the corresponding bit for all blocks
currently in use by the live filesystem. Note that many of these
blocks may have had other bits set when other snapshots were
created previously. So a block can be a member of multiple snapshots.
It may even be a member of all snapshots. This is not unusual at all.
If a file is older than your oldest snapshot, then the blocks that
comprise the file are members of all snapshots.
When a snapshot is deleted, the bit corresponding to the snapshot
is cleared for each block that has the bit set. If a block is left
with no bits set and if the block is not part of the live filesystem,
then it is freed for reuse.
So long as a block is a member of any snapshot, it cannot be modified,
so it cannot be freed for reuse. The only way to get that block back
is to delete all the snapshots that it belongs to.
You may wonder how you can possibly modify a file once it has been
snapshotted because you can't modify any of its blocks. The filer
simply makes changes in new data blocks and links them into the file
in place of the snapshotted blocks. The snapshotted blocks are left
untouched. However, they are no longer part of the live filesystem.
So when you look at a snapshot of a file, you are not looking at a copy.
You are looking at the actual data blocks that comprised the file when
the snapshot was made. In fact, the entire volume is treated this way
including the directories, inodes, etc. So when you look at a snapshot,
you are looking at the actual blocks that comprised the volume at the
moment the snapshot was taken. File permissions, owner, group, timestamps,
etc., are all frozen in time. (This can be a security issue. If a
sensitive file has been left world readable and you change the permissions
to protect it, you have to remember that any snapshotted copy of the file
still has the wrong permissions, so anyone can still read the file
in the snapshot. Your only option is to delete all snapshots where the
file is world readable.)
>
> OK, second question, does it only check the most recent snapshot or does it
> drill through all existing snaps?
Don't know.
>
> Now that I think more on the subject, third question... what happens to the
> snapshot "n" that references blocks in snap "n+1" when "n+1" rolls off the
> end and expires?
Don't think about what happens to the snapshot, think about what happens
to the blocks. If a block is a member of snapshots n and n+1, then the
block has at least two bits set (n and n+1). When n+1 expires, bit
n+1 is cleared for all blocks where it is set. Since bit n is still set,
the block is not freed, leaving snapshot n still intact.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support