Re: OT?: FAT32(/16?) Question: Max. files in top level
On Sat 31 Dec 2016 at 10:35:02 (+0100), tomas@tuxteam.de wrote:
> On Thu, Dec 29, 2016 at 07:38:18AM +0100, Xen wrote:
> > doark@mail.com schreef op 26-12-2016 3:41:
> >
> > >I encountered this many times on windowz FAT32 in a non-root dir, but
> > >never on Linux. I suspect that it was/is one of their "Features". The
> > >said "Feature" still was there when using ntfs in XP if I remember
> > >correctly.
> >
> > Perhaps it's just because Windows Explorer doesn't deal well with
> > many files. Try to unpack some open source archive of some
> > distributor that had to make their sources open, some 1G archive,
> > and see how it goes. Not recommended :p.
> >
> > Then when you've unpacked it, deleting it takes a few years as well.
> > So imposing a filesystem limit may just have been a way to ensure
> > that their user interface limit is not quickly reached, I don't
> > know.
>
> Calculemus, as Leibnitz said. A bit of experimental informatics:
>
> dd if=/dev/zero of=dose bs=4096 count=64
> mkfs.vfat dose
> sudo mkfs.vfat dose
> sudo mount dose /mnt
> for i in $(seq 1 10000) ; do sudo touch /mnt/f.$(printf "%05d" $i) || echo "fail $i" ; done
>
> The loop starts failing at i == 257 with "no space left on device"
> (that's ENOSPC if I remember correctly). The "device" has still
> reams of space left:
>
> tomas@rasputin:~$ df -h
> Filesystem Size Used Avail Use% Mounted on
> [...]
> /dev/loop0 238K 0 238K 0% /mnt
>
> So 256 must be a limit on number of entries on the top level dir of
> FATty file systems (or an implementation limit of Linux's version
> of that, but guess whom I trust more to bust that badly).
>
> 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:
# 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
/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
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.
Cheers,
David.
Reply to: