From owner-freebsd-arm@FreeBSD.ORG Wed Dec 16 15:41:52 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59974106566B for ; Wed, 16 Dec 2009 15:41:52 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 05A608FC16 for ; Wed, 16 Dec 2009 15:41:51 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 7CEC6C41E7; Wed, 16 Dec 2009 16:41:52 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id SP-Gu44bAbvH; Wed, 16 Dec 2009 16:40:33 +0100 (CET) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id 8C096C3BA4; Wed, 16 Dec 2009 16:40:33 +0100 (CET) Message-ID: <4B28FF6F.4090601@semihalf.com> Date: Wed, 16 Dec 2009 16:40:31 +0100 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: RuiDC References: <26803523.post@talk.nabble.com> <4B28C608.1070802@gmail.com> <4B28CFCD.3000401@semihalf.com> <26811801.post@talk.nabble.com> In-Reply-To: <26811801.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: fetch data corruption on local fs X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 15:41:52 -0000 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, It all depends on how memory is use and which cache lines are evicted. In my case it happened always for files bigger then 300MB and sometimes for smaller files. > 2. what is the safest to use: just -o sync or also -o noclusterr -o > noclusterw ? As I understand setting just "-o noclusterr -o noclusterw" didn't help you, right? If so use just "-o sync". > > 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\" I don't know how to compile it into kernel, but you can try to add line: vfs.root.mountfrom.options="sync" to your loader.conf Grzesiek