Re: Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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?
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
> >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. > >Might be easier to use V4... > >> 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 My word here is done: While reiserfs3 actually got ACLs, xattrs and quota support by now, reiser4 still lacks them. Something must be very wrong to suggest V4; at least when it comes to these three things. Jan Engelhardt --
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 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. Interesting read. > You are making it more hideous. By insisting that something that is /not/ a directory /is/ written as such? Sorry, they are asking for exactly the opposite. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
Hans Reiser wrote: Jeff Mahoney wrote: 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. The above though, is pure and simple PR. Please do not confuse PR with maintenance, or design maintenance. I run pretty recent kernels on some of my servers and or workstations (2.6.17.4 at the moment). Some others are still using 2.4. All of them are using reiserfs3. I use reiser3 for most all, except video application partitions where XFS is used. For the past 2 yr i have been really pressed for time, and as a result have needed to scale back on pet projects, like testing new filesystems which are not yet into mainline. Once Reiserfs4 gets into mainline, i will test on a workstation. Till that time (and after) any work done on reiserfs3 is very much appreciated by me. It is keeping v3 up with changing requirements and expectations. You cannot start developing a new version and then quit supporting the previous version. I consider the work Jeff and others have been doing a very good maintenance job. YES, a maintenance job. Addition of relatively minor features is part of normal maintenance. I expect you to disagree here, i am used to that (having followed reiserfs list for many years). Cheers, Rudy Zijlstra P.S. reducing maintenance to pure bug-fixing is tentamount to announcing EOL.
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 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 going to get handed 'a'. > It does not need to be so complex actually, Just create a plain old > parent directory just like every other parent directory in procfs. This smells a lot like using a directory to resolve it pgpII2oRQluma.pgp Description: PGP signature
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 a simple "replace / with ! before sending the name to procfs." > >> > >>Reiserfs requests that a procfs directory called > >>/proc/fs/reiserfs/ be created. Some block devices contain > >>slashes, so with cciss/c123 it attempts to create a directory called > >>/proc/fs/reiserfs/cciss/c123, but cciss/ doesn't exist, shouldn't, and > >>never will. > > >Why not check to see if it does not exist, and create it if not, as > >needed, and skip the !'s? > > > 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? > 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. 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. Replacing / with ! is hideous. Someone added a nifty elegance to block device naming, and you are desecrating it. Hans
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 '/' interpretation in the VFS, how, >> exactly? >> >>> fs/namei.c, do_path_lookup() does magic on a '/' on about the 3rd line. >>> So you're going to get handed 'a'. >> >> That's where he started talking about how BSD gets namei() right by >> allowing each file system to deal with it how it chooses. >> >> Personally, I think it's insane. On occasion, I've started to port >> ReiserFS to BSD-like systems, > > Porting V3 to anything is insane. Why would you even consider it? Because I have an iBook I dual boot, and I wanted access to my reiserfs file systems while using OSX. I'd call it more of a write-from-scratch than a port, actually. >> and I get so fed up with how you have to >> reinvent the wheel for everything. There's something to be said for >> replaceable-anything semantics, but personally I like the Linux model >> and having an agreed-upon framework to work with. > > Linux vs. BSD's namei is the difference between thinking you know how to > do things and everyone should be forced into your mold, and thinking > that someone will always be more clever, at the very least with regards > to some special case you could never have anticipated. That's great, except that by and large, the Linux VFS covers all the common cases for you. This is such a ridiculous corner case that it hardly justifies using the BSD namei() semantics. >> I also think it's insane to come up with a reisermetafs to export procfs >> information when a simple s#/#!# _on a single directory name_ will do >> the job. > > Or just create a parent directory and skip the metafs. Look, I don't > much care about the other details of coding it, but if you are changing > !'s to /'s, as an architect my intuition says something is wrong and > being papered over. /'s are just fine, and what the block devices do is > elegant. You are doing a quick hack. Yes, it is a quick hack. It's called being practical and consistent until we can get around to removing slashes. Slashes *were* ok in block device names until we started using them as path name components. I've stated the reasons why adding a subdirectory is a bad idea multiple times. The fix is already accepted. I'm done discussing this. - -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+AGLPWxlyuTD7IRAjzqAKCk/nSheinL6AL4m+9YbG5FIo7f/ACeKWOd Urif7U9OMFwX9JzywowrMiM= =86sM -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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() does magic on a '/' on about the 3rd line. > >So you're going to get handed 'a'. > > > That's where he started talking about how BSD gets namei() right by > allowing each file system to deal with it how it chooses. > > Personally, I think it's insane. On occasion, I've started to port > ReiserFS to BSD-like systems, Porting V3 to anything is insane. Why would you even consider it? > and I get so fed up with how you have to > reinvent the wheel for everything. There's something to be said for > replaceable-anything semantics, but personally I like the Linux model > and having an agreed-upon framework to work with. Linux vs. BSD's namei is the difference between thinking you know how to do things and everyone should be forced into your mold, and thinking that someone will always be more clever, at the very least with regards to some special case you could never have anticipated. > > I also think it's insane to come up with a reisermetafs to export procfs > information when a simple s#/#!# _on a single directory name_ will do > the job. Or just create a parent directory and skip the metafs. Look, I don't much care about the other details of coding it, but if you are changing !'s to /'s, as an architect my intuition says something is wrong and being papered over. /'s are just fine, and what the block devices do is elegant. You are doing a quick hack. > > -Jeff > > -- > Jeff Mahoney > SUSE Labs
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 difficult or >> not. It's a simple "replace / with ! before sending the name to procfs." >> >> Reiserfs requests that a procfs directory called >> /proc/fs/reiserfs/ be created. Some block devices contain >> slashes, so with cciss/c123 it attempts to create a directory called >> /proc/fs/reiserfs/cciss/c123, but cciss/ doesn't exist, shouldn't, and >> never will. > > Why not check to see if it does not exist, and create it if not, as > needed, and skip the !'s? 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. 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. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEu9lCLPWxlyuTD7IRAjeSAJ43f0SU1g4oivcUaFHQnnIPS89VMQCgkYu/ 8S3Qi0cM7mKuwhp9W51JjsY= =EXCL -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
[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 '/' on about the 3rd line. >So you're going to get handed 'a'. > > It does not need to be so complex actually, Just create a plain old parent directory just like every other parent directory in procfs.
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 > > -- > Jeff Mahoney > SUSE Labs
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 the name to procfs." > > Reiserfs requests that a procfs directory called > /proc/fs/reiserfs/ be created. Some block devices contain > slashes, so with cciss/c123 it attempts to create a directory called > /proc/fs/reiserfs/cciss/c123, but cciss/ doesn't exist, shouldn't, and > never will. Why not check to see if it does not exist, and create it if not, as needed, and skip the !'s? > In order to create a single path component, "cciss/c123" > becomes "cciss!c123." This is consistent with how sysfs does it now. For > a real example, change the "-" in device mapper block names to "/" and > see what happens. > > Regardless, it's already been checked into mainline as change > 6fbe82a952790c634ea6035c223a01a81377daf1. > > -Jeff > > -- > Jeff Mahoney > SUSE Labs
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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? > > fs/namei.c, do_path_lookup() does magic on a '/' on about the 3rd line. > So you're going to get handed 'a'. That's where he started talking about how BSD gets namei() right by allowing each file system to deal with it how it chooses. Personally, I think it's insane. On occasion, I've started to port ReiserFS to BSD-like systems, and I get so fed up with how you have to reinvent the wheel for everything. There's something to be said for replaceable-anything semantics, but personally I like the Linux model and having an agreed-upon framework to work with. I also think it's insane to come up with a reisermetafs to export procfs information when a simple s#/#!# _on a single directory name_ will do the job. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEu9QALPWxlyuTD7IRAqHbAKCVknPt6Gr43YHyrUZVtmuuEWX9UgCfdw74 tXwbWr5AhupA868D96lw9Eo= =NvUr -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 going to get handed 'a'. pgpAiNTu9WQ5W.pgp Description: PGP signature
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 file system wants to use the block device name as a pathname. In any other case, interpreting the / as a path separator would be the correct behavior. While a helper function/macro may be appropriate, I don't think the VFS has any business interpreting names automatically like that. As stated before numerous times by both Andrew and myself, the correct solution is to eliminate / from block device names. This patch was a band-aid until that's done. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEu7VNLPWxlyuTD7IRAinwAJ43vf+NHkI/U/sA743174o68xw5UQCfaL1z N367ixvf/HeQuWHZH0CkjVY= =4+dh -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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?
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 / with ! before sending the name to procfs." Reiserfs requests that a procfs directory called /proc/fs/reiserfs/ be created. Some block devices contain slashes, so with cciss/c123 it attempts to create a directory called /proc/fs/reiserfs/cciss/c123, but cciss/ doesn't exist, shouldn't, and never will. In order to create a single path component, "cciss/c123" becomes "cciss!c123." This is consistent with how sysfs does it now. For a real example, change the "-" in device mapper block names to "/" and see what happens. Regardless, it's already been checked into mainline as change 6fbe82a952790c634ea6035c223a01a81377daf1. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEu6TPLPWxlyuTD7IRAvFTAJ9MYmmhSljmJTYFFlQvwS1G5AWdWQCglN0u FCxA4sTIi/O5KRsZ38vzT1c= =M7gO -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 for > >>making any translation to that usage. > > >This makes no sense. I have the feeling you see trees and I see forest. > > > No, Hans. I see a problem that has been fixed elsewhere in an identical > manner. The real solution is to eliminate / from block devices in the > long run, not to start introducing mount points with different pathname > interpretation rules. Those may have a place elsewhere, after a tough > uphill battle, and are most certainly overkill for this problem. > > -Jeff 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. Hans
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 and is responsible for >> making any translation to that usage. > > This makes no sense. I have the feeling you see trees and I see forest. No, Hans. I see a problem that has been fixed elsewhere in an identical manner. The real solution is to eliminate / from block devices in the long run, not to start introducing mount points with different pathname interpretation rules. Those may have a place elsewhere, after a tough uphill battle, and are most certainly overkill for this problem. - -Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuwFFLPWxlyuTD7IRAsiiAJ9cwTuov+2OM7GI44L1wQ/XDBMy9ACeIIYQ 5xEIRCQXHAZFG7oOFEkWJS4= =onBb -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 translate them into names with > "!"'s. > > > If using something with slashes in it as a file name component isn't > problematic, then by all means create a single file system object named > "a/b" where "a" doesn't refer to a parent directory and tell us all how. Create a mountpoint which knows how to resolve a/b without using a "directory". > > >>and it would be nice to correct drivers currently using > >>them. The problem is that when you change the name of a device, that's a > >>userspace visible change. > > >So don't. Why would user space care how you parse it and whether the > >driver or reiserfs does it? > > > Huh? The block device's name is exported directly via /proc/partitions, > but then also used as a file name component in sysfs, and also procfs > via reiserfs. How do you propose fixing this without adding an > additional field to genhd? Adding a helper function is essentially the > same thing as this patch other than it being open coded, what is open coding? Something different from free software? > and I'm not > getting the impression that the open coding is your issue. > > >>Scripts that currently expect, say, > >>/proc/partitions to contain cciss/ will break between kernel > >>versions. Sysfs wants to use the device name as a pathname component, > >>and as such translates the / to a !, the same as this patch proposes. > >> > >>Reiserfs gets involved because it expects that name to be usable as a > >>file system pathname component when it is not intended to be one without > >> translating slashes into another character. The difference is that > >>block device names are allowed to have slashes in them, while normal > >>file system names are not. > > >We should distinguish here between names and name components. > > > In terms of file system names, I have been making that distinction. In > terms of block devices, the name the name refers to? > consists of only one component. So fix that. Create a pseudo directory, and have a/b and a/c get resolved by a. That is cleaner than converting / to !. > More below. > > >>The fact is that device driver names, when in > >>/dev can use separate components, like /dev/cciss/0, but when used in > >>the manner reiserfs wants them to be used, they can't. Also, I'm not > >>talking about name spaces like struct namespace, I mean that the group > >>of names that block device drivers use have different constraints than > >>the group of names that are allowable as file names. > >> > >>The fact is that this change is required for users deploying devices > >>that use slashes in their names to see the proc data for a reiserfs file > >>system. You can point the finger all you want at the block drivers in > >>the mean time, but it's still a reiserfs problem. > > >I still do not grok why you need to change / to !. > > >Something is wrong. Reiserfs is being asked to do something that > >somebody else should be doing. > > > Splitting the block device names with / is applying file system path > name rules to the block device name, when they don't. Don't what? > The entire point > of this is that "cciss/whatever" refers to a single object in the block > layer, but when you apply file system rules, it becomes two. Uh, no, a/b in any POSIX filesystem refers to one object. Now maybe someday probably not what you meant > 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 for > making any translation to that usage. This makes no sense. I have the feeling you see trees and I see forest. > > -Jeff
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 somehow needing to translate them into names with "!"'s. If using something with slashes in it as a file name component isn't problematic, then by all means create a single file system object named "a/b" where "a" doesn't refer to a parent directory and tell us all how. >> and it would be nice to correct drivers currently using >> them. The problem is that when you change the name of a device, that's a >> userspace visible change. > > So don't. Why would user space care how you parse it and whether the > driver or reiserfs does it? Huh? The block device's name is exported directly via /proc/partitions, but then also used as a file name component in sysfs, and also procfs via reiserfs. How do you propose fixing this without adding an additional field to genhd? Adding a helper function is essentially the same thing as this patch other than it being open coded, and I'm not getting the impression that the open coding is your issue. >> Scripts that currently expect, say, >> /proc/partitions to contain cciss/ will break between kernel >> versions. Sysfs wants to use the device name as a pathname component, >> and as such translates the / to a !, the same as this patch proposes. >> >> Reiserfs gets involved because it expects that name to be usable as a >> file system pathname component when it is not intended to be one without >> translating slashes into another character. The difference is that >> block device names are allowed to have slashes in them, while normal >> file system names are not. > > We should distinguish here between names and name components. In terms of file system names, I have been making that distinction. In terms of block devices, the name consists of only one component. More below. >> The fact is that device driver names, when in >> /dev can use separate components, like /dev/cciss/0, but when used in >> the manner reiserfs wants them to be used, they can't. Also, I'm not >> talking about name spaces like struct namespace, I mean that the group >> of names that block device drivers use have different constraints than >> the group of names that are allowable as file names. >> >> The fact is that this change is required for users deploying devices >> that use slashes in their names to see the proc data for a reiserfs file >> system. You can point the finger all you want at the block drivers in >> the mean time, but it's still a reiserfs problem. > > I still do not grok why you need to change / to !. > > Something is wrong. Reiserfs is being asked to do something that > somebody else should be doing. Splitting the block device names with / is applying file system path name rules to the block device name, when they don't. The entire point of this is that "cciss/whatever" refers to a single object in the block layer, but when you apply file system rules, it becomes two. 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 for making any translation to that usage. - -Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuuzhLPWxlyuTD7IRAnH4AJ9b17T51IL+8f0TiewCKKS23H1c2wCeMF2W /OhK0wnvQ1dql2Xd7OmocLI= =G8iz -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 nice to correct drivers currently using > them. The problem is that when you change the name of a device, that's a > userspace visible change. So don't. Why would user space care how you parse it and whether the driver or reiserfs does it? > Scripts that currently expect, say, > /proc/partitions to contain cciss/ will break between kernel > versions. Sysfs wants to use the device name as a pathname component, > and as such translates the / to a !, the same as this patch proposes. > > Reiserfs gets involved because it expects that name to be usable as a > file system pathname component when it is not intended to be one without > translating slashes into another character. The difference is that > block device names are allowed to have slashes in them, while normal > file system names are not. We should distinguish here between names and name components. > The fact is that device driver names, when in > /dev can use separate components, like /dev/cciss/0, but when used in > the manner reiserfs wants them to be used, they can't. Also, I'm not > talking about name spaces like struct namespace, I mean that the group > of names that block device drivers use have different constraints than > the group of names that are allowable as file names. > > The fact is that this change is required for users deploying devices > that use slashes in their names to see the proc data for a reiserfs file > system. You can point the finger all you want at the block drivers in > the mean time, but it's still a reiserfs problem. I still do not grok why you need to change / to !. Something is wrong. Reiserfs is being asked to do something that somebody else should be doing. Hans
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 handle the number. I really don't get why reiserfs has any > role in this problem. Regarding "a separate name space that doesn't > follow the same rules > as the standard file system name space.", linux does not need those to > be created, but what I don't understand is exactly in what respect the > driver namespace does not conform. It has components separated by > slashes. Is this related to the difference between BSD's namei and > Linux's? BSD is the one getting it right. Hans, we're all in agreement that we'd prefer drivers not use names with slashes in them, and it would be nice to correct drivers currently using them. The problem is that when you change the name of a device, that's a userspace visible change. Scripts that currently expect, say, /proc/partitions to contain cciss/ will break between kernel versions. Sysfs wants to use the device name as a pathname component, and as such translates the / to a !, the same as this patch proposes. Reiserfs gets involved because it expects that name to be usable as a file system pathname component when it is not intended to be one without translating slashes into another character. The difference is that block device names are allowed to have slashes in them, while normal file system names are not. The fact is that device driver names, when in /dev can use separate components, like /dev/cciss/0, but when used in the manner reiserfs wants them to be used, they can't. Also, I'm not talking about name spaces like struct namespace, I mean that the group of names that block device drivers use have different constraints than the group of names that are allowable as file names. The fact is that this change is required for users deploying devices that use slashes in their names to see the proc data for a reiserfs file system. You can point the finger all you want at the block drivers in the mean time, but it's still a reiserfs problem. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEursULPWxlyuTD7IRAuaoAJ4w9PiYbgSpFzhQraJklOTkSGin7gCfW5I7 bJblQKd/y40fnckG75UhJ8k= =hLoM -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 this problem. Regarding "a separate name space that doesn't follow the same rules as the standard file system name space.", linux does not need those to be created, but what I don't understand is exactly in what respect the driver namespace does not conform. It has components separated by slashes. Is this related to the difference between BSD's namei and Linux's? BSD is the one getting it right. Hans Jeffrey Mahoney wrote: > 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 of the namespace, seeing the driver as a mountpoint, and > >just passing number to the driver. There must be something I don't > >grasp here, can you help me? > > > The name used in procfs isn't parsed anywhere, it could just as easily > be fs0, fs1, fs2, etc, but that wouldn't be a very user friendly way of > indicating which file system's statistics are described in that > directory. It's just presented to the user as a pathname to identify a > particular file system. The problem is that reiserfs is attempting to > use a name from a separate name space that doesn't follow the same rules > as the standard file system name space. Block device names, initially, > weren't intended for use as self-contained path components and aren't > part of the file system name space. If we wish to use those names, we > need to sanitize them to conform to the rules of the file system name > space by removing/replacing the path separator character. > > It's unfortunate that some drivers use a slash rather than sticking with > the convention. I don't expect new drivers to be added > with slashes in them. If at some point the existing drivers are changed > to remove the slash, then this patch can be removed again. > > > -Jeff
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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 of the namespace, seeing the driver as a mountpoint, and > just passing number to the driver. There must be something I don't > grasp here, can you help me? The name used in procfs isn't parsed anywhere, it could just as easily be fs0, fs1, fs2, etc, but that wouldn't be a very user friendly way of indicating which file system's statistics are described in that directory. It's just presented to the user as a pathname to identify a particular file system. The problem is that reiserfs is attempting to use a name from a separate name space that doesn't follow the same rules as the standard file system name space. Block device names, initially, weren't intended for use as self-contained path components and aren't part of the file system name space. If we wish to use those names, we need to sanitize them to conform to the rules of the file system name space by removing/replacing the path separator character. It's unfortunate that some drivers use a slash rather than sticking with the convention. I don't expect new drivers to be added with slashes in them. If at some point the existing drivers are changed to remove the slash, then this patch can be removed again. - -Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEumGhLPWxlyuTD7IRAvuOAJ4yYUYp9TsUervYGBERSinPyOeAJQCgn7Wm lgYoPKKUElaKkWcoECN9e+4= =Rp8I -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 number to the driver. There must be something I don't grasp here, can you help me? Hans Jeff Mahoney wrote: > 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/ due to > >>> it being interpreted as a subdirectory. The generic block device code > >>> changes the / to ! for use in the sysfs tree. This patch uses that > >>> convention. > >>> > >>> Tested by making dm devices use dm/ rather than dm- > >> > >>Your patch handles at most one slash. But the description mentions > 'slashes' > >>(ie several slashes) > > >Besides that, there is no reason to prevent the user from using many > slashes. > >OTOH, I'd prefer propper quoting, but having each driver do this would be > >insane. > > > The strings aren't user-supplied, they're kernel-internal names of block > devices, supplied by the driver. At present there is no possibility of > more than one slash in the name, and I doubt we'll see any new devices > with one slash in them, never mind more than one. > > -Jeff > > -- > Jeff Mahoney > SUSE Labs
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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/ due to >>> it being interpreted as a subdirectory. The generic block device code >>> changes the / to ! for use in the sysfs tree. This patch uses that >>> convention. >>> >>> Tested by making dm devices use dm/ rather than dm- >> Your patch handles at most one slash. But the description mentions 'slashes' >> (ie several slashes) > > Besides that, there is no reason to prevent the user from using many slashes. > OTOH, I'd prefer propper quoting, but having each driver do this would be > insane. The strings aren't user-supplied, they're kernel-internal names of block devices, supplied by the driver. At present there is no possibility of more than one slash in the name, and I doubt we'll see any new devices with one slash in them, never mind more than one. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEt9l6LPWxlyuTD7IRAgwsAJ9nvPJRnnJsbqukhtJj3T2mjJC1hQCfYYeh lbTYktc+yglYRmxT/LwPcT4= =767A -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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/ due to
>> it being interpreted as a subdirectory. The generic block device code
>> changes the / to ! for use in the sysfs tree. This patch uses that
>> convention.
>>
>> Tested by making dm devices use dm/ rather than dm-
>
> Your patch handles at most one slash. But the description mentions 'slashes'
> (ie several slashes)
Besides that, there is no reason to prevent the user from using many slashes.
OTOH, I'd prefer propper quoting, but having each driver do this would be
insane.
> Maybe you need a loop
>
> while (s) {
[...]
s = bdev;
while (s = strchr(s, '/'))
*s = '!';
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
http://david.woodhou.se/why-not-spf.html
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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. > > > >
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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 /proc/fs/reiserfs/ due to > >> it being interpreted as a subdirectory. The generic block device code > >> changes the / to ! for use in the sysfs tree. This patch uses that > >> convention. > >> > >> > > > >Isn't it a bit dumb of us to be putting slashes in the device names anyway? > > It would be better, if poss, to alter dasd/cciss/etc and stop all these > >s@/@[EMAIL PROTECTED] games. > > > > > > > > > Isn't better to ask why there is a problem with the /'s? It would be > bad for Linux as a design to prevent passing arbitrary tail ends of > filenames off to arbitrary plugins of some kind. In general, in > namespace design, you want to allow delegating the job of > resolving/interpreting the tail end of a file that the front end has > identified as something that can interpret it. > > Forgive me, I probably understand something wongly about procfs and this > issue > It's a question of being *practical*. Your observations are in the realm of the theoretical. 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.
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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/ due to >> it being interpreted as a subdirectory. The generic block device code >> changes the / to ! for use in the sysfs tree. This patch uses that >> convention. >> >> > >Isn't it a bit dumb of us to be putting slashes in the device names anyway? > It would be better, if poss, to alter dasd/cciss/etc and stop all these >s@/@[EMAIL PROTECTED] games. > > > > Isn't better to ask why there is a problem with the /'s? It would be bad for Linux as a design to prevent passing arbitrary tail ends of filenames off to arbitrary plugins of some kind. In general, in namespace design, you want to allow delegating the job of resolving/interpreting the tail end of a file that the front end has identified as something that can interpret it. Forgive me, I probably understand something wongly about procfs and this issue Hans
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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/ due to > it being interpreted as a subdirectory. The generic block device code > changes the / to ! for use in the sysfs tree. This patch uses that > convention. Isn't it a bit dumb of us to be putting slashes in the device names anyway? It would be better, if poss, to alter dasd/cciss/etc and stop all these s@/@[EMAIL PROTECTED] games.
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
-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/ due to >> it being interpreted as a subdirectory. The generic block device code >> changes the / to ! for use in the sysfs tree. This patch uses that >> convention. >> >> Tested by making dm devices use dm/ rather than dm- > > Your patch handles at most one slash. But the description mentions 'slashes' > (ie several slashes) > >> +if (s) >> +*s = '!'; > > Maybe you need a loop I'd prefer to correct the grammar rather than the patch. This patch simply duplicates the logic in make_block_name(). - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEtStALPWxlyuTD7IRAgl0AJ9Q25r0SIZpIZrX/m6ld69OLwvoxQCfdRj/ XIT1LYuQThoypHAx7ud96h8= =0ZdG -END PGP SIGNATURE-
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
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/ due to
> it being interpreted as a subdirectory. The generic block device code
> changes the / to ! for use in the sysfs tree. This patch uses that
> convention.
>
> Tested by making dm devices use dm/ rather than dm-
Your patch handles at most one slash. But the description mentions 'slashes'
(ie several slashes)
> + if (s)
> + *s = '!';
Maybe you need a loop
while (s) {
*s = '!';
s = strchr(s, '/');
}
Eric
[PATCH] reiserfs: fix handling of device names with /'s in them
-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/ due to
it being interpreted as a subdirectory. The generic block device code
changes the / to ! for use in the sysfs tree. This patch uses that
convention.
Tested by making dm devices use dm/ rather than dm-
Signed-off-by: Jeff Mahoney <[EMAIL PROTECTED]>
- --
fs/reiserfs/procfs.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff -ruNp linux-2.6.17.orig/fs/reiserfs/procfs.c
linux-2.6.17.orig.devel/fs/reiserfs/procfs.c
- --- linux-2.6.17.orig/fs/reiserfs/procfs.c2006-07-12 11:58:56.0
-0400
+++ linux-2.6.17.orig.devel/fs/reiserfs/procfs.c2006-07-12
12:39:17.0 -0400
@@ -493,9 +493,17 @@ static void add_file(struct super_block
int reiserfs_proc_info_init(struct super_block *sb)
{
+ char bdev[BDEVNAME_SIZE];
+ char *s;
+
+ /* Some block devices use /'s */
+ strlcpy(bdev, reiserfs_bdevname(sb), BDEVNAME_SIZE);
+ s = strchr(bdev, '/');
+ if (s)
+ *s = '!';
+
spin_lock_init(&__PINFO(sb).lock);
- - REISERFS_SB(sb)->procdir =
- - proc_mkdir(reiserfs_bdevname(sb), proc_info_root);
+ REISERFS_SB(sb)->procdir = proc_mkdir(bdev, proc_info_root);
if (REISERFS_SB(sb)->procdir) {
REISERFS_SB(sb)->procdir->owner = THIS_MODULE;
REISERFS_SB(sb)->procdir->data = sb;
@@ -509,13 +517,22 @@ int reiserfs_proc_info_init(struct super
return 0;
}
reiserfs_warning(sb, "reiserfs: cannot create /proc/%s/%s",
- - proc_info_root_name, reiserfs_bdevname(sb));
+proc_info_root_name, bdev);
return 1;
}
int reiserfs_proc_info_done(struct super_block *sb)
{
struct proc_dir_entry *de = REISERFS_SB(sb)->procdir;
+ char bdev[BDEVNAME_SIZE];
+ char *s;
+
+ /* Some block devices use /'s */
+ strlcpy(bdev, reiserfs_bdevname(sb), BDEVNAME_SIZE);
+ s = strchr(bdev, '/');
+ if (s)
+ *s = '!';
+
if (de) {
remove_proc_entry("journal", de);
remove_proc_entry("oidmap", de);
@@ -529,7 +546,7 @@ int reiserfs_proc_info_done(struct super
__PINFO(sb).exiting = 1;
spin_unlock(&__PINFO(sb).lock);
if (proc_info_root) {
- - remove_proc_entry(reiserfs_bdevname(sb), proc_info_root);
+ remove_proc_entry(bdev, proc_info_root);
REISERFS_SB(sb)->procdir = NULL;
}
return 0;
- --
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFEtSZ0LPWxlyuTD7IRAkfVAJoChixL9icBa5tpe+A9cqE4OdohywCfVW0f
RgF2ffZyXik8NuDy/m0kXUc=
=X3VE
-END PGP SIGNATURE-
