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