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
On 7/17/06, Hans Reiser [EMAIL PROTECTED] wrote:
Replacing / with ! is hideous. Someone added a nifty elegance to block
device naming, and you are desecrating it.
You're free to send a patch to fix it all, you know. Until then, lets
make reiserfs consistent with rest of the kernel, ok?
Jeffrey Mahoney wrote:
Hans Reiser wrote:
Jeffrey Mahoney wrote:
This is not
the desired interpretation, which is why we need to replace the pathname
separator in the name. ReiserFS is the component that is choosing to use
the block device name as a pathname component and is responsible
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
I don't understand your patch and cannot support it as it is written.
Perhaps you can call me and explain it on the phone.
I seriously can't tell if you're deliberately trying to be difficult or
not. It's a simple replace /
Shouldn't the replacement of / by some other character be done for all
filesystems? If so shouldn't it be done in a single point for all of
them? Isn't this the purpose of VFS?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carlos Carvalho wrote:
Shouldn't the replacement of / by some other character be done for all
filesystems? If so shouldn't it be done in a single point for all of
them? Isn't this the purpose of VFS?
This only applies to a corner case where the
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
And said mountpoint gets past the '/' interpretation in the VFS, how, exactly?
fs/namei.c, do_path_lookup() does magic on a '/' on about the 3rd line.
So you're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
And said mountpoint gets past the '/' interpretation in the VFS, how, exactly?
Jeff Mahoney wrote:
Hans Reiser wrote:
I don't understand your patch and cannot support it as it is written.
Perhaps you can call me and explain it on the phone.
I seriously can't tell if you're deliberately trying to be difficult or
not. It's a simple replace / with ! before sending
Jeff Mahoney wrote:
As stated before numerous times by both Andrew and myself, the correct
solution is to eliminate / from block device names.
Why? It is elegant to have those /'s Just create the directory,
how is that hard?
This patch was a
band-aid until that's done.
-Jeff
--
[EMAIL PROTECTED] wrote:
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
And said mountpoint gets past the '/' interpretation in the VFS, how, exactly?
fs/namei.c, do_path_lookup() does magic on a '/'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
I don't understand your patch and cannot support it as it is written.
Perhaps you can call me and explain it on the phone.
I seriously can't tell if you're deliberately trying to be
Jeff Mahoney wrote:
[EMAIL PROTECTED] wrote:
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
And said mountpoint gets past the '/' interpretation in the VFS, how,
exactly?
fs/namei.c, do_path_lookup()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
Jeff Mahoney wrote:
[EMAIL PROTECTED] wrote:
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
And said mountpoint gets past the '/'
Jeff Mahoney wrote:
Hans Reiser wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
I don't understand your patch and cannot support it as it is written.
Perhaps you can call me and explain it on the phone.
I seriously can't tell if you're deliberately trying to be difficult or
not. It's
On Mon, 17 Jul 2006 11:27:20 PDT, Hans Reiser said:
[EMAIL PROTECTED] wrote:
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
For wanting to resolve it *without* using a directory...
And said mountpoint gets
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 /
Hans Reiser wrote:
Jeff Mahoney wrote:
snip
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
Hans,
I appreciate your vision and willingness to work to that vision.
Hans Reiser [EMAIL PROTECTED] wrote:
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
So the Plan 9 and Unix way would be to let the driver parse the number
part of the name after the last slash. What I don't understand is why
reiserfs is getting involved here, rather than recognizing the driver as
an extension of the namespace, seeing the driver as a mountpoint, and
just passing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
So the Plan 9 and Unix way would be to let the driver parse the number
part of the name after the last slash. What I don't understand is why
reiserfs is getting involved here, rather than recognizing the driver as
an extension
This sounds like it should be fixed in the driver, not in reiserfs. It
sounds like the driver is violating Posix naming, and should be fixed to
conform to it. Have the driver create an fs mountpoint, and then have
the driver handle the number. I really don't get why reiserfs has any
role in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
This sounds like it should be fixed in the driver, not in reiserfs. It
sounds like the driver is violating Posix naming, and should be fixed to
conform to it. Have the driver create an fs mountpoint, and then have
the driver
Jeff Mahoney wrote:
Hans Reiser wrote:
Hans, we're all in agreement that we'd prefer drivers not use names with
slashes in them,
there is nothing wrong with using names that have slashes. The thing
that is wrong is somehow needing to translate them into names with !'s.
and it would be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
Hans, we're all in agreement that we'd prefer drivers not use names with
slashes in them,
there is nothing wrong with using names that have slashes. The thing
that is wrong is
Jeffrey Mahoney wrote:
Hans Reiser wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
Hans, we're all in agreement that we'd prefer drivers not use names with
slashes in them,
there is nothing wrong with using names that have slashes. The thing
that is wrong is somehow needing to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
Jeffrey Mahoney wrote:
This is not
the desired interpretation, which is why we need to replace the pathname
separator in the name. ReiserFS is the component that is choosing to use
the block device name as a pathname component
Eric Dumazet [EMAIL PROTECTED] wrote:
On Wednesday 12 July 2006 18:42, Jeff Mahoney wrote:
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize /proc/fs/reiserfs/dev due to
it being interpreted as a subdirectory. The generic block
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bodo Eggert wrote:
Eric Dumazet [EMAIL PROTECTED] wrote:
On Wednesday 12 July 2006 18:42, Jeff Mahoney wrote:
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize /proc/fs/reiserfs/dev
Who exactly is failing to handle the slashes, forgive me for my
confusion in asking?
Hans
Andrew Morton wrote:
Software sucks, and we get along better by not provoking it. So don't put
spaces, let alone slashes into strings which we offer to userspace.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize /proc/fs/reiserfs/dev due to
it being interpreted as a subdirectory. The generic block device code
changes the / to ! for use in the
On Wednesday 12 July 2006 18:42, Jeff Mahoney wrote:
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize /proc/fs/reiserfs/dev due to
it being interpreted as a subdirectory. The generic block device code
changes the / to ! for use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
On Wednesday 12 July 2006 18:42, Jeff Mahoney wrote:
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize /proc/fs/reiserfs/dev due to
it being interpreted as a
On Wed, 12 Jul 2006 12:42:28 -0400
Jeff Mahoney [EMAIL PROTECTED] wrote:
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize /proc/fs/reiserfs/dev due to
it being interpreted as a subdirectory. The generic block device code
changes
Andrew Morton wrote:
On Wed, 12 Jul 2006 12:42:28 -0400
Jeff Mahoney [EMAIL PROTECTED] wrote:
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize /proc/fs/reiserfs/dev due to
it being interpreted as a subdirectory. The generic
On Wed, 12 Jul 2006 20:51:47 -0700
Hans Reiser [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Wed, 12 Jul 2006 12:42:28 -0400
Jeff Mahoney [EMAIL PROTECTED] wrote:
On systems with block devices containing slashes (virtual dasd, cciss,
etc), reiserfs will fail to initialize
36 matches
Mail list logo
