> [W]hen trying to add a 32767th directory, I got the error message: > "Too many links".
As others have said, this is because link counts are 16 bits, and someone at some point didn't want to deal with making them unsigned. > When my tools reads only the single indirect blocks, it get all 32767 > subdirectories. Your subdirectory names are comaratively short. > [W]hy does dump iterate the indirect blocks, when looking for > subdirectories? Because it may need to. A directory may contain entries other than subdirectories. Since there is no enforced ordering of entries in a directory, the whole directory must be read to find all the subdirectories (unless 32767 subdirs are found first, I suppose, which is unlikely in practice); there could always be a subdirectory lurking out at the end of the directory. Since directories can be arbitrarily large (adding things other than subdirectories does not increase the directory's link count), they may involve double indirect blocks. (In theory, even triple indirect blocks, though that would mean a directory over 4299210752 bytes long (or more if filesystem blocks are bigger than 4K), which is difficult to test.) Even if the directory contains nothing but subdirectories, a directory holding 32767 max-size directory entries on a filesystem with 4K blocks will overflow single indirect blocks. (Using directory entries as large as possible and blocks as small as possible: a directory entry can be as large as 264 bytes, 256 bytes of padded name plus 8 bytes of overhead, so only one entry fits per DIRBLKSIZE directory block. On a 4K-block filesystem, a single indirect block holding 1K block numbers, so the single indirect block runs out at 4096*(12+1024)=4243456 bytes of directory, which is only 8288 DIRBLKSIZE blocks, or 8288 max-size directory entries.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
