Date: Fri, 26 Jun 2015 17:39:03 +0200 From: Ben Stuyts <ben@altesco.nl> To: freebsd-fs@freebsd.org Subject: Re: Panic on removing corrupted file on zfs Message-ID: <2CC1E621-687B-4F4A-97D4-2DCCB620E17A@altesco.nl> In-Reply-To: <BC0509E5-E86E-4D50-AB5A-308434C4C1CB@altesco.nl> References: <BC0509E5-E86E-4D50-AB5A-308434C4C1CB@altesco.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Anybody? Otherwise I=E2=80=99ll just wipe the pool (it=E2=80=99s 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@altesco.nl> wrote: >=20 > Hello, >=20 > I have a corrupted file on a zfs file system. It is a backup store for = an rsync job, and rsync errors with: >=20 > 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=3D3.1.1] >=20 > This is a file from februari, and it hasn=E2=80=99t 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=E2=80=99t help. >=20 > Output from zpool status -v: >=20 > 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: >=20 > NAME STATE READ = WRITE CKSUM > home1 ONLINE 0 = 0 0 > gptid/14032b0b-7f05-11e3-8797-54bef70d8314 ONLINE 0 = 0 0 >=20 > errors: Permanent errors have been detected in the following files: >=20 > = /home1/vwa/rsync/tank3/cam/jpg/487-20150224180950-05.jpg/<xattrdir> >=20 > When I try to rm the file the system panics. =46rom /var/crash: >=20 > tera8 dumped core - see /var/crash/vmcore.1 >=20 > Tue Jun 23 15:37:11 CEST 2015 >=20 > FreeBSD tera8 10.1-STABLE FreeBSD 10.1-STABLE #2 r284317: Fri Jun 12 = 17:07:21 CEST 2015 root@tera8:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > panic: acl_from_aces: a_type is 0x4d00 >=20 > 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"... >=20 > Unread portion of the kernel message buffer: > panic: acl_from_aces: a_type is 0x4d00 > cpuid =3D 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 >=20 > Is there any other way of getting rid of this file (except destroying = the fs/pool)?=20 >=20 > Thanks, > Ben >=20 >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CC1E621-687B-4F4A-97D4-2DCCB620E17A>