Re: Problem in msdosfs_moutfs
On Tue, 15 Jul 2014, Matthias Drochner wrote: While we are here... (Sorry, I'm too busy with other things, otherwise I'd do it myself.) I found that msdosfs mount fails for some pre-formatted USB thumb drives due to a too strict bpb check. See attachment, but it might make sense to find another limit, or to kill pm_SecPerTrack completely. Aiui, the =63 limit makes only sense if the file system is used to boot from, without int13 extensions. One can safely assume that a PC with USB ports also implements int13 extensions... Is this the failure where you see pre-formatted USB storage with the MBR partition size correct, but offset by a sector so that it appears to extend beyond the end of the device (even though the FAT does not extend into that range) and so it is rejected? -- Stephen
Re: Problem in msdosfs_moutfs
In article 336424c1a5a44044b29030055527aa75049f8a5...@ausx7mcps301.amer.dell.com, gerald_...@dell.com wrote: -=-=-=-=-=- We have a function that mount/umounts a file system a part of a sanity check. When the operation is done rapidly(you really don't want to know) it uncovers a problem with mounting a raw device with a block size less than 1KiB (size of the on disk data structure). The code always reads a block (pmp-pm_BytesPerSec), the problem comes when the buffer is the last one in a page, and the following page is not mapped. The code reads beyond the 512 bytes in the original read, causing a seg fault in our case. I don't understand why the code doesn't insure the read to be minimum of the structure being read from the device. I tried to send this once before, but appear to have mucked it up. For now we have a working fix/ Discussed the change with Matt, resulting in the following diff: Fixed, thanks! christos
Re: Problem in msdosfs_moutfs
While we are here...
(Sorry, I'm too busy with other things, otherwise I'd do it myself.)
I found that msdosfs mount fails for some pre-formatted USB thumb drives
due to a too strict bpb check. See attachment, but it might make sense
to find another limit, or to kill pm_SecPerTrack completely.
Aiui, the =63 limit makes only sense if the file system is used to
boot from, without int13 extensions. One can safely assume that a PC
with USB ports also implements int13 extensions...
best regards
Matthias
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
# HG changeset patch
# Parent 57c15f727f2caa91ee4cac3bc51096ef5b311b40
diff -r 57c15f727f2c -r 62d8682d656d sys/fs/msdosfs/msdosfs_vfsops.c
--- a/sys/fs/msdosfs/msdosfs_vfsops.c Thu Feb 06 18:37:08 2014 +0100
+++ b/sys/fs/msdosfs/msdosfs_vfsops.c Thu Jun 05 19:50:47 2014 +0200
@@ -556,7 +556,7 @@
if (!(argp-flags MSDOSFSMNT_GEMDOSFS)) {
/* XXX - We should probably check more values here */
if (!pmp-pm_BytesPerSec || !SecPerClust
- || pmp-pm_SecPerTrack 63) {
+ /*|| pmp-pm_SecPerTrack 63*/) {
DPRINTF((bytespersec %d secperclust %d
secpertrack %d\n,
pmp-pm_BytesPerSec, SecPerClust,
