Ran an analogous process using reiserfs: mkdir -p /tmp/test/loop cd /tmp/test dd if=/dev/zero bs=1M count=1000 of=fs.img yes | mkfs.reiserfs -f fs.img sudo mount -o loop fs.img loop mkdir loop/tmp cd loop/tmp seq -f%07g 1 10000000 | xargs touch >& /dev/null ls -U | wc -l date tail -3 /var/log/kern.log df -i . df -h .
Here's the output from the last five commands: + ls -U + wc -l 1900000 + date Fri May 28 13:32:25 EDT 2010 + tail -3 /var/log/kern.log May 28 13:28:39 mnx-lucid kernel: [1562071.373264] REISERFS (device loop0): checking transaction log (loop0) May 28 13:28:39 mnx-lucid kernel: [1562071.394933] REISERFS (device loop0): Using r5 hash to sort names May 28 13:28:39 mnx-lucid kernel: [1562071.394971] REISERFS (device loop0): Created .reiserfs_priv - reserved for xattr storage. + df -i . Filesystem Inodes IUsed IFree IUse% Mounted on /dev/loop0 0 0 0 - /tmp/test/loop + df -h . Filesystem Size Used Avail Use% Mounted on /dev/loop0 1000M 230M 771M 23% /tmp/test/loop What's odd is that even though I specified 10 million files it only made 1.9 million. I don't know what's up with the inode reporting, but there is still plenty of space and there is no error in the kernel logs. Anyone got a recommendation for a filesystem that can hold 10+ million files in a single directory? Regards, - Robert On Wed, May 26, 2010 at 8:19 PM, Robert Citek <[email protected]> wrote: > Apparently, the size the filesystem is a factor, too. I doubled the > size of the filesystem to 2 GB and I had to double the number of files > to get the error. I would have expected the limit on the directory > size to remain constant. -- Central West End Linux Users Group (via Google Groups) Main page: http://www.cwelug.org To post: [email protected] To subscribe: [email protected] To unsubscribe: [email protected] More options: http://groups.google.com/group/cwelug
