Project

General

Profile

Bug #24816

Specify "-o large" when mounting MSDOS filesystems

Added by Carl-Daniel Hailfinger over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Critical
Assignee:
Bonnie Follweiler
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

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

ChangeLog Required:
No

Description

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.

freenas-import-usb-fat01.png (116 KB) freenas-import-usb-fat01.png Carl-Daniel Hailfinger, 06/25/2017 01:41 PM
freenas-import-usb-fat02.png (102 KB) freenas-import-usb-fat02.png Carl-Daniel Hailfinger, 06/25/2017 01:42 PM
Screen Shot 2017-11-17 at 11.34.50 AM.png (46.1 KB) Screen Shot 2017-11-17 at 11.34.50 AM.png Bonnie Follweiler, 11/17/2017 08:50 AM
11579
11580
13078

Related issues

Related to FreeNAS - Bug #19956: Import Disk status not shownClosed: Duplicate2017-01-02
Is duplicate of FreeNAS - Bug #25350: Import of Volume Failed.Closed: Duplicate2017-07-28
Has duplicate FreeNAS - Bug #25427: Unable to import NTFS driveResolved2017-08-02

Associated revisions

Revision f555c815 (diff)
Added by Vladimir Vinogradenko about 1 year ago

Fix mount_msdosfs: /dev/da1s7: Disk too big, try '-o large' mount option

Ticket: #24816

Revision 2374f702 (diff)
Added by Vladimir Vinogradenko about 1 year ago

Fix mount_msdosfs: /dev/da1s7: Disk too big, try '-o large' mount option

Ticket: #24816

History

#1 Updated by Carl-Daniel Hailfinger over 1 year ago

11579

#2 Updated by Carl-Daniel Hailfinger over 1 year ago

11580

#3 Updated by Carl-Daniel Hailfinger over 1 year ago

  • Category changed from 569 to 578
  • Seen in changed from Unspecified to 11.0
  • Hardware Configuration updated (diff)

#4 Updated by Xin Tan over 1 year ago

  • Category changed from 578 to 76
  • Assignee deleted (Xin Tan)

#5 Updated by Carl-Daniel Hailfinger over 1 year ago

  • Private changed from Yes to No

#6 Updated by Carl-Daniel Hailfinger over 1 year ago

Using the shell in the GUI, mounting the FAT partition manually and copying data off the partition into the local ZFS pool works just fine. This suggests it's a software issue, not a hardware issue.

@Xin Tan:
Any logs I can supply?

#7 Avatar?id=14398&size=24x24 Updated by Kris Moore over 1 year 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 over 1 year 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.

#9 Updated by William Grzybowski over 1 year ago

  • Assignee changed from William Grzybowski to Suraj Ravichandran
  • Target version set to 11.0-U2

There should be some. It may have broken with py3.

Suraj wrote this feature, can you take a look at that, please?

#10 Updated by Suraj Ravichandran over 1 year ago

  • Status changed from Unscreened to Screened
  • Priority changed from No priority to Important

#11 Updated by Carl-Daniel Hailfinger over 1 year ago

Any logs I can supply?

#12 Updated by Vaibhav Chauhan over 1 year ago

  • Target version changed from 11.0-U2 to 11.0-U3

#13 Avatar?id=14398&size=24x24 Updated by Kris Moore over 1 year ago

  • Status changed from Screened to 46

Suraj - Any status update on this one?

#14 Updated by Suraj Ravichandran over 1 year ago

  • Status changed from 46 to Screened

Not as yet, I'll work on this next week

#15 Updated by Dru Lavigne over 1 year ago

  • Assignee changed from Suraj Ravichandran to William Grzybowski
  • Target version changed from 11.0-U3 to 11.1

Suraj: punting to 11.1.

William: please load balance between Vladimir and Nikola.

#16 Updated by William Grzybowski over 1 year 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.

#17 Updated by William Grzybowski over 1 year ago

Actually, 2to3 was probably fixed in https://github.com/freenas/freenas/pull/271, so only remaining thing would be the rewrite to middleware plugin.

#18 Updated by William Grzybowski over 1 year ago

  • Is duplicate of Bug #25350: Import of Volume Failed. added

#19 Updated by Vladimir Vinogradenko over 1 year ago

  • Status changed from Unscreened to Fix In Progress

