>From the point of view of the respective application developers, they
gain portability. People want to run INN and Squid on a lot of
platforms. OTOH, if Linux had an ideal filesystem on which to run
these apps, a lot of people might switch over to our camp.
A filesystem has a huge advantage in that all the traditional Unix tools
can be used; how are you going to back up your current news or cache
partition, convert it to a raw DBMS partition, and restore the backup?
Just as a thought, if a new filesystem were to keep a single huge hashed
directory, collapsing all subdirectories into it, the number of physical
disk accesses to open() a file would drop considerably (1/dir-hashnode,
2/file-inode, 3/file-data? Maybe even try to hash directly to the file's
inode number?).
For a special filesystem to be mounted at /usr/local/squid/cache or
/var/spool/news, we'd need to optimize to create a file, open and read
it, unlink it, and (for news only) hardlink it. Rarely if ever will a
file be modified, appended, or seeked (history and logs belong elsewhere).
The big problem with the collapsed directory structure is opendir().
Neither app uses this functionality, but it is useful for maintenance.
It might still be necessary to chain files together by directory so that
a random subdirectory can still be ls(1)'ed in reasonable time (or at
all). For purposes of find(1), it's tempting to just return the entire
filesystem at the mount point.
-- Anthony DeBoer <adb@onramp.ca>