Skip site navigation (1)Skip section navigation (2)
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>