Re: OT?: FAT32(/16?) Question: Max. files in top level
On Sun 01 Jan 2017 at 13:15:11 (+0100), tomas@tuxteam.de wrote:
> 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
This was intended to create a FAT16 filesystem...
> > 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 :)
... so I think you mean FAT16 here.
> 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.
So no mystery, perhaps.
> > 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
Cheers,
David.
Reply to: