Re: FAT32 statfs(2) inode usage

On Mon, 6 Mar 2023, at 11:46 AM, Stefan Esser wrote:
>
> Hi Ben,
>
> even if you write FAT32 in the subject, I'd want to ask whether this really
> is a FAT32 file system or rather FAT12 or FAT16?
>
> The reason I ask is that there is no limit on the number of files (reported
> as inodes) in the root directory of a FAT32 file system, but such a limit
> does exist in FAT12/FAT16 and the default value happens to be 512 in case
> of FAT16.

Hi Stefan, thanks for taking the time to write a detailed and very useful response.

You are correct - it turns out this is a FAT16 file system:
$ file -s /dev/nvd0p1
/dev/nvd0p1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4  ", sectors/cluster 32, root entries 512, sectors/FAT 65, sectors/track 63, heads 255, sectors 532480 (volumes > 32 MB), serial number 0x27890a16, unlabeled, FAT (16 bit)

This was created by bsdinstall - and now I'm thinking we should change the FreeBSD installer to use FAT32 by default for ZFS installs with UEFI, given the EFI system partition (ESP) is being created as 260MB.
https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/zfsboot?h=release/13.1.0#n843

>
> For FAT16 the exhaustion of root directory entries could be seen as an
> issue similar to no free inodes in a Unix file system, but it would only
> prevent the creation of new files at the root directory level.
>
> It is highly unlikely that you run into that limit unless you do actually
> store lots of files in the root directory, and then hitting that limit might
> look similar to inode exhaustion on a Unix file system (freespace, but no
> new files can be created).

Really helpful information - thank you.

>> I think it might be more correct for msdosfs_vfsops.c to set the f_files variable to 0. Thoughts on this change?
>
> If you tend to fill up your FAT12/FAT16 root directory, then a warning about
> that directory being filled is quite useful, since if there already are more
> than 100 files it is likely that you are adding more and more files at the
> root directory level. When working with sub-directories, you'll probably
> never come near to that limit.
>
> Regards, STefan

I think my issue stems from the fact that the msdosfs_vfsops.c code is using the f_files limit variable to represent the FAT root directory entities limit, but is not using the corresponding f_ffree available variable to represent the current number of root directory entities. This leads to the df(1) output incorrectly implying that the number of root directory entities is at capacity.

To avoid this confusion, I think the msdosfs_vfsops.c should either set both the f_files and f_ffree statfs variables so that df(1) correctly reports %iused, or should set them both to zero so that df(1) shows %iused as "-".

Thoughts?

-- 
From: Ben Woods
woodsb02@freebsd.org