Date: Mon, 04 Mar 2013 15:52:06 -0700 From: Ian Lepore <ian@FreeBSD.org> To: "Brian J. McGovern" <mcgovern@beta.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: arm/173617 Message-ID: <1362437526.1195.293.camel@revolution.hippie.lan> In-Reply-To: <201303042155.r24LtN7a016998@spoon.beta.com> References: <201303042155.r24LtN7a016998@spoon.beta.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2013-03-04 at 16:55 -0500, Brian J. McGovern wrote: > I have been chasing down a disk write problem my OpenRD. In my research, I > ran across arm/173617, which discusses file corruption while downloading ports > via fetch, which is how I first noticed the issue. However, contrary to the PR, > the issues does not appear to be in the network interface, but rather on the > writing of the file to disk. The problem appears global - I've tested SATA, > USB (umass), and SD/MMC interfaces. I've also had problems with NFS mounts in > the past, but have not verified that the issues are the same. > > I have not chased down a particular size, but "small" writes (e.g. a config > file, .c file, etc.) appear to work correctly at all times. "Large" writes > (I usually see it on files a MB or larger, but this may be a function of > opportunity) will typically see some number of bytes set to zero. To reproduce > the problem, I wrote a short application that writes sequentially incrementing > 64-bit integers out to disk. (e.g. 0, 1, 2, 3...), and one that reads them > back. > > The result matrix clearly showed the problem is on the write side - writing > files on other systems and reading them back on the OpenRD works fine. Writing > them on the OpenRD causes read back failures, both on the OpenRD _and_ other > hosts. I have also found that setting the file handle O_SYNC (or mounting > the filesystem in sync mode) eliminates the problem. > > Has anyone seen/fixed this problem? I'd hate to waste much more time with it > if its a known problem, or there is a closed PR I haven't found yet. > You didn't say what version of freebsd you're working with. I saw a problem like that a while back on my similar DreamPlug; the symptom was random chunks of corruption that were always 32 bytes of wrong data each. I think the fix for that was to disable cache write-allocate on sheeva chipsets; that fix came into -current along with all the armv6 changes, but I have it as a separate patch too. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362437526.1195.293.camel>