Specify "-o large" when mounting MSDOS filesystems
Dell T20, 12 GB ECC RAM, CPU Intel Xeon E3-1225 v3, Chipset Intel C226,
external Toshiba Stor.E Basics USB 3.0 1 TB HDD
When trying to import contents from a FAT partition on an external USB 3.0 hard disk, the "Import Disk" GUI doesn't show any progress. The Reporting section of the GUI shows that no data is read from the external disk.
Fix mount_msdosfs: /dev/da1s7: Disk too big, try '-o large' mount option
#7 Updated by Kris Moore almost 2 years ago
- Assignee set to William Grzybowski
This sounds like something we'd have to investigate for 11.2 or later in the new UI. William, is there even any progress reporting we can get? I assume its doing file-copies, so we'd almost have to list the entire media and then throw up the counter as files are copied by (assuming we are doing one-by-one copies and not some bulk "cp -r" type setup.
#8 Updated by Carl-Daniel Hailfinger almost 2 years ago
According to the FreeNAS built-in monitoring graphs, the source disk has some minor read access in the beginning, then the read activity drops to zero. I'd have expected ~80 MB/s continuous reads for almost 3 hours (800 GB data on the source disk).
Judging by the monitoring output, the copy process is either not started at all or it hangs directly after being started.
#16 Updated by William Grzybowski almost 2 years ago
- Category changed from 129 to Middleware
- Status changed from Screened to Unscreened
- Assignee changed from William Grzybowski to Vladimir Vinogradenko
- Priority changed from Important to Critical
Vladimir, there is probably something wrong with the sockscopy script Suraj wrong (might be an easy 2to3 conversion error).
However, this might be an interesting project to get you started on the middlewared, and rewrite it in a middleware plugin.
#24 Updated by Dru Lavigne almost 2 years ago
- Status changed from Ready For Release to 46
#27 Updated by Carl-Daniel Hailfinger over 1 year ago
- QA Status Test Fails added
- QA Status deleted (
This is not fixed in 11.0-U3.
I can still reproduce, and it still fails exactly the same way.
I have managed to find the bug:
/usr/local/bin/sockscopy line 216:
mount(data_dict["volume"], src, 'ro', fstype)
This fails for any reasonably large FAT32 volume with the following error message:
Sep 25 22:40:13 nas /sockscopy: [sockscopy:316] Import of Volume /dev/da1s7 encoutered the following error Error occured whilst mounting /dev/da1s7 as msdosfs filesystem. Error Mount failed 1 -> , mount_msdosfs: /dev/da1s7: Disk too big, try '-o large' mount option: Invalid argument
Whether that's a FreeBSD mount bug for not automatically choosing the right mount option or a FreeNAS sockscopy bug for not guessing the right parameters for mount is probably a matter of debate.
#30 Updated by Vladimir Vinogradenko over 1 year ago
- Assignee changed from Vladimir Vinogradenko to Dru Lavigne
- Target version set to N/A
This is different bug that was present in
sockscopy and migrated to middleware plugin.
- this is not a
mountbug: user should specify
-o largefor any
msdosfsfilesystem (I've tested with 10MB one) won't break anything
So fix is simple: we can always specify
-o large when mounting
This is definitely present in 11.0-U4
#39 Updated by Bonnie Follweiler over 1 year ago
- File Screen Shot 2017-11-17 at 11.34.50 AM.png Screen Shot 2017-11-17 at 11.34.50 AM.png added
- Status changed from Resolved to 15
Vladimir, In order to test this, I formatted a USB as a MSDOS (FAT32). I copied some files over to it and then tried to Import Disk to verify that it was fixed. I got an error message: "The selected disks were not verified for these import rules. Filesystem check failed." (screen shot provided)
The destination dataset is a Windows share with no set quota.
#41 Updated by Vladimir Vinogradenko over 1 year ago
- Assignee changed from Vladimir Vinogradenko to Bonnie Follweiler
Filesystem on that partition is recognized as damaged
root@bonniemini:~ # /sbin/fsck_msdosfs -p /dev/da0p2 /dev/da0p2: Invalid signature in fsinfo block backup (block 6) mismatch with primary bootblock: /dev/da0p2: UNEXPECTED INCONSISTENCY; RUN fsck_msdosfs MANUALLY. root@bonniemini:~ # echo $? 8
Please test that it can still be mounted in Windows