Re: ffs snapshots patch

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Apr 18, 2011 at 09:36:25AM +0200, Juergen Hannken-Illjes wrote:
> [...]
> > Fixing 2) is trickier. To avoid the heavy writes to the snapshot file
> > with the fs suspended, the snapshot appears with its real lenght and
> > blocks at the time of creation, but is marked invalid (only the
> > inode block needs to be copied, and this can be done before suspending
> > the fs). Now BLK_SNAP should never be seen as a block number, and we skip
> > ffs_copyonwrite() if the write is to a snapshot inode.
> 
> I strongly object here.  There are good reasons to expunge old snapshots.
> 
> Even it it were done right, without deadlocks and locking-against-self,
> the resulting snapshot looses at least two properties:
> 
> - A snapshot is considered stable.  Whenever you read a block you get
>   the same contents.  Allowing old snapshots to exist but not running
>   copy-on-write means these blocks will change their contents.
> 
> - A snapshot will fsck clean.  It is impossible to change fsck_ffs
>   to check a snapshot as these old snapshots indirect blocks now will
>   contain garbage.

Maybe we should relax these contraints then

> 
> You cannot copy blocks before suspension without rewriting them once
> the file system is suspended.
> 
> The check in ffs_copyonwrite() will only work as long as the old
> snapshot exists.  As sson as it gets removed we will run COW
> on the blocks used by the old snapshot.

is it a problem ?

On Sat, Apr 23, 2011 at 10:40:05AM +0200, Juergen Hannken-Illjes wrote:
> [...]
> 
> These times depend on the file systems block size.  With contiguous indirect
> blocks (ffs_balloc.c rev 1.54) I did timings on a 1.4 TByte UFS1 non-logging
> file system created on 3 concatenated WD5003ABYX.  For every block size
> I created four persistent snapshots (with unmounting the file systems after
> every creation) and get these times (seconds):
> 
> Layout            create suspended
> 
> 91441948 x 16384  385.713   22.785
> 91441948 x 16384  414.170   59.580
> 91441948 x 16384  474.164   91.385
> 91441948 x 16384  652.556  111.314
> 
> 45720974 x 32768   43.478    0.420
> 45720974 x 32768   40.790    5.642
> 45720974 x 32768   49.700   12.748
> 45720974 x 32768   55.599   18.612
> 
> 22860487 x 65536    7.005    0.600
> 22860487 x 65536   10.558    2.436
> 22860487 x 65536   14.365    4.122
> 22860487 x 65536   18.615    5.739
> 
> For me snapshots create reasonable fast with a block size of 32k or 64k.

On my test system (16k/2k UFS2, logging, quotas) I get:
/usr/bin/time fssconfig fss0 /home /home/snaps/snap0
      141.69 real         0.00 user         1.22 sys
/home: suspended 14.716 sec, redo 0 of 2556
/usr/bin/time fssconfig fss1 /home /home/snaps/snap1
      213.87 real         0.00 user         1.98 sys
/home: suspended 64.027 sec, redo 0 of 2556
/usr/bin/time fssconfig fss2 /home /home/snaps/snap2
      290.82 real         0.00 user         3.06 sys
/home: suspended 120.641 sec, redo 0 of 2556
/usr/bin/time fssconfig fss3 /home /home/snaps/snap3
      342.11 real         0.00 user         3.92 sys
/home: suspended 170.733 sec, redo 0 of 2556

Even a 14s hang is still a long time for a NFS server (workstations will be
frozen by this time). Even if we can make it shorter with some filesystem
tuning, it still doesn't scale with the size of the filesystem and
the number of snapshot (having 12 persistent snapshots on a filesystem is
not a unreasonable number).
Other OSes can do it with almost no freeze, so it should be possible
(the snapshot may not be fsck-able, but I'm not sure it's the most
important property of FS snapshots).

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--