] Terry Lambert writes:
]
] > I don't understand the inability to perform the trivial
] > design engineering necessary to keep from needing to put
] > 60,000 files in one directory.
] >
] > However, we can take it as a given that people who need
] > to do this are incapable of doing computer science.
]
] One could say the same about the design engineering necessary
] to handle 60,000 files in one directory. You're making excuses.
No, I'm not. I released trie patches for FreeBSD directory
sotrage in 1995.
No one thought they were very useful, because only morons
would treat a filesystem as if it were a database, instead
of using a database as a database.
If you want to get technical, a filesystem is a form of a
database... but it's a _hierarchical_ database, like DNS or
LDAP, and trying to use it as a _relational_ database, with
key/value pairs, is still a stupid idea. Use the right tool
for the job.
] People _want_ to do this, and it often performs better on
] a modern filesystem. This is not about need; it's about
] keeping ugly hacks out of the app code.
]
] http://www.namesys.com/5_1.html
I'm glad you said "people want to do this" instead of saying
"computer professionals want to do this".
The 60,000 file "benchmark" is meaningless to a properly
designed system.
] > (the rationale behind this last is that people who can't
] > design around needing 60,000 files in a single directory
] > are probably going to to be unable to correctly remember
] > the names of the files they created, since if they could,
] > then they could remember things like ./a/a/aardvark or
] > ./a/b/abominable).
]
] Eeew. "./a/b/abominable" is a disgusting old hack used to
] work around traditional filesystem deficiencies.
No, it's a hack to work around being too damn lazy to use
a database where it makes sense to use a database.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
