Date: Mon, 2 Jan 2017 09:32:33
From: David Wright <deblis@lionunicorn.co.uk>
Reply-To: debian-user@lists.debian.org
To: debian-user@lists.debian.org
Subject: Re: OT?: FAT32(/16?) Question: Max. files in top level
Resent-Date: Mon, 2 Jan 2017 14:37:55 +0000 (UTC)
Resent-From: debian-user@lists.debian.org
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.