On Mon, 18 Jun 2007, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but will not get polished for
users or have a full set of features implemented (e.g. ACL, quota, fsck,
etc). While I don't think there is a single answer to every question,
it does seem that the number of filesystem projects has climbed lately.
I view some of the attempts for "from scratch" filesystems as ways of
testing out various designs as "proof-of-concepts". It's a great way
of demo'ing ones ideas, to see how well they work. There is a huge
chasm between a proof-of-concept and a full production filesystem that
has great repair/recovery tools, etc. That's why it's so important to
do the POC implementation first, so folks can see how well it works
before investing a huge amount of effort to make it be
production-ready.
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
(Forked filesystems tend to be fragile and do not play well with
non-forked filesystems.)
So I actually think the number of these new filesystem proposals are
*good* things. It means people are interested in creating new
filesystems, and that's all good. Eventually, we'll need to decide
which design ideas should be combined, and that may be a little tough
to the egos involved, but that's all part of the darwinian kernel
programming model. Not all implementations make it into the kernel
mainline. That doesn't mean that the work that was done on the
various schedular proposals were useless; they just helped demonstrate
concepts and advanced the debate.
I would like to see more clarification from the designers as to what
problem they are trying to solve. Some of the goals seem to be laudable,
but some are not problems that I worry about.
I see filesystems that are trying to handle the flakeyness of hardware.
That is useful to me. I also see people who are trying to archive every
little change for "legal reasons". I have a hard time with this one
because I have a hard enough time keeping spare hard drive space for the
stuff I want, not the space that someone else wants me to keep.
What I really want are high throughput systems where I can write and read
as fast as the hardware will allow. (And then I want faster hardware.)
--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
