Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #176166

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

Show all headers | View raw

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.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: OT?: FAT32(/16?) Question: Max. files in top level Xen <list@xenhideout.nl> - 2016-12-29 07:40 +0100
  Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2016-12-31 10:40 +0100
    Re: OT?: FAT32(/16?) Question: Max. files in top level Gene Heskett <gheskett@shentel.net> - 2016-12-31 14:00 +0100
      Re: OT?: FAT32(/16?) Question: Max. files in top level Nicolas George <george@nsup.org> - 2016-12-31 14:10 +0100
        Re: OT?: FAT32(/16?) Question: Max. files in top level Gene Heskett <gheskett@shentel.net> - 2016-12-31 15:00 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level Richard Owlett <rowlett@cloud85.net> - 2016-12-31 15:20 +0100
            Re: OT?: FAT32(/16?) Question: Max. files in top level Gene Heskett <gheskett@shentel.net> - 2016-12-31 16:40 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level Nicolas George <george@nsup.org> - 2016-12-31 16:40 +0100
        Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2016-12-31 16:30 +0100
    Re: OT?: FAT32(/16?) Question: Max. files in top level David Wright <deblis@lionunicorn.co.uk> - 2017-01-01 00:30 +0100
      Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2017-01-01 13:20 +0100
        Re: OT?: FAT32(/16?) Question: Max. files in top level David Wright <deblis@lionunicorn.co.uk> - 2017-01-02 15:40 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level Jude DaShiell <jdashiel@panix.com> - 2017-01-02 16:30 +0100
            Re: OT?: FAT32(/16?) Question: Max. files in top level Nicolas George <george@nsup.org> - 2017-01-02 16:30 +0100
              Re: OT?: FAT32(/16?) Question: Max. files in top level rhkramer@gmail.com - 2017-01-02 17:40 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2017-01-02 20:50 +0100
    Re: OT?: FAT32(/16?) Question: Max. files in top level Xen <list@xenhideout.nl> - 2017-01-01 12:50 +0100

csiph-web