Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Dec 2016 20:01:12 +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:  <68290275-9C8D-4ACC-9E29-B6A7805512FD@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.

No ECC (simple 4x8 Gbyte sticks; nothing on L2 and L3 either).

> 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.

Perfectly balanced. Rocks steady last few hours according to per disk =
graphs. We=E2=80=99ll see how it goes before rebooting (and if it is =
indeed memory - that will I guess mask the issue until it appears =
again).

Thanks,

Dw=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68290275-9C8D-4ACC-9E29-B6A7805512FD>