3

If I put a USB memory stick (FAT formatted) into a Windows PC, then unplug it without "ejecting" it, then put it in again, Windows is okay with that, without giving any warning about it "possibly having problems".

But if I do the same with Linux (e.g. Ubuntu 15.04), then after inserting it the second time, I get warning messages in the log like:

FAT-fs (sdf1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

And if I subsequently put it in a Windows PC, I get a message popping up prompting me to check it for errors.

Why is Linux handling of the FAT "dirty" flag so basic? I would have thought it would be better to only set the "dirty" flag if it really is potentially "dirty" -- e.g. something like:

  • Set the "dirty" flag when a file is written.
  • Clear the "dirty" flag when:
    • all written files are closed, and/or
    • the write cache is written out to disk,
    • and of course, when the disk is unmounted.

It would be nice if there was at least some mount option to operate in that mode, to reduce the chance of users getting "dirty" flag false alarms for merely plugging and unplugging a removable device, even though nothing was actually written.

7

My C is rough but it looks like the fat dirty bit is set when the superblock is read (this commit explains why it was implemented the way it was).

Windows may choose to not set the bit until after something is changed in the FS where linux takes a bit more paranoid approach of setting it upon mount.

To me it seems like it's more efficient this way, to assume dirty after mount and unset upon clean unmount, otherwise the kernel would have to track the dirty/clean state of the volume and check if it needs to be set on each write.

As you can see in the code and the commit comment; you can mount RO and the bit will not be changed.

  • 2
    That commit message is a gem; thanks for finding it. It would be nice if Linux at least did the same as Windows 7 (set dirty flag on first write and remove it on umount.) – Craig McQueen Sep 17 '15 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.