#20 Updated by William Grzybowski over 1 year ago

  • Related to Bug #19956: Import Disk status not shown added

#21 Updated by Vladimir Vinogradenko over 1 year ago

  • Status changed from Fix In Progress to Needs Developer Review

#22 Updated by William Grzybowski over 1 year ago

  • Status changed from Needs Developer Review to Reviewed by Developer

#23 Updated by Vladimir Vinogradenko over 1 year ago

  • Status changed from Reviewed by Developer to Ready For Release

#24 Updated by Dru Lavigne over 1 year ago

  • Status changed from Ready For Release to 46

Vladimir: is this a duplicate of #25497? In other words, was any new code added to address this ticket or should we close it as a duplicate?

Also, does a middleware plugin need to be rewritten as per comment #17?

#25 Updated by Dru Lavigne about 1 year ago

  • Has duplicate Bug #25427: Unable to import NTFS drive added

#26 Updated by Dru Lavigne about 1 year ago

  • Status changed from 46 to Closed: Duplicate
  • Target version changed from 11.1 to N/A

#27 Updated by Carl-Daniel Hailfinger about 1 year ago

  • QA Status Test Fails added
  • QA Status deleted (Not Tested)

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.

#28 Updated by Carl-Daniel Hailfinger about 1 year ago

  • Seen in changed from 11.0 to 11.0-U3

#29 Updated by Dru Lavigne about 1 year ago

  • Status changed from Closed: Duplicate to 15
  • Target version deleted (N/A)

Carl-Daniel: can you please verify that the issue persists in U4 (which was released yesterday).

Vladimir: please check comment #27 and sync with Bonnie regarding the failed QA test.

#30 Updated by Vladimir Vinogradenko about 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.

If I understand correctly,
  • this is not a mount bug: user should specify -o large himself
  • specifying -o large for any msdosfs filesystem (I've tested with 10MB one) won't break anything

So fix is simple: we can always specify -o large when mounting msdosfs filesystems.

This is definitely present in 11.0-U4

#31 Updated by Dru Lavigne about 1 year ago

  • Status changed from 15 to Screened
  • Assignee changed from Dru Lavigne to Vladimir Vinogradenko

#32 Updated by Vladimir Vinogradenko about 1 year ago

  • Status changed from Screened to Needs Developer Review
  • Assignee changed from Vladimir Vinogradenko to William Grzybowski
  • Target version changed from N/A to 11.1

#33 Updated by William Grzybowski about 1 year ago

  • Status changed from Needs Developer Review to Reviewed by Developer
  • Assignee changed from William Grzybowski to Vladimir Vinogradenko

#34 Updated by Vladimir Vinogradenko about 1 year ago

  • QA Status Not Tested added
  • QA Status deleted (Test Fails)

#35 Updated by Vladimir Vinogradenko about 1 year ago

  • Status changed from Reviewed by Developer to Ready For Release

#36 Updated by Carl-Daniel Hailfinger about 1 year ago

Wow, that was quick! Thank you.

#37 Updated by Dru Lavigne about 1 year ago

  • Subject changed from Importing FAT partition from external USB 3.0 disk hangs forever to Specify "-o large" when mounting MSDOS filesystems
  • Target version changed from 11.1 to 11.1-BETA1

#38 Updated by Dru Lavigne about 1 year ago

  • Status changed from Ready For Release to Resolved

#39 Updated by Bonnie Follweiler about 1 year ago

13078

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.

#40 Updated by Bonnie Follweiler about 1 year ago

  • File debug-bonniemini-20171117085147.tgz added

I have the 3.0 USB drive with a little over 15 GB on it still in the machine and it is available for you to take a look at
10.231.1.76
root:abcd1234

#41 Updated by Vladimir Vinogradenko about 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

#42 Updated by Bonnie Follweiler about 1 year ago

  • Needs QA changed from Yes to No
  • QA Status Test Passes FreeNAS added
  • QA Status deleted (Not Tested)

#43 Updated by Dru Lavigne about 1 year ago

  • Status changed from 15 to Resolved

#44 Updated by Dru Lavigne about 1 year ago

  • File deleted (debug-bonniemini-20171117085147.tgz)

Also available in: Atom PDF