Date: Wed, 16 Dec 2009 07:35:57 -0800 (PST) From: RuiDC <ruidc@yahoo.com> To: freebsd-arm@freebsd.org Subject: Re: fetch data corruption on local fs Message-ID: <26813077.post@talk.nabble.com> In-Reply-To: <26811801.post@talk.nabble.com> References: <26803523.post@talk.nabble.com> <4B28C608.1070802@gmail.com> <4B28CFCD.3000401@semihalf.com> <26811801.post@talk.nabble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm having a hard time searching for how to pass these mount options for root. I believe I have to set them in the setting vfs.root.mountfrom.options But I don't know where I have to make this change so that it is baked into the kernel.bin output file that the sheevaplu/FreeBSD build process produces, or even if there's an easier way I can specify these eg. /etc/fstab but still have them picked up at boot time. Can anybody point me in the right direction? RuiDC wrote: > > Thanks! That's definitely the problem, I used an md filesystem instead of > nfs as it was easier, and reproduced the problem, this time on a smaller > .gz file (11MB): ftp://ftp.gnu.org/gnu/gettext/gettext-0.17.tar.gz > which was also failing consistently. If I mount it without -o sync I > reproduce the problem, if I mount it with -o sync it works. > > so the only questions open are that: > 1. this happens for relatively small files as above rather than the 300MB > referred to in your quoted thread, > 2. what is the safest to use: just -o sync or also -o noclusterr -o > noclusterw ? > > 3. I then need to seek how to compile these mount options into the kernel, > as this is for my root filesystem compiled using: option > ROOTDEVNAME=\"ufs:/dev/da0s2\" > > Regards, > RuiDC > > > Grzegorz Bernacki wrote: >> >> bebahu@gmail.com wrote: >> >>> I have seen the same problem. Fetch is corrupting downloads to local >>> filesystems. You can try it on an NFS mount or mount your local fs with >>> "-o sync". >>> >>> As i have seen there are n x 32bytes of corrupt chunks in the downloaded >>> file. I hope it correlate with something, but have no time to dig >>> deeper. Also note cp, scp does not corrupts data so fetch does something >>> alternatively. >>> >> >> Hi, >> >> 32 bytes is a size of cache line, so probably this is a cache coherency >> issue. Please read mail below for details and workaround. >> >> http://lists.freebsd.org/pipermail/freebsd-arm/2008-December/001423.html >> >> Grzesiek >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> >> > > -- View this message in context: http://old.nabble.com/problem-setting-up-ports-tp26803523p26813077.html Sent from the freebsd-arm mailing list archive at Nabble.com.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26813077.post>