-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hans Reiser wrote:
> Jeff Mahoney wrote:
>> 1) Because then the behavior of /proc/fs/reiserfs/ would be
>> inconsistent. Devices that contain slashes end up being one level deeper
>> than other devices, which is silly and a userspace visible change.
>
> And you think translating / to ! is less work for user space?
A one line s#/#!# to access devices they couldn't before versus now
having to deal with going deeper into a tree for no real reason? Yes, I do.
>> Tools
>> that wish to parse the information would then need added complexity to
>> traverse into the next level to reach that information.
>>
>> 2) The block-device-as-path-name-component behavior is already defined
>> by sysfs (/sys/block), and it should be consistent.
>
> Translate that as, "I won't recompile my brain no matter what you do to
> make me."
>
> You blindly copied how someone else in a hurry did it without a thought
> to whether it was done right, and now you don't want to change it. You
> should have asked me about it before coding it.
>
> Replace block-device-as-path-name-component with
> block-device-as-path-name-suffix, and everything is very consistent.
> And elegant.
No, it's not, Hans. Adding another level is a user visible change. It is
*not* consistent, and requires users to change their tools. How is that
elegant?
> Jeff, you are a programmer, not an architect, and when you disregard
> architects we end up with things like the performance disaster that is
> V3 acls.
This again? The original reiser3 implementation was, and still is,
incomplete in comparison to the design document. The design touted the
extensibility of the tree and item types. My original xattr
implementation added another item type, but oh -- wait -- it turns out
that the file system isn't quite as extensible as claimed.. or, well, AT
ALL. Adding another item results in an incompatible file system change
that when mounted on another system, will panic the node. That's
friendly! There's not even any way to identify which items are in use on
a particular file system to issue a warning/error on mount. Outstanding
job "architecting" there.
If I could go back and do it again, I would have forked a reiserfs v3.7
that actually incorporated a compatibility block to identify which items
are in use on a particular file systems, so that the mount can succeed
or fail based on that. Xattrs would have been another item type as
expected, and the performance problems wouldn't be nearly as harsh as
they are. Not that you wouldn't have been just as resistant to that
change as well.
The thing is, you have a history of ignoring what users want. Users
wanted ACLs and xattrs on reiser3, but you said, "wait for v4, it'll be
out soon, and it'll have them." That was 4 years ago. Reiser4 still
isn't completely stable (or in mainline), and ACLs and xattrs still
aren't implemented. Users that demanded ACLs certainly aren't waiting
around for reiser4 to be released and have ACLs added. They've long
since switched to a file system that actually does what they need. They
wanted ACLs and xattrs added to the stable file system they were using
and you refused in an attempt to get more support for your latest
project. Further, reiser3 users remember what a long painful road it was
to reiser3 stability and aren't looking to use their production systems
as your guinea pigs. They don't want to go through that hell again.
> Replacing / with ! is hideous. Someone added a nifty elegance to block
> device naming, and you are desecrating it.
No, someone added inconsistent names to block devices, and now we have
to pay for it.
If trying to understand what users actually want, and trying to keep
their experience consistent with the rest of the system makes me a
programmer instead of an architect, fine. It's a badge I'll wear
proudly. You can keep your ivory tower.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFEu+wXLPWxlyuTD7IRAmroAJ0bbMSL7iSZ7TI29M/+e/jRQqbDPQCfYBcZ
w7OwY1/+G1UckaPURd0zTrg=
=3iaQ
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
