Jeff Mahoney wrote:
> 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.
I am willing to bet that perl can tree iterate with one line of code....
Please read the Hideous Name by Rob Pike. You are making it more hideous.
>
> >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.
Try v4.
> 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.
Well, if you had an obsessive desire to not use V4, you could fix this
in V3 instead.
>
> 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.
Might be easier to use V4... so many bugs got added to an otherwise
stable V3.....
> Xattrs would have been another item type as
> expected, and the performance problems wouldn't be nearly as harsh as
> they are.
Hmm, maybe it was all perfectly predictable to an architect....
> 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.
What quality architect does not? Users are to be listened to with great
care. Users are to be listened to with great discretion.
> 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
It is more stable than V3 was when it went in, and surely it is more
stable than ext4....
It is getting there. Recent get ready for mainline changes added bugs.
We need to get some patches out the door tomorrow, and then we should be
back to being stable again.
> (or in mainline),
not my doing;-) we wasted a lot of time shuffling code from one side of
the room to the other for no measurable benefit. If only that time
could have been spent on the things I know deserve work.
> 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
so why did you take their stable branch away from them by working on
more than bugfixes for V3?
Jeff, working on v3 at this point is nuts. V4 blows it away....
-
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]
