Re: SMP/cc Cluster description

David S. Miller
2001-12-06T23:48:56Z

From: Larry McVoy <lm@bitmover.com>
Date: Thu, 6 Dec 2001 15:32:57 -0800

And, the ccCluster approach moves most of the nasty locking
problems into a ccCluster specific filesystem rather than buggering
up the generic paths.

I still don't believe this, you are still going to need a lot of
generic VFS threading. This is why myself and others keep talking
about ftruncate(), namei() et al.

If I look up "/etc" on bigfoot, littletoe, or whatever fancy name you
want to call the filesystem setup, SOMETHING has to control access to
the path name components (ie. there has to be locking).

You are not "N*M scaling" lookups on filesystem path components.
In fact, bigfoot sounds like it would make path name traversal more
heavyweight than it is now because these stripes need to coordinate
with each other somehow.

You keep saying "it'll be in the filesystem" over and over. And the
point I'm trying to make is that this is not going to do away with the
fundamental problems. They are still there with a ccCluster, they are
still there with bigfoot, and you are not getting N*M scaling on
filesystem name component walks.