Snapshot corruption on 6.1/amd64

Kostik Belousov kostikbel at gmail.com
Thu Sep 21 21:15:51 PDT 2006


On Thu, Sep 21, 2006 at 03:43:03PM -0500, Eric Anderson wrote:
> On 09/21/06 14:59, James Lauser wrote:
> >Hello.
> >
> >I've been having some trouble with snapshots on my FreeBSD 6.1/amd64  
> >system.  Basically, I have this system set up with a 3ware RAID card  
> >and several disks, and use it to collect backups from my other  
> >FreeBSD server (sparc64) and three Macs via rsync..
> >
> >Every night, I have a script generate a snapshot of the RAID's file  
> >system, and those snapshots are kept on the system for one week  
> >before being removed (i.e. there are always 7 snapshots present on  
> >the system), so I can recover files that were accidentally removed or  
> >changed.
> >
> >The problem is that when a large number of files are removed or  
> >changed on the file system, the corresponding files in the snapshot  
> >get corrupted.  This, obviously, makes the snapshots quite useless.
> >
> >After some searching, I've found a bug report filed last year that  
> >describes this problem exactly, though the log of that report does  
> >not suggest that anything has been done with it.  That report is at  
> >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/90512
> >
> >Any help would be greatly appreciated.  A test I ran showing the  
> >problem, plus the output of uname -a and dmesg.boot is attached.
> >
> >Thanks in advance.
> 
> 
> >Sledge# cd /raid
> >Sledge# touch foo
> >Sledge# ls -l foo
> >-rw-r--r--  1 root  wheel  0 Sep 18 14:07 foo
> >Sledge# mksnap_ffs /raid /raid/.snap/snap
> >Sledge# rm foo
> >Sledge# mdconfig -a -t vnode -f /raid/.snap/snap -u 4
> >WARNING: opening backing store: /raid/.snap/snap readonly
> >Sledge# mount -r /dev/md4 /mnt
> >Sledge# cd /mnt
> >Sledge# ls -l foo
> >ls: foo: Bad file descriptor
> >Sledge# 
> >Sledge# 
> >Sledge# 
> >Sledge# uname -a
> >FreeBSD Sledge.jlauser.net 6.1-RELEASE-p6 FreeBSD 6.1-RELEASE-p6 #4: Wed 
> >Sep  6 23:30:56 EDT 2006     
> >root at Sledge.jlauser.net:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> Hmm.. Interesting, it seems to work fine for me:
> 
> [root at neutrino /tmp]# dd if=/dev/zero of=TESTDISK bs=1m count=100
> 100+0 records in
> 100+0 records out
> 104857600 bytes transferred in 3.390829 secs (30923882 bytes/sec)
> [root at neutrino /tmp]# mdconfig -a -t vnode -f ./TESTDISK
> md0
> [root at neutrino /tmp]# newfs -U /dev/md0
> /dev/md0: 100.0MB (204800 sectors) block size 16384, fragment size 2048
>         using 4 cylinder groups of 25.02MB, 1601 blks, 3264 inodes.
>         with soft updates
> super-block backups (for fsck -b #) at:
>  160, 51392, 102624, 153856
> [root at neutrino /tmp]# mount /dev/md0 /mnt
> [root at neutrino /tmp]# touch /mnt/foo
> [root at neutrino /tmp]# mksnap_ffs /mnt/ /mnt/.snap/snap
> [root at neutrino /tmp]# mdconfig -a -t vnode -f /mnt/.snap/snap
> WARNING: opening backing store: /mnt/.snap/snap readonly
> md1
> [root at neutrino /tmp]# mount -r /dev/md1 /mnt2
> [root at neutrino /tmp]# cd /mnt2
> [root at neutrino /mnt2]# ls -l foo
> -rw-r--r--  1 root  wheel  0 Sep 21 15:37 foo
> [root at neutrino /mnt2]#
I think you have i386 system ?

James, look at the PR/100365. Supposed fix is MFCed. Original reporter
said that this changed nothing for him. I have not much time lately to
look at this problem, but would like to get additional data points.

BTW, use of snapshots with stock 6.1 is not very attractive idea, better
to update to the 6-STABLE (many important fixes in that area were made).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20060922/e773fd43/attachment.pgp


More information about the freebsd-fs mailing list