Date: Thu, 24 Apr 2008 13:57:04 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Dominic Fandrey <kamikaze@bsdforen.de> Cc: freebsd-bugs@FreeBSD.org, gavin@FreeBSD.org, bug-followup@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: kern/122961: write operation on msdosfs file system causes panic Message-ID: <20080424133415.G70715@delplex.bde.org> In-Reply-To: <480F9E0F.3010803@bsdforen.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080424133415.G70715>