I think it might, as far as I know filers still use inodes, and it seems that the nested levels would be what would cause the problems here...but since they are going to increase the number of blocks then can address at the ^2 of the number of inodes deep I'm surprised this would cause performance issues. Adam probably can give you a 100% answer.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of David Lee Sent: Wednesday, July 19, 2006 10:37 AM To: toasters@mathworks.com Subject: directory efficiency
(Is the following an FAQ? If so, apologies, point me in the right direction...)
In years gone by, on a typical UNIX filesystem, creating entries (e.g. new files) in a directory could become badly inefficient as that directory size increased. By the time that (for instance) a "/var/spool/mail" reached (say) 20,000 entries, the acts of creating and deleting lockfiles in that directory could seriously impede things. (As a consequence, various sites devised various workaround; for instance we split into 100 subdirectories based on "uid mod 100", so that each subdir was only around (say) 200 entries.
When we migrated this to NetApp a couple of years back, we simply kept this subdivision in place. But now another consideration is coming into play which would be eased if we could consider reverting to the single large (~20,000 entry) directory.
Do such efficiency considerations matter in NetApp WAFL?