Comment 53 for bug 133567

Hello,

I am a Debian user, but got the same problem when testing a recent vanilla kernel release.

Asking the source of knowledge seems to be always the best way... This is the response from FAT kernel developer (available in MAINTAINERS file in kernel sources' root):

>Thanks for report. This is known issue.
>
> This slowdown is a necessary to avoid the "free clusters" issue, we
> can optimize it more or less although.
>
> If the partition is shared with recent Windows, Windows may write the
> wrong "free clusters" value. Then if you are not using "usefree" (IOW
> if you are enough with previous behavior, you can use "usefree"
> option), FAT may display and assume the wrong free space.
>
> It means FAT will stop to write at "free clusters" == 0, even if there
> is the free space actually.

In fact, that option is documented in file /Documentation/filesystems/vfat.txt (in kernel sources' root, at least for last development kernel release):

> VFAT MOUNT OPTIONS
> (...)
> usefree -- Use the "free clusters" value stored on FSINFO. It'll
> be used to determine number of free clusters without
> scanning disk. But it's not used by default, because
> recent Windows don't update it correctly in some
> case. If you are sure the "free clusters" on FSINFO is
> correct, by this option you can avoid scanning disk.

Maybe "mount" man page should be updated.