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 <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
