Re: ffs snapshots patch

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

On Thu, Apr 28, 2011 at 11:48:55AM +0200, Juergen Hannken-Illjes wrote:
> On Wed, Apr 27, 2011 at 10:43:59AM +0200, Manuel Bouyer wrote:
> > 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
> 
> No.  We use snapshots (with -X) for fsck and dump.  This makes no sense
> if we cannot fsck a snapshot any more.

AFAIK dump will ignore snapshot files (or at last it should), so it's not a
problem is the snapshot's blocks changes while we're working on a snapshot.
Also AFAIK, the above issue will only cause fsck to report missing blocks
in group maps and summary informations. It's not a big deal either.

In their current form, snapshot are not useable even for this, because
it's not acceptable to suspend a file server for several 10s of
seconds (if not minutes) to start a dump or fsck.

> > /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).
> 
> The only other OS with ffs+snapshots is FreeBSD which should behave similiar.
> Other file systems like ZFS, NilFS etc. will be faster and scale better as
> they are designed with instant snapshots in mind.

what about ext3fs ?

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