Panic on removing corrupted file on zfs

[Ben Stuyts]

Anybody? Otherwise I’ll just wipe the pool (it’s a backup so no big loss).

(To be safe I also ran memtest86 on this system, but it found no errors.)

Ben

> On 23 Jun 2015, at 17:26, Ben Stuyts <ben at altesco.nl> wrote:
> 
> Hello,
> 
> I have a corrupted file on a zfs file system. It is a backup store for an rsync job, and rsync errors with:
> 
> rsync: failed to read xattr rsync.%stat for "/home1/vwa/rsync/tank3/cam/jpg/487-20150224180950-05.jpg": Input/output error (5)
> Corrupt rsync.%stat xattr attached to "/home1/vwa/rsync/tank3/cam/jpg/487-20150224180950-04.jpg": "100644 0,0 \#007:1001"
> rsync error: error in file IO (code 11) at xattrs.c(1003) [generator=3.1.1]
> 
> This is a file from februari, and it hasn’t changed since. Smartctl shows no errors. No ECC memory on this system, so maybe caused by a memory problem. I am currently running a scrub for the second time. First time didn’t help.
> 
> Output from zpool status -v:
> 
>  pool: home1
> state: ONLINE
> status: One or more devices has experienced an error resulting in data
> 	corruption.  Applications may be affected.
> action: Restore the file in question if possible.  Otherwise restore the
> 	entire pool from backup.
>   see: http://illumos.org/msg/ZFS-8000-8A
>  scan: scrub in progress since Tue Jun 23 15:37:31 2015
>        462G scanned out of 2.47T at 80.8M/s, 7h16m to go
>        0 repaired, 18.29% done
> config:
> 
> 	NAME                                          STATE     READ WRITE CKSUM
> 	home1                                         ONLINE       0     0     0
> 	  gptid/14032b0b-7f05-11e3-8797-54bef70d8314  ONLINE       0     0     0
> 
> errors: Permanent errors have been detected in the following files:
> 
>        /home1/vwa/rsync/tank3/cam/jpg/487-20150224180950-05.jpg/<xattrdir>
> 
> When I try to rm the file the system panics. From /var/crash:
> 
> tera8 dumped core - see /var/crash/vmcore.1
> 
> Tue Jun 23 15:37:11 CEST 2015
> 
> FreeBSD tera8 10.1-STABLE FreeBSD 10.1-STABLE #2 r284317: Fri Jun 12 17:07:21 CEST 2015     root at tera8:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> panic: acl_from_aces: a_type is 0x4d00
> 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> panic: acl_from_aces: a_type is 0x4d00
> cpuid = 1
> KDB: stack backtrace:
> #0 0xffffffff8097d890 at kdb_backtrace+0x60
> #1 0xffffffff809410e9 at vpanic+0x189
> #2 0xffffffff80940f53 at panic+0x43
> #3 0xffffffff81aaa209 at acl_from_aces+0x1c9
> #4 0xffffffff81b61546 at zfs_freebsd_getacl+0xa6
> #5 0xffffffff80e5de77 at VOP_GETACL_APV+0xa7
> #6 0xffffffff809c7a3c at vacl_get_acl+0xdc
> #7 0xffffffff809c7bd2 at sys___acl_get_link+0x72
> #8 0xffffffff80d35817 at amd64_syscall+0x357
> #9 0xffffffff80d1a89b at Xfast_syscall+0xfb
> 
> Is there any other way of getting rid of this file (except destroying the fs/pool)? 
> 
> Thanks,
> Ben
> 
> 
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>