On Sun 01 Jan 2017 at 13:15:11 (+0100), to...@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), to...@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.
