>>>>> "pt" == Peter Tribble <peter.trib...@gmail.com> writes:
pt> Does it make sense to fold this sort of intelligence into the
pt> filesystem, or is it really an application-level task?
in general it seems all the time app writers want to access hundreds
of thousands of files by unique id rather than filename, and the POSIX
directory interface is not really up to the task. In theory there are
supposed to be all these hashed directories and decent performance
with huge directories, but in practice posters keep mentioning stupid
gotchya's like API's that enforce full scans of the directory even if
the filesystem itself doesn't, or lack of garbage collection so that
churning queue directories end up swollen with dead space. The usual
workaround for all gotchyas of making two-levels-deep nested subdirs
just means a couple extra seeks per subdir level before you reach your
inode number, extra seeks just to accomodate the overcomplex
filesystem API, so sometimes app developers end up rolling their own
filesystem-in-a-file like Hadoop instead just to get away from the
presumption they want filenames and nested directories. A uuid-subdir
interface, or directoryless uuid-filesystem option for 'zfs create',
might gather a lot of application consumers.
pgpbD3u8x7oya.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
