Linux and Your USB Flash Drive

From Free Knowledge Base- The DUCK Project: information for everyone
Revision as of 10:54, 27 May 2019 by Admin (Talk | contribs)

Jump to: navigation, search

Flash memory: An EPROM, or erasable programmable read-only memory, is a type of computer memory chip that retains its data when its power supply is switched off. From this technology we have the modern solid state storage devices known as flash memory or memory cards, including thumb drives and flash drives.

The Thumb Drive

Most popular among the types of EPROM removable memory is the thumb drive, a flash drive that you plug directly into the computer USB port. Replacing the floppy disk from a time long ago, the modern thumb drive can hold magnitudes more data. The floppy drive is no longer practical for most applications. A thumb drive can be made to be bootable and is often used to install an operating system on a computer.

Installing Linux from a thumb drive onto a PC is probably the only time that the USB memory seems to function correctly. While working in a Linux desktop environment on a daily basis I have found the use of USB flash memory very problematic. Problems include:

  • File copy progress misreported, progress indicator in the file manager (all of them) shows completed in seconds while you wait for many minutes for the process to actually complete and the dialog to go away.
  • File drive rarely cleanly ummounts
  • Process frequently hangs for over a minute after the i/o activity completes. What is it doing? We have to wait for the dialog to go away even though its done!
  • Process fails on copying large files. Files of 1GB or greater often result in the progress interface showing complete but hanging up and not releasing the drive indefinitely. How long? I once let it sit overnight and it was still hung up in the morning. Linux would not even property shut down!

Why is USB flash memory support so flaky in Linux? It is difficult to determine the problem and cooperate with developers on a resolution due to factors including:

  • Linux zealots defend the kernel and deny the existence of a problem rather blaming the end user
  • Microsoft poorly documents FAT elements such as bit flags relating to corruption of the file system making it difficult for kernel developers to ensure compatibility
  • Linux desktop file managers failing to cope with the USB file system and relying on buggy kernel support
  • A new industry focus on so called cloud storage has demoted focus on attached / portable mass storage

Microsoft Windows Says Linux Corrupted My USB Drive

In ordinary cases and under circumstances where the file copy process went (as smooth as possible) on the Linux system, the flash drive being removed and attached to the Windows system may complain that it is necessary to "Repair this drive." Typically the drive does NOT need to be repaired even though Windows complains. The problem has to do with lack of Linux Kernel support for specific flags of a FAT32, FAT16, or NTFS filesystem. The Microsoft people won't provide clear documentation on specific flags and the Linux kernel developers are too stubborn to take the time and properly reverse engineer until full compatibility is realized.

Yes, it is a fact that Microsoft won't share, and even when they do, they provide bad information. However, flags such as ClnShutBitMask and HrdErrBitMask are not that difficult to reverse engineer based on simple observation of behavior. Linux kernel developers are too busy adding candy and crap to the kernel rather than stepping back and fixing long standing irritation problems such as USB drive support.

According to Microsoft:

  • ClnShutBitMask: If bit is 1, the volume is “clean”. The volume can be mounted for access. If bit is 0, the volume is “dirty” indicating that a FAT file system driver was unable to dismount the volume properly (during a prior mount operation). The volume contents should be scanned for any damage to file system metadata.
  • HrdErrBitMask: If this bit is 1, no disk read/write errors were encountered. If this bit is 0, the file system driver implementation encountered a disk I/O error on the volume the last time it was mounted, which is an indicator that some sectors may have gone bad. The volume contents should be scanned with a disk repair utility that does surface analysis on it looking for new bad sectors.