Re: OT?: FAT32(/16?) Question: Max. files in top level

[<tomas@tuxteam.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Dec 31, 2016 at 05:14:50PM -0600, David Wright wrote:
> On Sat 31 Dec 2016 at 10:35:02 (+0100), tomas@tuxteam.de wrote:

[...]

> > Calculemus, as Leibnitz said. A bit of experimental informatics:

Mpfh. Seems I was a bit boisterous here :)

[...]

> > Try this at home. Enjoy.
> 
> I did, but I had some difficulty replicating your result. I took a USB
> stick and put a type c partition on it (mkfs.fat doesn't like writing
> whole devices). Then:

Thanks for trying to replicate. Didn't know about the device thing. Will
try when I've an USB stick which isn't my main backup :)

> #  mkfs.fat -i 20161231 -n PETROLEUM2G -r 2000 -v /dev/sdb1
> mkfs.fat 3.0.27 (2014-11-12)
> Auto-selecting FAT32 for large filesystem

OK, seems FAT32 has bigger limits (and it's actually selected when
the medium is big enough).

> /dev/sdb1 has 62 heads and 62 sectors per track,
> hidden sectors 0x0800;
> logical sector size is 512,
> using 0xf8 media descriptor, with 3891199 sectors;
> drive number 0x80;
> filesystem has 2 32-bit FATs and 8 sectors per cluster.
> FAT size is 3793 sectors, and provides 485447 clusters.
> There are 32 reserved sectors.
> Volume ID is 20161231, volume label PETROLEUM2G.
> # 
> 
> I now ran your one-liner and created over 20,000 empty files
> at top level. So I down-sized with:
> 
> # mkfs.fat -F 16 -i 20161231 -n PETROLEUM2G -r 2000 -v /dev/sdb1
> mkfs.fat 3.0.27 (2014-11-12)
> /dev/sdb1 has 62 heads and 62 sectors per track,
> hidden sectors 0x0800;
> logical sector size is 512,
> using 0xf8 media descriptor, with 3891199 sectors;
> drive number 0x80;
> filesystem has 2 16-bit FATs and 64 sectors per cluster.
> FAT size is 256 sectors, and provides 60789 clusters.
> There is 1 reserved sector.
> Root directory contains 2048 slots and uses 128 sectors.
> Volume ID is 20161231, volume label PETROLEUM2G.
> # 
> 
> and now at last I could exhaust the top level directory with
> 1023 entries. As expected, df -h gives
> /dev/sdb1       1.9G     0  1.9G   0% /media/petroleum2g

This is very interesting! Seems FAT32 has a limit of 1024 entries
in a top-level dir. OK, if all else fails, read the instructions :)

Wikipedia [1] has a very informative page: according to that, on
FAT12 and FAT16, the root directory is statically allocated, and
its maximum size is written somewhere in the file system header.
There are two bytes available for that (and the number encoded
there is "number of entries"), so that in theory there could be
up to 65K. Lo and behold, mkfs.vfat *has* a command line parameter
(-r) to set the number of root directory entries! Of course, I'd
expect any overall limit on entries per directory to apply here,
if there is any (couldn't find that out in that short time).

This all doesn't apply to FAT32 (as you had), where the root
directory is an ordinary directory. Why you got this 1024 limit
is thus still a mystery for me.

> Like Nicolas I couldn't unpick Gene's rant about the subject as he
> doesn't seem to distinguish between DOS, the OS, and FAT, the
> filesystem used by DOS. But I wouldn't expect anyone using DOS
> seriously to need to have many files in top level directories.
> If the OP is lucky, the photo frame might create a subdirectory
> like most cameras/phones etc do, or, like some MP3 players, just
> display everything it encounters regardless of the subdirectory
> involved.

Yeah, exactly. The only reason for FAT to exist these days is
compatibility, and then it makes sense to be especially conservative
(e.g. there's no limit to directory nesting depth, but most
implementations die on a path which is too long).

Anyway, thanks for digging further!

regards

[1] https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlho8s8ACgkQBcgs9XrR2kZlKwCdHLzpxBlW0Eju+lnt+3muUMce
EfQAn2QsVopodC3ZC7LNivJ5jXR8Ue2X
=W1Qy
-----END PGP SIGNATURE-----