On Tue, 29 Jun 1999 14:23:11 +0000 (/etc/localtime), Hans Reiser
<reiser@ceic.com> said:
> I think we are speaking past each other. Any time something like
> structured storage comes along, it means that the filesystem has failed
> the developer, otherwise he wouldn't bother.
That's not _necessarily_ true. You could as easily say that:
any time something like
the internet
the http protocols
xml encoding
ELF binary formats
the coda distributed filesystem
comes along, it is because our local disk filesystem has failed.
I'm not trying to argue against solving problems. I'm trying to argue
for solving them in the right place.
You say we need filesystem support for GUIs. But when I point out that
I _need_ my home directory to run over NFS, I'm just a stick-in-the-mud?
Hans, with 95% of the Linux developers I deal with, I can point out
problems and engage in a constructive argument about how to solve them.
`
> Now you say to me that my being the only file system that doesn't fail
> the developer isn't useful, and I say, the developer shouldn't use the
> other file systems.
That's part of the problem. If you continue to dismiss existing
practice out-of-hand, then it is your new features which I won't use.
> As for NFS, if it's broken, let's fix it. And if the vendors on the
> NFS standards committee use their leverage to delay support until
> their filesystems catch up, then ignore the standards committee or
> obsolete NFS.
This is exactly the attitude which is the problem. NFS is _not_ broken:
you are just claiming that anything which isn't your solution is
broken. That's hardly constructive.
Now, what we _could_ do is to provide a user-space library stub for
other NFS clients which translates O_DIRECTORY() opens to a file into an
open of something like "filename/.%%pseudodir%%", and have an NFS server
which detects that pseudoname and munges it into an O_DIRECTORY open on
the server side.
See? Suddenly we are able to pass these calls over NFS while still
doing something useful with local filesystem semantics. That's the sort
of thing I would like to see us talking about. Simply dismissing all of
existing practice as irrelevant and broken just doesn't get us any
further, I'm afraid.
> I am sorry Stephen, but you keep harping on the cost of change, I keep
> harping on the benefit of change, and we will never convince each
> other.
You keep harping on the benefit of change without appearing ever to
address questions about where the change is best applied. That is a
serious problem. The cost of making the wrong change is that you just
won't persuade people to follow. I hear too much from you that sounds
like "we can solve it in the filesystem, therefore it is broken to solve
it anywhere else". I just don't buy that argument.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/