From owner-freebsd-bugs@FreeBSD.ORG Thu Apr 24 03:57:15 2008 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76B0B106564A; Thu, 24 Apr 2008 03:57:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 273C78FC15; Thu, 24 Apr 2008 03:57:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m3O3v4S6002726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2008 13:57:06 +1000 Date: Thu, 24 Apr 2008 13:57:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Dominic Fandrey In-Reply-To: <480F9E0F.3010803@bsdforen.de> Message-ID: <20080424133415.G70715@delplex.bde.org> References: <200804211445.m3LEjNh6018941@freefall.freebsd.org> <480CC6F4.1000200@bsdforen.de> <20080422084732.H63563@delplex.bde.org> <480E1F9E.5070308@bsdforen.de> <20080423110846.I67125@delplex.bde.org> <480F9E0F.3010803@bsdforen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org, gavin@FreeBSD.org, bug-followup@FreeBSD.org, Bruce Evans Subject: Re: kern/122961: write operation on msdosfs file system causes panic X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 03:57:15 -0000 On Wed, 23 Apr 2008, Dominic Fandrey wrote: > Bruce Evans wrote: >> The broken nocluster* can be worked around by upgrading to a version of >> mount_msdsosfs(8) that hasn't been broken by using nmount(2). >> mount_msdsosfs(8) from RELENG_5 should work. > > I feel reluctant about downgrading to 5.x mount_msdosfs, But it would be an upgrage :-). Anyway, running mount_msdosfs on one disposable file system that might panic should be safe. > however I can > confirm that cp with large files does _not_ cause a panic. As far as I > understand this confirms your theory. Not quite. I would have expected the problem to affect read() and write() too unless the file system is mounted with -nocluster*. > How can I provide more useful information? Check if the cp of large files actually works. A previous report mentioned data corruption but I don't remember it saying anything about panics. Maybe mmap() does something different that causes more serious corruption. I'll have to think more about adding debugging code to mmap() and the device driver. Meanwhile, can you try changing this code in msdosfs_vnops.c: %%% mp = vp->v_mount; maxio = mp->mnt_iosize_max / mp->mnt_stat.f_iosize; bnpercn = de_cn2bn(pmp, 1); %%% o Add a printf to print out maxio (might need rate limiting). o Try lower values of maxio until you find the largest one that works (keep dividing by 2. Only try one value per boot or per mount of course). I think it is always 128K initially, and small values will work. A value of the cluster size (typically 4K) or smaller should give the old behaviour. or one or more of the following: o Check that large i/o's to the raw device work. o Check for the problem with other file systems that implement clustering. ffs is easiest. o On an older version of FreeBSD that doesn't seem to have the problem, check for the problem with msdosfs with a large cluster size (the cluster can be up to 64K, which is large enough to show the problem that I suspect). Check on file systems that implement clustering too (now the block size doesn't need to be large to cause large i/o's). Bruce