Date: Tue, 30 Sep 2014 16:15:43 +0200 From: Mattia Rossi <mattia.rossi.mailinglists@gmail.com> To: Ian Lepore <ian@FreeBSD.org>, freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: Random Kernel Panic on Dreamplug (FS related) Message-ID: <542ABB0F.8080201@gmail.com> In-Reply-To: <1412085915.66615.360.camel@revolution.hippie.lan> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <1411998551.66615.328.camel@revolution.hippie.lan> <20140930113444.GV43300@funkthat.com> <1412085915.66615.360.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 30.09.2014 16:05, schrieb Ian Lepore: > On Tue, 2014-09-30 at 04:34 -0700, John-Mark Gurney wrote: >> Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600: >>> On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote: >>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >>>>> This might be part of the weird FFS issues the Dreamplug has and no-one >>>>> knows why they're happening. >>>> Are you running w/ FFS journaling? If so, try turning it off, but >>>> keeping softupdates on.. >>>> >>> It's not an SU+J problem, or even an SU problem. fsck finds >>> non-existant errors on filesystems known to be clean, and if >>> write-enabled it will corrupt the good filesystem when attempting to >>> correct those "errors". This is on armv4 only, not v6. I tested with >>> and without softupdates on. I tested with UFS1 and UFS2 filesystems. >>> You can even do a newfs followed immediately by an fsck on it and it >>> will corrupt the fs. >>> >>> The one thing I haven't done is opened a PR for this. >> Hmm... I just tested this on my AVILA board, and I don't see this on >> either UFS1 or UFS2... Are you doing this via HD or md? My testing was >> via a 64MB md as I don't have a good way to attach external storage to >> my board... >> >> If you really are seeing immediate corruption to an SD card, then I'd >> make sure that the card is getting the correct data written to it... >> > There isn't actually any corruption on the filesystem until fsck starts > trying to fix what it thinks is wrong. That is, fsck -n will report > problems, you then move that drive to a non-armv4 system and fsck there > reports no problems. If you let armv4 fsck "fix" problems then move the > drive to another system and re-check, the filesystem IS corrupted at > that point. > >> I'd suggest trying to run ZFS since it checksums everything it writes, >> but not sure if it'd run, and if so, how well... >> > afaik, nobody has ever tried zfs on any arm platform. Maybe it just > works. I'd love to hear from someone about it. I don't have time > myself to learn to configure and administer it. I think there are at least a few people that tried it (http://lists.freebsd.org/pipermail/freebsd-arm/2014-February/007455.html). I've tried it as well (on an external ESATA disk), but had some performance problems, which I think could be resolved if I would run a bootloader (which I don't). The other solution would be to apply the following patch, and tweak performance via sysctls on a running system: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 Anyhow, first things first..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542ABB0F.8080201>