Unioning file systems: Architecture, features, and design choices

Posted Mar 21, 2009 18:25 UTC (Sat) by jbailey (guest, #16890)
In reply to: Unioning file systems: Architecture, features, and design choices by nix
Parent article: Unioning file systems: Architecture, features, and design choices

Off the top of my head:

* To preserve the old syscall, we need to keep this functionality anyway.

* Retrieving directory entries could be expensive over wan links and such,
taking that huge hit on opendir might be a little much (How many times have
I done ls on a large dir and found myself hammering on C-c?)

* opendir sending me past my ulimit or available ram would be an
interesting DoS attack. Too many files, and you can't ls to figure out
what you should start deleting. No globs for you either. =)

If the interface could change, it might be nice to have a timelimit, and
throw an EINTR or some such on a seekdir that amounted to "suck it up and
start again."

Unioning file systems: Architecture, features, and design choices

Posted Mar 21, 2009 19:34 UTC (Sat) by nix (subscriber, #2304) [Link]

Ah, no. I mis-explained. I expect opendir() to do just what it does now:
but readdir()ing will remember the contents. (This is fine, because you
can't seekdir() to somewhere that you haven't telldir()ed, and you can't
telldir() something you haven't readdir()ed already.)

There's no DoS problem, because the application can keep an eye on the
amount of readdir()ing it's done, and stop if need be. It makes seekdir(),
even over NFS, a doddle, and retrieving dirents is no more expensive than
it is now.

I don't understand why glibc doesn't *already* implement this. Why on
earth is seekdir() the kernel's job?

(And, yes, we'd have to preserve the old syscall, but given the number of
users --- none on my system, two in the *entire* Debian source tree when I
counted it a few years ago --- I don't think anyone would care much, or
even notice, if it rotted gently into brokenness, or completely failed to
work on new filesystems.)