Date: Fri, 30 Dec 2016 12:57:16 +0100 From: Dirk-Willem van Gulik <dirkx@webweaving.org> To: Peter Jeremy <peter@rulingia.com> Cc: FreeBSD Hackers <hackers@freebsd.org> Subject: Re: ZFS - directory entry Message-ID: <C85151EE-557C-4B98-9646-9A09C52A70AB@webweaving.org> In-Reply-To: <20161214185154.GT61036@server.rulingia.com> References: <BEAC6EE9-C50F-4FB9-B215-D5A6691E2DD9@webweaving.org> <20161214185154.GT61036@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 14 Dec 2016, at 19:51, Peter Jeremy <peter@rulingia.com> wrote: >=20 > On 2016-Dec-14 16:27:00 +0100, Dirk-Willem van Gulik = <dirkx@webweaving.org> wrote: >> A rather odd directory entry (in /root, the home dir of root/toor) = appeared on a bog standard FreeBSD 10.2 (p18) lightly loaded machine = under ZFS during/post a backup: >>=20 >> $ ls -la /root | tail -q >> ---------- 1 root wheel 9223372036854775807 Jan 1 1970 = ?%+?kD?H???x,?5?Dh;*s!?h???jw??????\h?:????????``?13?@?????OA????????Puux?= ???<T]???R??Qv?g???]??%?R? >>=20 >> OS and ZFS is installed with a bog standard sysinstall. =E2=80=98SMART=E2= =80=99 nor smartd have reported anything. nothing in dmesg, syslog of = boot log. Any suggestions as how to debug or get to the root of this ?=20= >>=20 >> And in particular - what is a risk of a reboot (to get a kernel with = debug, etc) causing the issue to =E2=80=98go away=E2=80=99 - and hence = stopping the forensic ? >=20 > Do you have ECC RAM? If not, it's possible this is an artifact of = some RAM > corruption, rather than on-disk corruption. >=20 > I'm surprised by the slow scrub, though they are very slow disks. You = might > like to use gstat or zpool iostat to see if one of the disks is slower = than > the others - indicating a possible problem with it. For the record - no such imbalance was found (all disks a specced = performance; SMART data yielded nothing either). Scrub found nothing. A = zfs send & compares of snapshots prior and post the entry did not yield = anything conclusive (But -1 entries in that directory). A reboot did not fix the issue =E2=80=94 i.e. it appeared resident on = disk post reboot (and in zfs send). An extensive lowlevel/bios memtest = (memtest.exe et.al. through PXE) did not find any HW issues; nor did a = SMART level disk check on all disks. Ultimately the =E2=80=98file=E2=80=99 was deleted with a simple = =E2=80=98rm=E2=80=99. Took about 3 seconds to return with a prompt. And = that was it. A post remove =E2=80=9Czfs send=E2=80=9D followed by a "zfs scrub" found = no ill effect/lost data (nor did tripwire throughout it all). So very odd all in all - and mildly unsatisfying :) Dw
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C85151EE-557C-4B98-9646-9A09C52A70AB>