kern/100365: snapshots on busy filesystem fail

Tor Egge Tor.Egge at cvsup.no.freebsd.org
Mon Aug 21 13:00:44 UTC 2006


The following reply was made to PR kern/100365; it has been noted by GNATS.

From: Tor Egge <Tor.Egge at cvsup.no.freebsd.org>
To: sjr at comcast.net
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: kern/100365: snapshots on busy filesystem fail
Date: Mon, 21 Aug 2006 12:57:32 +0000 (UTC)

 It looks like snapshots don't work well on amd64.  Making a snapshot
 while 'make world' is running in the background and mounting it multiple
 times shows that it isn't stable:
 
 
 # rm -f /usr/.snap/snapshot
 # mksnap_ffs /usr /usr/.snap/snapshot
 # mdconfig -a -t vnode -f /usr/.snap/snapshot -u 0 -o readonly
 # mount -r /dev/md0 /mnt
 # ls -lisdtT /mnt/src/make.world
 1860701 11792 -rw-r--r--  1 root  bin  12050746 Aug 19 23:21:33 2006 /mnt/src/make.world
 # umount /mnt
 # mount -r /dev/md0 /mnt
 # ls -lisdtT /mnt/src/make.world 
 1860701 12528 -rw-r--r--  1 root  bin  12801326 Aug 19 23:23:03 2006 /mnt/src/make.world
 
 The check at the start of ffs_copyonwrite() for whether the write is to a
 snapshot file or not is faulty when the write is a metadata update.  In that
 case, the vnode associated with the buffer doesn't have an inode, but instead a
 devfs_dirent structure.
 
 Memory beyond the end of the related devfs_dirent structure is incorrectly
 interpreted as ufs inode flags for those metadata updates.
 
 On RELENG_6/amd64, what is interpreted as i_flags is really the start of the
 device name in the dirent structure following the devfs_dirent structure,
 content typically 0x73306164 (da0s), triggering the failure.
 
 On HEAD/i386, what is interpreted as i_flags is beyond the end of both the
 devfs_dirent structure and the following dirent structure, content typically
 zero, not triggering the failure.
 
 - Tor Egge


More information about the freebsd-bugs mailing list