Date: Thu, 24 Apr 2008 06:30:40 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-bugs@FreeBSD.org, gavin@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/122961: write operation on msdosfs file system causes panic Message-ID: <48100CF0.9080708@bsdforen.de> In-Reply-To: <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> <20080424133415.G70715@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > 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. If it really is of help, I will downgrade. Not before the weekend, though. >> 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 copied a 1.2gb DVD rip and watched it afterwards. No corruption. Md5 checksums show that the file on the stick and the original are identical. > 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. I will give it a try. > 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 > These ones are harder. I will also defer them to the weekend.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48100CF0.9080708>