Max files in unix folder from PIL process

[Corey Brune]

On Mon, 28 Mar 2005 21:25:28 -0400, David Pratt <fairwinds at eastlink.ca> wrote:
> Hi.  I am creating a python application that uses PIL to generate
> thumbnails and sized images. It is beginning to look the volume of
> images will be large. This has got me to thinking.  Is there a number
> that Unix can handle in a single directory. I am using FreeBSD4.x at
> the moment. I am thinking the number could be as high 500,000 images in
> a single directory but more likely in the range of 6,000 to 30,000 for
> most. I did not want to store these in Postgres.  I will most likely to
> break these into directories by size ie. thumbnail, small, medium,
> large, etc. .  That will at least take it down by a factor of the
> number of sizes used but still the possibility of a very large number
> (maximum to perhaps 100,000 or more) There is really no other way that
> I can think of to categorize these at  the moment.   Should this pose a
> problem on the filesystem?  How will it affect the use of Unix tools?
> Will there be access problems that affect speed? This is unchartered
> territory for me so hope someone who has been there, done that can
> provide some of what they learned from experience.  Many thanks.
> 
> Regards,
> David
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 


I've had apps that had over 800k subdirectories and files. As long as
you know the filename, performance will not be an issue. However, if
you don't know the full path, then you may want to either redesign the
app or consider storing everything in the DB. The apps that I've seen
had the full path stored in the database, and the image on a file
server.

I've also had apps that stored everything in the database, and that
turned out to be a nightmare. Eventually, we moved everything from the
DB to the filesystem.

Corey