[SLL] limit on number of files in a directory and hashed dir vs. flat dir file access time
Chuck Wolber
chuckw at quantumlinux.com
Wed Oct 31 17:23:19 PDT 2007
On Wed, 31 Oct 2007, Adam Monsen wrote:
> Is there a limit on the number of files in a directory other than just
> the inode limit of a particular partition? I'm using the ext3
> filesystem. Ubuntu 7.10.
In old 2.4 kernels ext3 performanced inversely porportional to the number
of files in a given directory. So in that sense there was a limit. They
fixed that in 2.6 with a tree like data structure. "ls" will still perform
dog slow because it tries to grok the entire dir before outputting, but
file accesses should be fine.
As for a physical limit on the number of files in a directory, if there
is, it would probably have something to do with how many bits used to
represent the tree structure. That number is probably so astronomically
large that you'll probably exceed some other filesystem limit before you
hit it, but that's just a guess.
Have you tried asking that question on the ext3 developers list? I don't
know if this is the *OFFICIAL* list, but Theodore Tso posts there all the
time:
https://www.redhat.com/mailman/listinfo/ext3-users
Also, have you considered other types of filesystems for what you're
trying to do? IIRC ReiserFS actually has some advantages over ext3 for
lots of small files, or maybe that was xfs...
> Follow up question: is it more efficient (as far as reads are concerned) to
> "hash" files into subdirectories rather than just throw them all in a single
> directory? For instance, say I have 1 million 100 kilobyte JPEG images named
> as follows:
> 000000.jpg
> 000001.jpg
> 000002.jpg
> ...
> 999999.jpg
>
> Would it speed up read time for a particular image if images were placed in
> directories like:
>
> 0/0/0/0/0/1/000001.jpg and
> 0/2/3/6/1/2/023612.jpg
>
> and so on?
Not according to anything I've ever seen, but it's probably worth a test.
Perhaps traversing the logical tree in a directory might add *some*
overhead as the tree gets larger, but the 2.6 kernel really did fix a lot
of the annoying performance problems in ext. Chopping the images into a
directory hiearachy may make sense for other reasons though.
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"Stay Hungry. Stay Foolish."
-The Whole Earth Catalog
More information about the linux-list
mailing list