ext3 и десятки тысяч файлов в директории - будет ли падение производительности?

По моему опыту после миллиона где-то начинается падение производительности. Тогда надо будет переносить на XFS. У меня она 18 лимонов в одной папке жует и не жалуется.

Тогда надо будет переносить на XFS

Если VPS на OpenVZ, то только ex4, так как остальное (кроме ext3, и та не полностью - ploop не работает) не поддерживается.

Historically, ext2/3 directories have used a simple linked list, ... While it might be expected that the O(n) lookup times would be a significant performance issue, the Linux VFS-level directory cache mitigated the O(n) lookup times for many common workloads.

To address these concerns, we designed a radically simplified tree structure that was specifically optimized for filesystem directories

«HTree», uses 32-bit hashes for keys, where each hash key references a range of entries stored in a leaf block. Since internal nodes are only 8 bytes, HTrees have a very high fanout factor (over 500 blocks can be referenced using a 4K index block), two levels of index nodes are sufficient to support over 16 million 52-character filenames. To further simplify the implementation, HTrees are constant depth (either one or two levels). The combination of the high fanout factor and the use of a hash of the filename, plus a filesystem-specific secret to serve as the search key for the HTree, avoids the need for the implementation to do balancing operations.

This feature was extremely well received, since for very large directories, performance improvements were often better by a factor of 50-100 or more.

While the HTree algorithm significantly improved lookup times, it could cause some performance regressions for workloads that used readdir() to perform some operation of all of the files in a large directory. This is caused by readdir() returning filenames in a hash-sorted order, so that reads from the inode table would be done in a random order.

Написал бы, откуда цитата.