Re: List of things requested by lkml for reiser4 inclusion (to review)
Andrew Morton wrote: > > > >>1. pseudo files or "" files >> >> >> > > > >> disabled. It remains a point of (extraordinary) contention as to >>whether it can be fixed, we want to keep the code around until we can >>devote proper resources into proving it can be (or until we fail to prove >>it can be and remove it). We don't want to delay the rest of the code for >>that proof, but we still think it can be done (by several different ways of >>which we need to select one and make it work.) Let us postpone contention >>on this until the existence of a patch that cannot crash makes contention >>purposeful, shall we? >> >> > >I'd prefer that unused code simply not be present in the tree, sorry. > > Ok, edward will remove. > > >>2. dependency on 4k stack turned off >> >> removed as requested >> >> > >So it all runs OK with 4k stacks now? > > vs will answer this. > > >>3. remove conditional variable code, use wait queues instead. >> >>not done. There are times when reduced functionality aids debugging. >>kcond is (literally) textbook code. We don't care enough to fight much for >>it, but akpm, what is your opinion? Will remove if akpm asks us to. >> >> > >kcond is only used in a couple of places. One looks like it could use >complete() and the other is a standard wait-for-something-to-do kernel >thread loop, which we open-code without any fuss in lots of places >(kjournald, loop, pdflush, etc). So yes, I'd be inclined to remove kcond >please. > > ok, zam will do so. >Also, it would be better to use the kthread API rather than open-coding >kernel_thread() calls. If you think that reiser4 needs additional ways of >controlling kernel threads then feel free to enhance the kthread API. > > > >>6. remove type safe lists and type safe hash queues. >> >>not done, it is not clear that the person asking for this represents a >>unified consensus of lkml. Other persons instead asked that it just be >>moved out of reiser4 code into the generic kernel code, which implies they >>did not object to it. There are many who like being type safe. Akpm, what >>do you yourself think? >> >> > >The type-unsafety of existing list_heads gives me conniptions too. Yes, >it'd be nice to have a type-safe version available. > >That being said, I don't see why such a thing cannot be a wrapper around >the existing list_head functions. Yes, there will be some ghastly >C-templates-via-CPP stuff, best avoided by not looking at the file ;) > >We should aim for a complete 1:1 relationship between list_heads and >type-safe lists. So people know what they're called, know how they work, >etc. We shouldn't go adding things called rx_event_list_pop_back() when >everyone has learned the existing list API. > >Of course, it would have been better to do this work as a completely >separate kernel feature rather than bundling it with a filesystem. If this >isn't a thing your team wants to take on now then yes, I'd be inclined to >switch reiser4 to list_heads. > > Ok, Edward, this task is yours. Edward, how big you make the task is up to you so long as it is done by Monday. If you run low on time, get help with it. - 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/
Re: List of things requested by lkml for reiser4 inclusion (to review)
Christoph Hellwig wrote: > 6. remove type safe lists and type safe hash queues. > >> not done, it is not clear that the person asking for this represents a >> unified consensus of lkml. Other persons instead asked that it just be >> moved out of reiser4 code into the generic kernel code, which implies they >> did not object to it. There are many who like being type safe. Akpm, what >> do you yourself think? >> >> > >I think quite a few people complained ;-) > I remember that you complained. > It's huge CPP abuse > can you define what that means? and how abuse differs from cleverness? This code was not my idea, but it seemed more cleverness than abuse to me when I read it. > which we >generally don't want - at least for the hash case we already had something >similar (linux/ghash.h and got rid of it). That beeing said a generic hash >abstraction without too much CPP abuse might be really useful, but the list >code should certainly go. > > > >>8. Remove all assertions because they clutter the code and make it hard to >>read >> >>We think this person was not an experienced security specialist, >> >> > >please stop attacking people personally all the time. > It is not an attack, fewer than 1% of programmers are security specialists, and I go on to say that until I was educated by some such specialists, I would have agreed with him, so I don't think you can view it as an attack. I hardly expect most people to hang out with the DoD. > You're certainly not >what I'd call an experienced security specialist either, but fortunately that >doesn't matter for this case at all. > >Removing all assertations certainly doesn't make sense, we have them all >over the tree. Whether your own assert macros makes sense is a different >question, but given that you use something similar in reiser3 and lots >of other drivers have their own things built around BUG() I won't complain >to loudly. > >What should go on the other hand are useless assertation, like one that >asserts that something is non-NULL just before dereferencing it - the >latter gives a backtrace just as nice. > > I'll be happy to accept point of code improvements. > >As additional requirements please give people time to actually audit the >codebase. > 9 months time given so far > I've started but it's quite a pain with all the plugin >indirections right now. > > Here I sympathize with you. If anyone has ideas for how to comment it, etc., to make it trivial to follow the indirections, I am all ears. It annoys me also. >One major item I found is that you're using your own code for the >read/write file operations, > As I remember, there were things that did not code right using the generic code, and I told the guys to code it right. I no longer remember what those things were, quite honestly, but I remember they affected performance. The whole idea of vfs operations is that each file system gets to do them its own way, and please remember that we code for more than just use on Linux. > which not only duplicates core code but >also lacks features (vectored I/O, AIO, direct I/O) from the common code > > in time >and is totally buggy (it has no chance on working on architectures that >have completely separate address spaces for user/kernel like s390, please >check how they define PAGE_OFFSET). > zam, please look at that on Tuesday. > Depending on your requirements you >might not use the complete generic code, but you should at least use >the most important fragments, ala XFS or ocfs, and improve them where >needed. > > Oh we do try to do that where it does what we need. However, you should keep in mind that reiser4 is not made just for Linux. Our code needs to be at least moderately self-contained. >A very annoying small thing that comes to mind is the usage of >reiser4_internal. Please remove it, all but exported symbol are >module-private. > > Here I mostly agree. Edward, can you work on a patch to fix it? Thanks. > > > Christoph, thanks kindly for the donation of your time to improving our work. - 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/
Re: List of things requested by lkml for reiser4 inclusion (to review)
Chris Shoemaker wrote: >On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote: > > >>If we lose every remaining point of this list, we can generate a patch >>in a few days, because the VFS work was the only substantive (in coding >>hours) task, and it is done. Do I remember right that the submission >>deadline is a week from Monday for 2.6.14 inclusion? >> >> > >No. 14 days from release date of 2.6.13, which was 8/29, so deadline >is 9/12, this coming Monday. > >-chris > > > > IIRC, Linus announced that since he was going on vacation for 7 days, this release only it would be 3 weeks, so it is a week from Monday that we must submit by, yes? Hans - 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/
List of things requested by lkml for reiser4 inclusion (to review)
We haven't been sending much email out, but we have been working away. We just finished the VFS work, and will send a patch out on Monday. akpm asked for a bullet list of things suggested on lkml as issues for inclusion. There are some things that I would like akpm to confirm represent the official opinion/consensus as opposed to just someone posting an opinion and perhaps not being right. I assure you that all points made by commenters were considered carefully, and I thank all of them for their time. If we lose every remaining point of this list, we can generate a patch in a few days, because the VFS work was the only substantive (in coding hours) task, and it is done. Do I remember right that the submission deadline is a week from Monday for 2.6.14 inclusion? This is supposed to be a bullet list, so I don't list here the line by line minor code improvements sent to us, most of which were incorporated, but let me take a moment to thanks those who donated them. Hans 1. pseudo files or "" files disabled. It remains a point of (extraordinary) contention as to whether it can be fixed, we want to keep the code around until we can devote proper resources into proving it can be (or until we fail to prove it can be and remove it). We don't want to delay the rest of the code for that proof, but we still think it can be done (by several different ways of which we need to select one and make it work.) Let us postpone contention on this until the existence of a patch that cannot crash makes contention purposeful, shall we? 2. dependency on 4k stack turned off removed as requested 3. remove conditional variable code, use wait queues instead. not done. There are times when reduced functionality aids debugging. kcond is (literally) textbook code. We don't care enough to fight much for it, but akpm, what is your opinion? Will remove if akpm asks us to. 4. remove reiser4_drop_inode done. 5. remove undesired abstraction layer right below reiser4 VFS hooks. done. This was a big job just completed. 6. remove type safe lists and type safe hash queues. not done, it is not clear that the person asking for this represents a unified consensus of lkml. Other persons instead asked that it just be moved out of reiser4 code into the generic kernel code, which implies they did not object to it. There are many who like being type safe. Akpm, what do you yourself think? 7. remove fs/reiser4/lib.h:/div64_32. is being replaced by the linux one. 8. Remove all assertions because they clutter the code and make it hard to read We think this person was not an experienced security specialist, and that what we do is considered by professional code auditors to be laudable practice. We can supply an emacs macro that makes them greyed out. I myself found the assertions to be distracting at first (though functional and especially necessary for a DARPA funded project), and then after time got used to them, and now I understand that it was just my inexperience that caused the discomfort. I now have a more sophisticated subconscious that is not discomforted or distracted by them. People debugging find them very useful. Defense branches tear their hair out at how difficult it is to get the commercial software they use coded this way, and I think they are right to be frustrated. Linux kernel folks, those DoD guys actually know quite a few things about security, maybe its ok that they taught me something and the code reflects that? We will conform on this if requested to by akpm, but somehow I doubt he will quite honestly. akpm? - 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/
List of things requested by lkml for reiser4 inclusion (to review)
We haven't been sending much email out, but we have been working away. We just finished the VFS work, and will send a patch out on Monday. akpm asked for a bullet list of things suggested on lkml as issues for inclusion. There are some things that I would like akpm to confirm represent the official opinion/consensus as opposed to just someone posting an opinion and perhaps not being right. I assure you that all points made by commenters were considered carefully, and I thank all of them for their time. If we lose every remaining point of this list, we can generate a patch in a few days, because the VFS work was the only substantive (in coding hours) task, and it is done. Do I remember right that the submission deadline is a week from Monday for 2.6.14 inclusion? This is supposed to be a bullet list, so I don't list here the line by line minor code improvements sent to us, most of which were incorporated, but let me take a moment to thanks those who donated them. Hans 1. pseudo files or files disabled. It remains a point of (extraordinary) contention as to whether it can be fixed, we want to keep the code around until we can devote proper resources into proving it can be (or until we fail to prove it can be and remove it). We don't want to delay the rest of the code for that proof, but we still think it can be done (by several different ways of which we need to select one and make it work.) Let us postpone contention on this until the existence of a patch that cannot crash makes contention purposeful, shall we? 2. dependency on 4k stack turned off removed as requested 3. remove conditional variable code, use wait queues instead. not done. There are times when reduced functionality aids debugging. kcond is (literally) textbook code. We don't care enough to fight much for it, but akpm, what is your opinion? Will remove if akpm asks us to. 4. remove reiser4_drop_inode done. 5. remove undesired abstraction layer right below reiser4 VFS hooks. done. This was a big job just completed. 6. remove type safe lists and type safe hash queues. not done, it is not clear that the person asking for this represents a unified consensus of lkml. Other persons instead asked that it just be moved out of reiser4 code into the generic kernel code, which implies they did not object to it. There are many who like being type safe. Akpm, what do you yourself think? 7. remove fs/reiser4/lib.h:/div64_32. is being replaced by the linux one. 8. Remove all assertions because they clutter the code and make it hard to read We think this person was not an experienced security specialist, and that what we do is considered by professional code auditors to be laudable practice. We can supply an emacs macro that makes them greyed out. I myself found the assertions to be distracting at first (though functional and especially necessary for a DARPA funded project), and then after time got used to them, and now I understand that it was just my inexperience that caused the discomfort. I now have a more sophisticated subconscious that is not discomforted or distracted by them. People debugging find them very useful. Defense branches tear their hair out at how difficult it is to get the commercial software they use coded this way, and I think they are right to be frustrated. Linux kernel folks, those DoD guys actually know quite a few things about security, maybe its ok that they taught me something and the code reflects that? We will conform on this if requested to by akpm, but somehow I doubt he will quite honestly. akpm? - 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/
Re: List of things requested by lkml for reiser4 inclusion (to review)
Chris Shoemaker wrote: On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote: If we lose every remaining point of this list, we can generate a patch in a few days, because the VFS work was the only substantive (in coding hours) task, and it is done. Do I remember right that the submission deadline is a week from Monday for 2.6.14 inclusion? No. 14 days from release date of 2.6.13, which was 8/29, so deadline is 9/12, this coming Monday. -chris IIRC, Linus announced that since he was going on vacation for 7 days, this release only it would be 3 weeks, so it is a week from Monday that we must submit by, yes? Hans - 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/
Re: List of things requested by lkml for reiser4 inclusion (to review)
Christoph Hellwig wrote: 6. remove type safe lists and type safe hash queues. not done, it is not clear that the person asking for this represents a unified consensus of lkml. Other persons instead asked that it just be moved out of reiser4 code into the generic kernel code, which implies they did not object to it. There are many who like being type safe. Akpm, what do you yourself think? I think quite a few people complained ;-) I remember that you complained. It's huge CPP abuse can you define what that means? and how abuse differs from cleverness? This code was not my idea, but it seemed more cleverness than abuse to me when I read it. which we generally don't want - at least for the hash case we already had something similar (linux/ghash.h and got rid of it). That beeing said a generic hash abstraction without too much CPP abuse might be really useful, but the list code should certainly go. 8. Remove all assertions because they clutter the code and make it hard to read We think this person was not an experienced security specialist, please stop attacking people personally all the time. It is not an attack, fewer than 1% of programmers are security specialists, and I go on to say that until I was educated by some such specialists, I would have agreed with him, so I don't think you can view it as an attack. I hardly expect most people to hang out with the DoD. You're certainly not what I'd call an experienced security specialist either, but fortunately that doesn't matter for this case at all. Removing all assertations certainly doesn't make sense, we have them all over the tree. Whether your own assert macros makes sense is a different question, but given that you use something similar in reiser3 and lots of other drivers have their own things built around BUG() I won't complain to loudly. What should go on the other hand are useless assertation, like one that asserts that something is non-NULL just before dereferencing it - the latter gives a backtrace just as nice. I'll be happy to accept point of code improvements. As additional requirements please give people time to actually audit the codebase. 9 months time given so far I've started but it's quite a pain with all the plugin indirections right now. Here I sympathize with you. If anyone has ideas for how to comment it, etc., to make it trivial to follow the indirections, I am all ears. It annoys me also. One major item I found is that you're using your own code for the read/write file operations, As I remember, there were things that did not code right using the generic code, and I told the guys to code it right. I no longer remember what those things were, quite honestly, but I remember they affected performance. The whole idea of vfs operations is that each file system gets to do them its own way, and please remember that we code for more than just use on Linux. which not only duplicates core code but also lacks features (vectored I/O, AIO, direct I/O) from the common code in time and is totally buggy (it has no chance on working on architectures that have completely separate address spaces for user/kernel like s390, please check how they define PAGE_OFFSET). zam, please look at that on Tuesday. Depending on your requirements you might not use the complete generic code, but you should at least use the most important fragments, ala XFS or ocfs, and improve them where needed. Oh we do try to do that where it does what we need. However, you should keep in mind that reiser4 is not made just for Linux. Our code needs to be at least moderately self-contained. A very annoying small thing that comes to mind is the usage of reiser4_internal. Please remove it, all but exported symbol are module-private. Here I mostly agree. Edward, can you work on a patch to fix it? Thanks. Christoph, thanks kindly for the donation of your time to improving our work. - 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/
Re: List of things requested by lkml for reiser4 inclusion (to review)
Andrew Morton wrote: 1. pseudo files or files disabled. It remains a point of (extraordinary) contention as to whether it can be fixed, we want to keep the code around until we can devote proper resources into proving it can be (or until we fail to prove it can be and remove it). We don't want to delay the rest of the code for that proof, but we still think it can be done (by several different ways of which we need to select one and make it work.) Let us postpone contention on this until the existence of a patch that cannot crash makes contention purposeful, shall we? I'd prefer that unused code simply not be present in the tree, sorry. Ok, edward will remove. 2. dependency on 4k stack turned off removed as requested So it all runs OK with 4k stacks now? vs will answer this. 3. remove conditional variable code, use wait queues instead. not done. There are times when reduced functionality aids debugging. kcond is (literally) textbook code. We don't care enough to fight much for it, but akpm, what is your opinion? Will remove if akpm asks us to. kcond is only used in a couple of places. One looks like it could use complete() and the other is a standard wait-for-something-to-do kernel thread loop, which we open-code without any fuss in lots of places (kjournald, loop, pdflush, etc). So yes, I'd be inclined to remove kcond please. ok, zam will do so. Also, it would be better to use the kthread API rather than open-coding kernel_thread() calls. If you think that reiser4 needs additional ways of controlling kernel threads then feel free to enhance the kthread API. 6. remove type safe lists and type safe hash queues. not done, it is not clear that the person asking for this represents a unified consensus of lkml. Other persons instead asked that it just be moved out of reiser4 code into the generic kernel code, which implies they did not object to it. There are many who like being type safe. Akpm, what do you yourself think? The type-unsafety of existing list_heads gives me conniptions too. Yes, it'd be nice to have a type-safe version available. That being said, I don't see why such a thing cannot be a wrapper around the existing list_head functions. Yes, there will be some ghastly C-templates-via-CPP stuff, best avoided by not looking at the file ;) We should aim for a complete 1:1 relationship between list_heads and type-safe lists. So people know what they're called, know how they work, etc. We shouldn't go adding things called rx_event_list_pop_back() when everyone has learned the existing list API. Of course, it would have been better to do this work as a completely separate kernel feature rather than bundling it with a filesystem. If this isn't a thing your team wants to take on now then yes, I'd be inclined to switch reiser4 to list_heads. Ok, Edward, this task is yours. Edward, how big you make the task is up to you so long as it is done by Monday. If you run low on time, get help with it. - 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/
Re: RFC: i386: kill !4KSTACKS
Adrian Bunk wrote: >4Kb kernel stacks are the future on i386, and it seems the problems it >initially caused are now sorted out. > >Does anyone knows about any currently unsolved problems? > >I'd like to: >- get a patch into on of the next -mm kernels that unconditionally > enables 4KSTACKS >- if there won't be new reports of breakages, send a patch to > completely remove !4KSTACKS for 2.6.15 > >In -mm, Reiser4 still has a dependency on !4KSTACKS. >I've mentioned this at least twice to the Reiser4 people, and they >should check why this dependency is still there and if there are still >stack issues in Reiser4 fix them. > >If not people using Reiser4 on i386 will have to decide whether to >switch the filesystem or the architecture... > >cu >Adrian > > > Can you wait just one month after we get in for this? Or even 2 weeks. vs needs a weekend, etc. - 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/
Re: RFC: i386: kill !4KSTACKS
Adrian Bunk wrote: 4Kb kernel stacks are the future on i386, and it seems the problems it initially caused are now sorted out. Does anyone knows about any currently unsolved problems? I'd like to: - get a patch into on of the next -mm kernels that unconditionally enables 4KSTACKS - if there won't be new reports of breakages, send a patch to completely remove !4KSTACKS for 2.6.15 In -mm, Reiser4 still has a dependency on !4KSTACKS. I've mentioned this at least twice to the Reiser4 people, and they should check why this dependency is still there and if there are still stack issues in Reiser4 fix them. If not people using Reiser4 on i386 will have to decide whether to switch the filesystem or the architecture... cu Adrian Can you wait just one month after we get in for this? Or even 2 weeks. vs needs a weekend, etc. - 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/
Re: [PATCH 00/14] GFS
Arjan van de Ven wrote: >On Tue, 2005-08-02 at 16:57 +0200, Jan Engelhardt wrote: > > >>>* Why use your own journalling layer and not say ... jbd ? >>> >>> >>Why does reiser use its own journalling layer and not say ... jbd ? >> >> > >because reiser got merged before jbd. Next question. > > That is the wrong reason. We use our own journaling layer for the reason that Vivaldi used his own melody. I don't know anything about GFS, but expecting a filesystem author to use a journaling layer he does not want to is a bit arrogant. Now, if you got into details, and said jbd does X, Y and Z, and GFS does the same X and Y, and does not do Z as well as jbd, that would be a more serious comment. He might want to look at how reiser4 does wandering logs instead of using jbd. but I would never claim that for sure some other author should be expected to use it. and something like changing one's journaling system is not something to do just before a merge. >Now the question for GFS is still a valid one; there might be reasons to >not use it (which is fair enough) but if there's no real reason then >using jdb sounds a lot better given it's maturity (and it is used by 2 >filesystems in -mm already). > > > >- >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/ > > > > - 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/
Re: [PATCH 00/14] GFS
Arjan van de Ven wrote: On Tue, 2005-08-02 at 16:57 +0200, Jan Engelhardt wrote: * Why use your own journalling layer and not say ... jbd ? Why does reiser use its own journalling layer and not say ... jbd ? because reiser got merged before jbd. Next question. That is the wrong reason. We use our own journaling layer for the reason that Vivaldi used his own melody. I don't know anything about GFS, but expecting a filesystem author to use a journaling layer he does not want to is a bit arrogant. Now, if you got into details, and said jbd does X, Y and Z, and GFS does the same X and Y, and does not do Z as well as jbd, that would be a more serious comment. He might want to look at how reiser4 does wandering logs instead of using jbd. but I would never claim that for sure some other author should be expected to use it. and something like changing one's journaling system is not something to do just before a merge. Now the question for GFS is still a valid one; there might be reasons to not use it (which is fair enough) but if there's no real reason then using jdb sounds a lot better given it's maturity (and it is used by 2 filesystems in -mm already). - 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/ - 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/
Re: Linux On-Demand Network Access (LODNA)
Peter Staubach wrote: > Hans Reiser wrote: > >> Peter, do you agree with his point that mounting should be something >> ordinary users can do on mountpoints they have write permission for? >> >> Do you agree that a systematic review of user friendliness would help >> NFS? Do you think that NFS should look at SFS and consider adopting >> some of its features? >> > > I think that connecting to required data could be more easily done than > currently. I don't know about allowing file systems to be mounted without > some form of control or resource utilization controls however. > > I do agree that the entire user experience associated with using and > trying > to administrate an NFS network could stand a good, long, hard look. > > Traditional tools such as the automounter were nice 15 years ago, but > have > not evolved with the world, nor have the rest of the system tools for > monitoring and managing NFS clients and servers. > > I could definitely envision better ways to handle things. In the past, > many of the arguments against making things better were security related. > There has been strong (relative term) security available to NFS > implementations > since 1997, but many vendors have not implemented it and many > customers found > it difficult to deploy because the underlying tools were very > difficult to > deploy. Many of the vendors are now implementing the security > framework, but > more work is required on the underlying security mechanisms, making them > easier to deploy. > > With proper security, usable monitoring and management tools, and > flexible > resource controls, then I wouldn't see why NFS mounts should be anything > special. > >Thanx... > > ps > > I would encourage you to look at SFS. it fixes a lot, making adding what Vlad asks for reasonable. - 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/
Re: Linux On-Demand Network Access (LODNA)
Peter Staubach wrote: > Vlad C. wrote: > >> --- Hans Reiser <[EMAIL PROTECTED]> wrote: >> >> >>> Please treat at greater length how your proposal >>> differs from NFS. >>> >> >> >> I think NFS is not flexible enough because: >> >> 1) NFS requires synchronization of passwd files or >> NIS/LDAP to authenticate users (which themselves >> require root access on both server and client to >> install) >> 2) NFS by definition understands only its own network >> protocol. >> 3) NFS requires root privileges on the client to >> mount. I'm not aware of a way to let normal users >> mount an NFS partition other than listing it in the >> client's fstab and adding the 'users' option... but >> then changing fstab still requires root access. >> 4) Users have to contact their sysadmin every time >> they want to mount a different partition, a different >> subdirectory of the same partition, or if they want to >> change the local mountpoint, all because the partition >> and mountpoint are hard-coded in fstab. >> >> On the other hand, I envision the following: >> > > Please keep in mind that these are restrictions of the current NFS > implementation and are not inherent in an NFS solution. > > The implied need for flexibility is being addressed by NFSv4 and the > ability to understand multiple versions of protocols and multiple > protocols is already resident in the system. We could do some work > to make it more transparent if desired, but it already works. > >Thanx... > > ps > > Peter, do you agree with his point that mounting should be something ordinary users can do on mountpoints they have write permission for? Do you agree that a systematic review of user friendliness would help NFS? Do you think that NFS should look at SFS and consider adopting some of its features? Hans - 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/
Re: Linux On-Demand Network Access (LODNA)
Peter Staubach wrote: Vlad C. wrote: --- Hans Reiser [EMAIL PROTECTED] wrote: Please treat at greater length how your proposal differs from NFS. I think NFS is not flexible enough because: 1) NFS requires synchronization of passwd files or NIS/LDAP to authenticate users (which themselves require root access on both server and client to install) 2) NFS by definition understands only its own network protocol. 3) NFS requires root privileges on the client to mount. I'm not aware of a way to let normal users mount an NFS partition other than listing it in the client's fstab and adding the 'users' option... but then changing fstab still requires root access. 4) Users have to contact their sysadmin every time they want to mount a different partition, a different subdirectory of the same partition, or if they want to change the local mountpoint, all because the partition and mountpoint are hard-coded in fstab. On the other hand, I envision the following: Please keep in mind that these are restrictions of the current NFS implementation and are not inherent in an NFS solution. The implied need for flexibility is being addressed by NFSv4 and the ability to understand multiple versions of protocols and multiple protocols is already resident in the system. We could do some work to make it more transparent if desired, but it already works. Thanx... ps Peter, do you agree with his point that mounting should be something ordinary users can do on mountpoints they have write permission for? Do you agree that a systematic review of user friendliness would help NFS? Do you think that NFS should look at SFS and consider adopting some of its features? Hans - 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/
Re: Linux On-Demand Network Access (LODNA)
Peter Staubach wrote: Hans Reiser wrote: Peter, do you agree with his point that mounting should be something ordinary users can do on mountpoints they have write permission for? Do you agree that a systematic review of user friendliness would help NFS? Do you think that NFS should look at SFS and consider adopting some of its features? I think that connecting to required data could be more easily done than currently. I don't know about allowing file systems to be mounted without some form of control or resource utilization controls however. I do agree that the entire user experience associated with using and trying to administrate an NFS network could stand a good, long, hard look. Traditional tools such as the automounter were nice 15 years ago, but have not evolved with the world, nor have the rest of the system tools for monitoring and managing NFS clients and servers. I could definitely envision better ways to handle things. In the past, many of the arguments against making things better were security related. There has been strong (relative term) security available to NFS implementations since 1997, but many vendors have not implemented it and many customers found it difficult to deploy because the underlying tools were very difficult to deploy. Many of the vendors are now implementing the security framework, but more work is required on the underlying security mechanisms, making them easier to deploy. With proper security, usable monitoring and management tools, and flexible resource controls, then I wouldn't see why NFS mounts should be anything special. Thanx... ps I would encourage you to look at SFS. it fixes a lot, making adding what Vlad asks for reasonable. - 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/
Re: reiser4 plugins
Neil Brown wrote: >On Tuesday July 12, [EMAIL PROTECTED] wrote: > > >>Neil Brown wrote: >> >> >> >>>Maybe it is worth repeating Al Viro's suggestion at this point. I >>>don't have a reference but the idea was basically that if you open >>>"/foo" and get filedescriptor N, then >>> /proc/self/fds/N-meta >>>is a directory which contains all the meta stuff for "/foo". >>>Then it is trivial to get the 'meta' stuff given a filedescriptor and >>>if you have a pathname, you can always get yourself a filedescriptor. >>> >>> >>> >>> >>This sound like it might be cute, but filedescriptors are too heavy >>weight for stat data accesses in quantity. >> >>In general, the whole file handle paradigm is too heavy for lightweight >>files. >> >> > >That may well be true, but is completely orthogonal to filesystem name >semantics. > >If you find file descriptors too slow, come up with an alternate (I >suspect you have in the reiser4 syscall, but I haven't looked at >that yet), implement it in the VFS, and show the world benchmarks of >real-world applications that go faster with this new interface. > >I doubt that you would then have a great deal of trouble in getting >the interface accepted (some trouble of course as you will need to >convince a few people, but numbers speak quite loudly). > >I suspect that there might need to be a new internal interface into >filesystems, and filesystems which don't provide that will not get the >same speed benefit, but that is perfectly acceptable. > >NeilBrown > > > > We need time, and then we can demonstrate sys_reiser4, it is not ready for showing yet. Hans - 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/
Re: Linux On-Demand Network Access (LODNA)
You might look into SFS by David Mazieres, some concepts in it are likely to interest you. Hans Vlad C. wrote: >--- Hans Reiser <[EMAIL PROTECTED]> wrote: > > >>Please treat at greater length how your proposal >>differs from NFS. >> >> > >I think NFS is not flexible enough because: > >1) NFS requires synchronization of passwd files or >NIS/LDAP to authenticate users (which themselves >require root access on both server and client to >install) >2) NFS by definition understands only its own network >protocol. >3) NFS requires root privileges on the client to >mount. I'm not aware of a way to let normal users >mount an NFS partition other than listing it in the >client's fstab and adding the 'users' option... but >then changing fstab still requires root access. >4) Users have to contact their sysadmin every time >they want to mount a different partition, a different >subdirectory of the same partition, or if they want to >change the local mountpoint, all because the partition >and mountpoint are hard-coded in fstab. > >On the other hand, I envision the following: > >1) No authentication layer required other than the >authentication built into the protocol. All the user >needs is the DNS/IP address of the server, a username, >a password, a path on the server, and a local >directory they own to act as a mountpoint. Note that >the user's identity on the server is not tied to his >identity on the client, as it is the case with NFS, >but rather the user can chose which username to >"Connect As" when he performs the mount. >2) Support for multiple network protocols. >3) No need for root privileges when choosing what to >mount and where to mount. Some may say this is a >security risk, but I see it as improved usability. >After all, DE-level implementations like KDE's fish:/ >don't require root privileges either. Nevertheless, I >think there should be some sort of switch where the >sysadmin can allow/deny user mounting on a global or >per user basis (rather than a per fstab-line basis). > >Reasons 3 and 4 for why NFS is not flexible enough >could also apply to the current Linux implementation >of smbfs, which leads me to believe that part of the >problem lies in the fact that users can't mount >locations that aren't explicitly listed in fstab. I >guess a per fstab-line basis of allowing mounts makes >sense when there are a finite number of devices, but >it doesn't make much sense when there are an infinite >number of network addresses. I'm just thinking out >loud here, but would it be possible to specify ranges >of addresses and directories using wildcards? Such a >line in fstab would look like: >*.myhost.com:/home/* /home/* nfs >rsize=8192,wsize=8192,timeo=14,users > >In this case, users could do: >mount -t nfs host1.myhost.com:/home/username >~/remote_home > >but they couldn't do: >mount -t nfs host1.myhost.com:/tmp ~/remote_tmp > >After receiving several suggestions, it appears that >FUSE (http://fuse.sourceforge.net/) and the various >projects that build on it >(http://fuse.sourceforge.net/filesystems.html) have >the potential to do a lot of what I had envisioned >LODNA doing. Therefore, I realize that there's >probably no need for yet another VFS framework ;) >Nevertheless, I think there is room for improvement >when it comes to giving users more flexibility in >mounting network locations (as described above). > >Thanks, >Vlad > >__ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > > > - 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/
Re: reiser4 plugins
David Masover wrote: > > That's why we're trying to find something that people won't actually > touch, especially since if we design it right, this will be the last > delimiter introduced at the fs/vfs level. Uh, no, there needs to be about a dozen or so more. But not this year. - 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/
Re: realtime-preempt + reiser4?
Lee Revell wrote: >On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote: > > >>Ingo Molnar's realtime-preempt patches used to be based on the -mm >>kernels, but now they appear to be based on the mainline kernels, so >>they don't support reiser4 (at least until reiser4 is merged into >>mainline, which is looking uncertain as I understand it). >> >> > >It's not uncertain, the reiser4 people just have to address the issues >that were raised on LKML before it will be merged, just like everyone >else. > > Maybe tomorrow the changes will compile. they have been written. - 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/
Re: Linux On-Demand Network Access (LODNA)
Please treat at greater length how your proposal differs from NFS. Hans Vlad C. wrote: >Recent discussion on ReiserFS 4 has focused on the >advantages and disadvantages of VFS at the kernel >level versus the Desktop Environment (DE) level. I >believe network locations should be administered by >the kernel in a proposed framework called Linux >On-Demand Network Access (LODNA), which would achieve >seamless network integration regardless (or even in >the absence) of DEs, thus increasing usability. > >INTRODUCTION: > >When VFS is implemented at the KDE/GNOME level, we >end up with the unfortunate situation where only >applications native to that DE can access its VFS >files. For example, Mozilla and Firefox (which are >GTK-based) can't access network locations set up under >KDE (see >https://bugzilla.mozilla.org/show_bug.cgi?id=298848). >Making an application aware of non-native VFS requires >serious amount of work, not only to use the other DE's >libraries, but also to embed miniature network clients >for every protocol the application supports. > >The same problem appears in OpenOffice: even though it >can use the KDE filepicker, whenever it accesses a >file on an SSH network location, a message pops up >saying "Protocol 'fish' is supported only partially. >Local copy of the file will be created." > >If Mozilla/Firefox and OpenOffice, which are some of >the most popular applications and which have a strong >developer base, haven't yet been able to achieve >cross-VFS compatibility, you can be certain that other >applications are in the same or worse situation. > >These two examples show why VFS at the DE level is a >temporary hack that only hides the need for such >functionality in the kernel. This hassle can be >completely avoided if the kernel provides standard I/O >functions for files in network locations >(ssh/webdav/ftp/smb/...) because opening and saving >network files would then become completely transparent >(i.e. no different from accessing a local file) from >the application's point of view. > >Having this functionality in the kernel would be a >huge usability plus: we would solve all these problems >in one swish, save application developers a lot of >time, and give users the peace of mind to know that >they can seamlessly access their network files no >matter what application they use. > >PROPOSAL: Linux On-Demand Network Access (LODNA) > >Users would be able to mount network locations under >directories they own. For example, to create a network >location on my home computer pointing to my work >computer (via ssh), I would do: >mount -t ssh [EMAIL PROTECTED]:~ >/home/username/net/remote_computer > >>From then on, whenever I change directory to >/home/username/net/remote_computer, I would be able to >see the files in my computer at work as if they were >local - no more need for fancy VPN! > >Similarly, I would also be able to do: >mount -t smbfs [EMAIL PROTECTED]:~ >/home/username/net/remote_computer >mount -t webdav [EMAIL PROTECTED]:~ >/home/username/net/remote_computer >mount -t ftp [EMAIL PROTECTED]:~ >/home/username/net/remote_computer > >Advantages of LODNA: > >1) Network locations would be fixed in the directory >tree, rather than float around in a DE abstraction >like fish:/ . >2) Remote files would be accessible by all >applications, even the shell. >3) LODNA would be independent of Desktop Environments >(although if present, they could provide GUIs for >things that could otherwise be done from the command >line). For example, KDE could use its existing "Add a >Network Folder" wizard to help users mount network >locations. >4) The user could give or deny other local users >access to his remote locations simply by setting the >permissions of the mount point (eg. chmod 700 >/home/username/net/remote_computer). >5) LODNA would help users who want to access files on >their Local Area Network but who don't know the exact >name or IP address of the destination computer. Such >users could use KDE's Konqueror File Manager >(http://www.konqueror.org/) with the Smb4k >(http://smb4k.berlios.de/) plugin to discover all the >samba servers on their LAN. They could then simply >right-click on a server/share and select "Mount", >which would take them to the "Add a Network Folder" >wizard. >6) LODNA would combine the transparency of NFS with >the flexibility of SSH/SMB/WebDav/FTP. >7) LODNA would allow users to build and manage their >own VPN client. > >CONCLUSION: > >Linux On-Demand Network Access (LODNA) is a proposed >kernel-based method for accessing network locations. >It would provide transparent, unified network access >to all applications and pave the way for highly >intuitive GUIs for managing diverse networks. As a >built-in, multi-protocol VPN client, LODNA would >greatly help employees who work from home, and be a >much needed step towards making Linux viable on the >desktop. > >For now, LODNA is only a concept, but the pieces >needed to make it happen already exist - they just
Re: reiser4 plugins
Neil Brown wrote: > > >Maybe it is worth repeating Al Viro's suggestion at this point. I >don't have a reference but the idea was basically that if you open >"/foo" and get filedescriptor N, then > /proc/self/fds/N-meta >is a directory which contains all the meta stuff for "/foo". >Then it is trivial to get the 'meta' stuff given a filedescriptor and >if you have a pathname, you can always get yourself a filedescriptor. > > This sound like it might be cute, but filedescriptors are too heavy weight for stat data accesses in quantity. In general, the whole file handle paradigm is too heavy for lightweight files. Hans - 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/
Re: realtime-preempt + reiser4?
Lee Revell wrote: On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote: Ingo Molnar's realtime-preempt patches used to be based on the -mm kernels, but now they appear to be based on the mainline kernels, so they don't support reiser4 (at least until reiser4 is merged into mainline, which is looking uncertain as I understand it). It's not uncertain, the reiser4 people just have to address the issues that were raised on LKML before it will be merged, just like everyone else. Maybe tomorrow the changes will compile. they have been written. - 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/
Re: reiser4 plugins
David Masover wrote: That's why we're trying to find something that people won't actually touch, especially since if we design it right, this will be the last delimiter introduced at the fs/vfs level. Uh, no, there needs to be about a dozen or so more. But not this year. - 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/
Re: Linux On-Demand Network Access (LODNA)
You might look into SFS by David Mazieres, some concepts in it are likely to interest you. Hans Vlad C. wrote: --- Hans Reiser [EMAIL PROTECTED] wrote: Please treat at greater length how your proposal differs from NFS. I think NFS is not flexible enough because: 1) NFS requires synchronization of passwd files or NIS/LDAP to authenticate users (which themselves require root access on both server and client to install) 2) NFS by definition understands only its own network protocol. 3) NFS requires root privileges on the client to mount. I'm not aware of a way to let normal users mount an NFS partition other than listing it in the client's fstab and adding the 'users' option... but then changing fstab still requires root access. 4) Users have to contact their sysadmin every time they want to mount a different partition, a different subdirectory of the same partition, or if they want to change the local mountpoint, all because the partition and mountpoint are hard-coded in fstab. On the other hand, I envision the following: 1) No authentication layer required other than the authentication built into the protocol. All the user needs is the DNS/IP address of the server, a username, a password, a path on the server, and a local directory they own to act as a mountpoint. Note that the user's identity on the server is not tied to his identity on the client, as it is the case with NFS, but rather the user can chose which username to Connect As when he performs the mount. 2) Support for multiple network protocols. 3) No need for root privileges when choosing what to mount and where to mount. Some may say this is a security risk, but I see it as improved usability. After all, DE-level implementations like KDE's fish:/ don't require root privileges either. Nevertheless, I think there should be some sort of switch where the sysadmin can allow/deny user mounting on a global or per user basis (rather than a per fstab-line basis). Reasons 3 and 4 for why NFS is not flexible enough could also apply to the current Linux implementation of smbfs, which leads me to believe that part of the problem lies in the fact that users can't mount locations that aren't explicitly listed in fstab. I guess a per fstab-line basis of allowing mounts makes sense when there are a finite number of devices, but it doesn't make much sense when there are an infinite number of network addresses. I'm just thinking out loud here, but would it be possible to specify ranges of addresses and directories using wildcards? Such a line in fstab would look like: *.myhost.com:/home/* /home/* nfs rsize=8192,wsize=8192,timeo=14,users In this case, users could do: mount -t nfs host1.myhost.com:/home/username ~/remote_home but they couldn't do: mount -t nfs host1.myhost.com:/tmp ~/remote_tmp After receiving several suggestions, it appears that FUSE (http://fuse.sourceforge.net/) and the various projects that build on it (http://fuse.sourceforge.net/filesystems.html) have the potential to do a lot of what I had envisioned LODNA doing. Therefore, I realize that there's probably no need for yet another VFS framework ;) Nevertheless, I think there is room for improvement when it comes to giving users more flexibility in mounting network locations (as described above). Thanks, Vlad __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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/
Re: reiser4 plugins
Neil Brown wrote: On Tuesday July 12, [EMAIL PROTECTED] wrote: Neil Brown wrote: Maybe it is worth repeating Al Viro's suggestion at this point. I don't have a reference but the idea was basically that if you open /foo and get filedescriptor N, then /proc/self/fds/N-meta is a directory which contains all the meta stuff for /foo. Then it is trivial to get the 'meta' stuff given a filedescriptor and if you have a pathname, you can always get yourself a filedescriptor. This sound like it might be cute, but filedescriptors are too heavy weight for stat data accesses in quantity. In general, the whole file handle paradigm is too heavy for lightweight files. That may well be true, but is completely orthogonal to filesystem name semantics. If you find file descriptors too slow, come up with an alternate (I suspect you have in the reiser4 syscall, but I haven't looked at that yet), implement it in the VFS, and show the world benchmarks of real-world applications that go faster with this new interface. I doubt that you would then have a great deal of trouble in getting the interface accepted (some trouble of course as you will need to convince a few people, but numbers speak quite loudly). I suspect that there might need to be a new internal interface into filesystems, and filesystems which don't provide that will not get the same speed benefit, but that is perfectly acceptable. NeilBrown We need time, and then we can demonstrate sys_reiser4, it is not ready for showing yet. Hans - 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/
Re: reiser4 plugins
Neil Brown wrote: Maybe it is worth repeating Al Viro's suggestion at this point. I don't have a reference but the idea was basically that if you open /foo and get filedescriptor N, then /proc/self/fds/N-meta is a directory which contains all the meta stuff for /foo. Then it is trivial to get the 'meta' stuff given a filedescriptor and if you have a pathname, you can always get yourself a filedescriptor. This sound like it might be cute, but filedescriptors are too heavy weight for stat data accesses in quantity. In general, the whole file handle paradigm is too heavy for lightweight files. Hans - 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/
Re: Linux On-Demand Network Access (LODNA)
Please treat at greater length how your proposal differs from NFS. Hans Vlad C. wrote: Recent discussion on ReiserFS 4 has focused on the advantages and disadvantages of VFS at the kernel level versus the Desktop Environment (DE) level. I believe network locations should be administered by the kernel in a proposed framework called Linux On-Demand Network Access (LODNA), which would achieve seamless network integration regardless (or even in the absence) of DEs, thus increasing usability. INTRODUCTION: When VFS is implemented at the KDE/GNOME level, we end up with the unfortunate situation where only applications native to that DE can access its VFS files. For example, Mozilla and Firefox (which are GTK-based) can't access network locations set up under KDE (see https://bugzilla.mozilla.org/show_bug.cgi?id=298848). Making an application aware of non-native VFS requires serious amount of work, not only to use the other DE's libraries, but also to embed miniature network clients for every protocol the application supports. The same problem appears in OpenOffice: even though it can use the KDE filepicker, whenever it accesses a file on an SSH network location, a message pops up saying Protocol 'fish' is supported only partially. Local copy of the file will be created. If Mozilla/Firefox and OpenOffice, which are some of the most popular applications and which have a strong developer base, haven't yet been able to achieve cross-VFS compatibility, you can be certain that other applications are in the same or worse situation. These two examples show why VFS at the DE level is a temporary hack that only hides the need for such functionality in the kernel. This hassle can be completely avoided if the kernel provides standard I/O functions for files in network locations (ssh/webdav/ftp/smb/...) because opening and saving network files would then become completely transparent (i.e. no different from accessing a local file) from the application's point of view. Having this functionality in the kernel would be a huge usability plus: we would solve all these problems in one swish, save application developers a lot of time, and give users the peace of mind to know that they can seamlessly access their network files no matter what application they use. PROPOSAL: Linux On-Demand Network Access (LODNA) Users would be able to mount network locations under directories they own. For example, to create a network location on my home computer pointing to my work computer (via ssh), I would do: mount -t ssh [EMAIL PROTECTED]:~ /home/username/net/remote_computer From then on, whenever I change directory to /home/username/net/remote_computer, I would be able to see the files in my computer at work as if they were local - no more need for fancy VPN! Similarly, I would also be able to do: mount -t smbfs [EMAIL PROTECTED]:~ /home/username/net/remote_computer mount -t webdav [EMAIL PROTECTED]:~ /home/username/net/remote_computer mount -t ftp [EMAIL PROTECTED]:~ /home/username/net/remote_computer Advantages of LODNA: 1) Network locations would be fixed in the directory tree, rather than float around in a DE abstraction like fish:/ . 2) Remote files would be accessible by all applications, even the shell. 3) LODNA would be independent of Desktop Environments (although if present, they could provide GUIs for things that could otherwise be done from the command line). For example, KDE could use its existing Add a Network Folder wizard to help users mount network locations. 4) The user could give or deny other local users access to his remote locations simply by setting the permissions of the mount point (eg. chmod 700 /home/username/net/remote_computer). 5) LODNA would help users who want to access files on their Local Area Network but who don't know the exact name or IP address of the destination computer. Such users could use KDE's Konqueror File Manager (http://www.konqueror.org/) with the Smb4k (http://smb4k.berlios.de/) plugin to discover all the samba servers on their LAN. They could then simply right-click on a server/share and select Mount, which would take them to the Add a Network Folder wizard. 6) LODNA would combine the transparency of NFS with the flexibility of SSH/SMB/WebDav/FTP. 7) LODNA would allow users to build and manage their own VPN client. CONCLUSION: Linux On-Demand Network Access (LODNA) is a proposed kernel-based method for accessing network locations. It would provide transparent, unified network access to all applications and pave the way for highly intuitive GUIs for managing diverse networks. As a built-in, multi-protocol VPN client, LODNA would greatly help employees who work from home, and be a much needed step towards making Linux viable on the desktop. For now, LODNA is only a concept, but the pieces needed to make it happen already exist - they just need to be integrated into the kernel, perhaps as a ReiserFS 4 plugin or by another method. I welcome your suggestions! Cheers, Vlad
Re: reiser4 plugins
Horst von Brand wrote: >Hans Reiser <[EMAIL PROTECTED]> wrote: > > >>Stefan Smietanowski wrote: >> >> >>>I think "..." and ".meta" both serve as a logical delimiter. However >>>some programs implement their own "..." which would make it clash with >>>them. Naturally if some program created a directory called .meta we're >>>equally screwed. >>> >>> > > > >>I chose '' (four dots) because it clashes with less, not three dots. >> >> > >Is this some kind of "My dots are more than yours" contest?! > >/None/ of them is safe. ".meta", "...", "", ".this.has.five.dots." are >all perfectly legal file (or directory) names, POSIXly. If any one of them >won't do, none will. > > There is a long history of encroaching namespaces by creating new keywords in CS, and it is a survivable problem. Clearcase (the version control filesystem) is an excellent example. They have special meanings for @ and some other common characters, and you have to learn how to escape those characters if you use them in Clearcase. It works, it makes users happy, in practice it is far less of a problem than one might think. I think there were two or three times I had to remember how to escape things in 2 years of using it. Better to spend one's mind looking for bugs instead of this issue. - 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/
Re: reiser4 plugins
Stefan Smietanowski wrote: > > I think "..." and ".meta" both serve as a logical delimiter. However > some programs implement their own "..." which would make it clash with > them. Naturally if some program created a directory called .meta we're > equally screwed. I chose '' (four dots) because it clashes with less, not three dots. - 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/
Re: reiser4 vs politics: linux misses out again
Jim Crilly wrote: > >I thought r3 was journaled from the beginning; the Namesys site credits >Chris with the addition of a relocated and large journal. And yes, a good >bit of the patches were from him. > Chris and I disagree about QA methodology, but I am deeply in debt to him for his contributions. R3 did not have a journal at first, that was his contribution, and a major part of what made reiserfs useful to real users. Hans - 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/
Re: reiser4 vs politics: linux misses out again
Horst von Brand wrote: > > > > >> It's not always >>nescesary to let the demand create the means. Give programmers >>some powerful tools and wait and see what wonderful things start >>to evolve. >> >> > >The sad truth is that if you give a random collection of people powerful >tools they misuse them more often than not, creating a huge mess in the >process. That is why it is so hard to design good tools. > > We are rope makers. Our job is to make good rope. If someone might use it to hang dissidents, that does not mean we should now make the rope too inflexible to form a noose. It is important that we know our place. Our place is to help users express themselves the way they want to. It is not our job to keep them from hanging dissidents. If they hang dissidents, we should not change the way we make rope, we should shoot them. Most of our users don't hang dissidents, to the contrary, they do work of value to society, and need their time saved so that they can do more of it. The users of reiser4 know a lot more than I do, and are much wiser than I am. Because I focus on a narrow little area, I am able to do something useful to help them express their greater wisdom more flexibly. I take pride in that. The belief expressed above that powerful tools will be misused more than well used, and the dislike of power for the users it contains, is why we will never do more than talk past each other. Perhaps we should just agree to disagree. Hans - 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/
Re: reiser4 vs politics: linux misses out again
Horst von Brand wrote: It's not always nescesary to let the demand create the means. Give programmers some powerful tools and wait and see what wonderful things start to evolve. The sad truth is that if you give a random collection of people powerful tools they misuse them more often than not, creating a huge mess in the process. That is why it is so hard to design good tools. We are rope makers. Our job is to make good rope. If someone might use it to hang dissidents, that does not mean we should now make the rope too inflexible to form a noose. It is important that we know our place. Our place is to help users express themselves the way they want to. It is not our job to keep them from hanging dissidents. If they hang dissidents, we should not change the way we make rope, we should shoot them. Most of our users don't hang dissidents, to the contrary, they do work of value to society, and need their time saved so that they can do more of it. The users of reiser4 know a lot more than I do, and are much wiser than I am. Because I focus on a narrow little area, I am able to do something useful to help them express their greater wisdom more flexibly. I take pride in that. The belief expressed above that powerful tools will be misused more than well used, and the dislike of power for the users it contains, is why we will never do more than talk past each other. Perhaps we should just agree to disagree. Hans - 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/
Re: reiser4 vs politics: linux misses out again
Jim Crilly wrote: I thought r3 was journaled from the beginning; the Namesys site credits Chris with the addition of a relocated and large journal. And yes, a good bit of the patches were from him. Chris and I disagree about QA methodology, but I am deeply in debt to him for his contributions. R3 did not have a journal at first, that was his contribution, and a major part of what made reiserfs useful to real users. Hans - 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/
Re: reiser4 plugins
Stefan Smietanowski wrote: I think ... and .meta both serve as a logical delimiter. However some programs implement their own ... which would make it clash with them. Naturally if some program created a directory called .meta we're equally screwed. I chose '' (four dots) because it clashes with less, not three dots. - 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/
Re: reiser4 plugins
Horst von Brand wrote: Hans Reiser [EMAIL PROTECTED] wrote: Stefan Smietanowski wrote: I think ... and .meta both serve as a logical delimiter. However some programs implement their own ... which would make it clash with them. Naturally if some program created a directory called .meta we're equally screwed. I chose '' (four dots) because it clashes with less, not three dots. Is this some kind of My dots are more than yours contest?! /None/ of them is safe. .meta, ..., , .this.has.five.dots. are all perfectly legal file (or directory) names, POSIXly. If any one of them won't do, none will. There is a long history of encroaching namespaces by creating new keywords in CS, and it is a survivable problem. Clearcase (the version control filesystem) is an excellent example. They have special meanings for @ and some other common characters, and you have to learn how to escape those characters if you use them in Clearcase. It works, it makes users happy, in practice it is far less of a problem than one might think. I think there were two or three times I had to remember how to escape things in 2 years of using it. Better to spend one's mind looking for bugs instead of this issue. - 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/
Re: reiser4 vs politics: linux misses out again
Ed Tomlinson wrote: >On Sunday 10 July 2005 01:10, Horst von Brand wrote: > > >>Ed Cogburn <[EMAIL PROTECTED]> wrote: >> >> >>>David Lang wrote: >>> >>> On Fri, 8 Jul 2005, Ed Tomlinson wrote: >No Flame from me. One thing to remember is that Hans and friends >_have_ supported R3 for years. > > >>They let it fall into disrepair when they started work on 4. >> >> > >This is FUD. Hans do you have figures on how many fixes for R3 have >been added in the last year or so? > > No, but I can tell you that > 2/3 were related to features I thought should have been put in V4 instead, and were added in violation of my declared code freeze and without my consent. Naturally, those bugs were routed to the authors of those features. There were maybe 2 bugs in the last 18 months in code not related to code freeze violations, I don't remember exactly. There is a simple reason why Namesys no longer spends much time on bug fixes for V3. The frozen code is too stable to generate bug reports to work on, and the unfrozen code is not ours. If the unfrozen code stopped being maintained, I'd have to do something. It seems to me that you should all hope that V4 gets to where Namesys does not spend much time maintaining it. It means we have no bug reports. Stable branches, and development branches, and only bug fixes get added to the stable branch, it is an old paradigm, and broadly speaking it is still the right paradigm. Guys, Horst is trolling.He has never used our code, and yet. - 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/
Re: reiser4 vs politics: linux misses out again
Ed Tomlinson wrote: On Sunday 10 July 2005 01:10, Horst von Brand wrote: Ed Cogburn [EMAIL PROTECTED] wrote: David Lang wrote: On Fri, 8 Jul 2005, Ed Tomlinson wrote: No Flame from me. One thing to remember is that Hans and friends _have_ supported R3 for years. They let it fall into disrepair when they started work on 4. This is FUD. Hans do you have figures on how many fixes for R3 have been added in the last year or so? No, but I can tell you that 2/3 were related to features I thought should have been put in V4 instead, and were added in violation of my declared code freeze and without my consent. Naturally, those bugs were routed to the authors of those features. There were maybe 2 bugs in the last 18 months in code not related to code freeze violations, I don't remember exactly. There is a simple reason why Namesys no longer spends much time on bug fixes for V3. The frozen code is too stable to generate bug reports to work on, and the unfrozen code is not ours. If the unfrozen code stopped being maintained, I'd have to do something. It seems to me that you should all hope that V4 gets to where Namesys does not spend much time maintaining it. It means we have no bug reports. Stable branches, and development branches, and only bug fixes get added to the stable branch, it is an old paradigm, and broadly speaking it is still the right paradigm. Guys, Horst is trolling.He has never used our code, and yet. - 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/
Re: reiser4 vs politics: linux misses out again
David Lang wrote: > > remember that Hans is on record (over a year ago) arguing that R3 > should not be fixed becouse R4 was replacing it. No, I said and say that V3 should not have features added to it, because features should not be added to a stable branch. Bug fixes are good. There are a few V3 bug fixes where the fix is so deep that it belongs in V4, all of the ones that I can think of at the moment are ones requiring disk format changes. Note that in V4, disk format changes are no longer deep fixes because of plugins. > > This type of thing is one of the reasons that you see arguments that > aren't 'purely code-related' becouse the kernel folks realize that > _they_ will have to maintain the code over time, Hans and company will > go on and develop R5 (R10, whatever) and consider R4 obsolete and stop > maintaining it. No, we will stop adding features to it at some point, only add bug fixes, and let it become stable enough for mission critical use. Of course, with plugins this becomes more complicated of a policy because smaller releases with more orthogonal features are easier and more tempting, and it becomes tempting to version and release plugins rather than the FS, so I am not sure exactly how this will play out yet. I think we will have an option to select experimental plugins individually. > > David Lang > - 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/
Re: reiser4 vs politics: linux misses out again
David Lang wrote: remember that Hans is on record (over a year ago) arguing that R3 should not be fixed becouse R4 was replacing it. No, I said and say that V3 should not have features added to it, because features should not be added to a stable branch. Bug fixes are good. There are a few V3 bug fixes where the fix is so deep that it belongs in V4, all of the ones that I can think of at the moment are ones requiring disk format changes. Note that in V4, disk format changes are no longer deep fixes because of plugins. This type of thing is one of the reasons that you see arguments that aren't 'purely code-related' becouse the kernel folks realize that _they_ will have to maintain the code over time, Hans and company will go on and develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining it. No, we will stop adding features to it at some point, only add bug fixes, and let it become stable enough for mission critical use. Of course, with plugins this becomes more complicated of a policy because smaller releases with more orthogonal features are easier and more tempting, and it becomes tempting to version and release plugins rather than the FS, so I am not sure exactly how this will play out yet. I think we will have an option to select experimental plugins individually. David Lang - 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/
Re: reiser4 plugins
Jonathan Briggs wrote: >On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote: > > >>Hubert Chan wrote: >> >> >>>And a question: is it feasible to store, for each inode, its parent(s), >>>instead of just the hard link count? >>> >>> >>> >>> >>Ooh, now that is an interesting old idea I haven't considered in 20 >>years makes fsck more robust too >> >> > >Hey, sounds like the idea I proposed a couple months ago of storing the >path names in each file, instead of in directories. Only better, since >each path component isn't text but a link instead. > >It still has the performance and locking problem of having to update >every child file when moving a directory tree to a new parent. On the >other hand, maybe the benefit is worth the cost. > > Oh no, don't store the whole path, store just the parent list. This will make fsck more robust in the event that the directory gets clobbered by hardware error. I don't think it affects the cost of detecting cycles though, I think it only makes fsck more robust. Hans - 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/
Re: reiser4 plugins
Horst von Brand wrote: >Hans Reiser <[EMAIL PROTECTED]> wrote: > >[...] > > > >>I think the exokernel approach by Frans is a very interesting approach. >>I wish I had the experience with it necessary to know if it was >>effective. I do NOT take the position that name resolution should be in >>the kernel. I DO take the position that it should be either in the >>kernel or out of the kernel, and should constitute one cohesive and >>coherent body of code. >> >> > >Right. > > > >>If someone talks Linus into trying the exokernel >>approach, >> >> > >Are you nuts?! Such radical experiments do /not/ belong in the kernel on >which millions of machines depend! > > Your response is a flame, and I will not respond to it. - 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/
Re: reiser4 plugins
Horst von Brand wrote: Hans Reiser [EMAIL PROTECTED] wrote: [...] I think the exokernel approach by Frans is a very interesting approach. I wish I had the experience with it necessary to know if it was effective. I do NOT take the position that name resolution should be in the kernel. I DO take the position that it should be either in the kernel or out of the kernel, and should constitute one cohesive and coherent body of code. Right. If someone talks Linus into trying the exokernel approach, Are you nuts?! Such radical experiments do /not/ belong in the kernel on which millions of machines depend! Your response is a flame, and I will not respond to it. - 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/
Re: reiser4 plugins
Jonathan Briggs wrote: On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote: Hubert Chan wrote: And a question: is it feasible to store, for each inode, its parent(s), instead of just the hard link count? Ooh, now that is an interesting old idea I haven't considered in 20 years makes fsck more robust too Hey, sounds like the idea I proposed a couple months ago of storing the path names in each file, instead of in directories. Only better, since each path component isn't text but a link instead. It still has the performance and locking problem of having to update every child file when moving a directory tree to a new parent. On the other hand, maybe the benefit is worth the cost. Oh no, don't store the whole path, store just the parent list. This will make fsck more robust in the event that the directory gets clobbered by hardware error. I don't think it affects the cost of detecting cycles though, I think it only makes fsck more robust. Hans - 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/
Re: reiser4 plugins
David Masover wrote: > And, once we start talking about applications, /meta will be more > readily supported (as in, some apps will go through a pathname and > stop when they get to a file, and then there's tar). On apps which > don't have direct support for /meta, you'd be navigating to the file > in question and then manually typing '...' into the dialog, so I don't > see why typing '...' at the end is better than typing '/meta' or > '/meta/vfs' at the beginning. Performance. If you type it at the end, and you already have done the lookup of the filename, then you can go from the file to one of its methods, instead of a complete new traversal of another tree under /meta > > That said, I'm still not entirely sure how we get /meta/vfs to work > other than adding a '...' sort of delimiter anyway. > >>> And a question: is it feasible to store, for each inode, its parent(s), >>> instead of just the hard link count? >>> >>> >> >> Ooh, now that is an interesting old idea I haven't considered in 20 >> years makes fsck more robust too > > > Doesn't it make directory operations slower, too? Not sure. It consumes space though. > > And, will it require a format change? > Yes, but we have plugins now, so. - 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/
Re: reiser4 plugins
Nate Diller wrote: > > > as an example, if a program were to store some things it needs access > to in its executable's attributes, it should have the option of > keeping a hard reference to something, so that it can't be deleted out > from underneath. this enables sane sharing of resources without > ownership tracking problems (see windows DLL hell for details). the > attribute space should be indistinguishable from the rest of the > namespace, and should be able to link (soft or hard) anywhere in the > FS. anything less is too much work for too little reward. > You already have a problem with hardlinks not crossing mount points, but I understand your point. If we can write code for solving the cycle problem cleanly, it would be best. - 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/
Re: reiser4 plugins
David Masover wrote: > So, will the format change happen at mount time? Will it need a > special mount flag? Will I need to use debugfs or some other offline > tool? First we make sure we have the right answer. Have we solved the cycle problem? Can we run out of memory as Horst/Nikita suggest? - 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/
Re: reiser4 plugins
Martin Waitz wrote: >hoi :) > >On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote: > > >>You could do filesystems in userspace too and just use the kernel's >>block layer. >> >> > >but you can't do that in an library, you have to use a filesystem >server in order to get access control. >But you can build a library that handles uniform access to >files and directories. > >Don't get me wrong, I'm all for a uniform interface for files and >metadata, but I don't think that it has to be in the kernel. >Gnome and KDE already have their own userspace VFS, something >like that should be used. > >One has to distinguish between the low-level filesystem and >the storage system which is presented to the user. > > > Yes, but to do what you advocate properly, the existing semantics currently in the kernel should be moved out of it into user space. I think the exokernel approach by Frans is a very interesting approach. I wish I had the experience with it necessary to know if it was effective. I do NOT take the position that name resolution should be in the kernel. I DO take the position that it should be either in the kernel or out of the kernel, and should constitute one cohesive and coherent body of code. If someone talks Linus into trying the exokernel approach, I will be happy to educate myself to where I have an opinion on whether that works. It is easy to see powerful advantages to the exokernel approach: I wish I understood the security model for it, and I wish I was sure that name resolution would not require too many context switches as one fetches each storage component required by a name resolution. Masover's words about HURD earlier in this thread were very well said. Context switching is expensive, and I find it easier to be sure my code will both perform well and be cohesive if it is all done in the kernel by one body of code. - 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/
Re: reiser4 plugins
Hubert Chan wrote: >On Tue, 05 Jul 2005 20:50:08 -0400 EDT, "Alexander G. M. Smith" <[EMAIL >PROTECTED]> said: > > > >>That sounds equivalent to no hard links (other than the usual parent >>directory one). If there's any directory with two links to it, then >>there will be a cycle somewhere! >> >> > >What we want is no directed cycles. That is A is the parent of B is the >parent of C is the parent of A. We don't care about A is the parent of >B is the parent of C; A is the parent of B is the parent of C. > >OK, here's a random idea that just popped into my head, and to which >I've given little thought (read: none whatsoever), and may be the >stupidest idea ever proposed on LKML, but thought I would just toss it >out to see if it could stimulate someone to come up with something >better (read: sane): Conceptually, foo/ is just a symlink to >/meta/[filesystem]/[inode of foo]. > > Except that we want the metafiles to go away when the base file goes away. >And a question: is it feasible to store, for each inode, its parent(s), >instead of just the hard link count? > > Ooh, now that is an interesting old idea I haven't considered in 20 years makes fsck more robust too - 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/
Re: reiser4 plugins
Hubert Chan wrote: On Tue, 05 Jul 2005 20:50:08 -0400 EDT, Alexander G. M. Smith [EMAIL PROTECTED] said: That sounds equivalent to no hard links (other than the usual parent directory one). If there's any directory with two links to it, then there will be a cycle somewhere! What we want is no directed cycles. That is A is the parent of B is the parent of C is the parent of A. We don't care about A is the parent of B is the parent of C; A is the parent of B is the parent of C. OK, here's a random idea that just popped into my head, and to which I've given little thought (read: none whatsoever), and may be the stupidest idea ever proposed on LKML, but thought I would just toss it out to see if it could stimulate someone to come up with something better (read: sane): Conceptually, foo/ is just a symlink to /meta/[filesystem]/[inode of foo]. Except that we want the metafiles to go away when the base file goes away. And a question: is it feasible to store, for each inode, its parent(s), instead of just the hard link count? Ooh, now that is an interesting old idea I haven't considered in 20 years makes fsck more robust too - 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/
Re: reiser4 plugins
Martin Waitz wrote: hoi :) On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote: You could do filesystems in userspace too and just use the kernel's block layer. but you can't do that in an library, you have to use a filesystem server in order to get access control. But you can build a library that handles uniform access to files and directories. Don't get me wrong, I'm all for a uniform interface for files and metadata, but I don't think that it has to be in the kernel. Gnome and KDE already have their own userspace VFS, something like that should be used. One has to distinguish between the low-level filesystem and the storage system which is presented to the user. Yes, but to do what you advocate properly, the existing semantics currently in the kernel should be moved out of it into user space. I think the exokernel approach by Frans is a very interesting approach. I wish I had the experience with it necessary to know if it was effective. I do NOT take the position that name resolution should be in the kernel. I DO take the position that it should be either in the kernel or out of the kernel, and should constitute one cohesive and coherent body of code. If someone talks Linus into trying the exokernel approach, I will be happy to educate myself to where I have an opinion on whether that works. It is easy to see powerful advantages to the exokernel approach: I wish I understood the security model for it, and I wish I was sure that name resolution would not require too many context switches as one fetches each storage component required by a name resolution. Masover's words about HURD earlier in this thread were very well said. Context switching is expensive, and I find it easier to be sure my code will both perform well and be cohesive if it is all done in the kernel by one body of code. - 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/
Re: reiser4 plugins
David Masover wrote: So, will the format change happen at mount time? Will it need a special mount flag? Will I need to use debugfs or some other offline tool? First we make sure we have the right answer. Have we solved the cycle problem? Can we run out of memory as Horst/Nikita suggest? - 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/
Re: reiser4 plugins
Nate Diller wrote: as an example, if a program were to store some things it needs access to in its executable's attributes, it should have the option of keeping a hard reference to something, so that it can't be deleted out from underneath. this enables sane sharing of resources without ownership tracking problems (see windows DLL hell for details). the attribute space should be indistinguishable from the rest of the namespace, and should be able to link (soft or hard) anywhere in the FS. anything less is too much work for too little reward. You already have a problem with hardlinks not crossing mount points, but I understand your point. If we can write code for solving the cycle problem cleanly, it would be best. - 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/
Re: reiser4 plugins
David Masover wrote: And, once we start talking about applications, /meta will be more readily supported (as in, some apps will go through a pathname and stop when they get to a file, and then there's tar). On apps which don't have direct support for /meta, you'd be navigating to the file in question and then manually typing '...' into the dialog, so I don't see why typing '...' at the end is better than typing '/meta' or '/meta/vfs' at the beginning. Performance. If you type it at the end, and you already have done the lookup of the filename, then you can go from the file to one of its methods, instead of a complete new traversal of another tree under /meta That said, I'm still not entirely sure how we get /meta/vfs to work other than adding a '...' sort of delimiter anyway. And a question: is it feasible to store, for each inode, its parent(s), instead of just the hard link count? Ooh, now that is an interesting old idea I haven't considered in 20 years makes fsck more robust too Doesn't it make directory operations slower, too? Not sure. It consumes space though. And, will it require a format change? Yes, but we have plugins now, so. - 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/
Re: reiser4 plugins
Jeremy Maitin-Shepard wrote: >Okay, so you are suggesting that file-as-dir would provide the user >interface for enabling the encryption or compression. Alternatively, >though, an ioctl could be used to control compression and encryption. > > > Why is it that /proc does not use an ioctl? Use of metafiles could allow eliminating ioctl(), which most folks I know hate as an interface. Wouldn't it be cleaner if we could find out what ioctl()s are supported by a given file using ls filename//ioctl? Excerpt from the ioctl man page, which lacks a list of what features are implemented or how to find out. CONFORMING TO No single standard. Arguments, returns, and semantics of ioctl(2) vary according to the device driver in question (the call is used as a catch-all for operations that don't cleanly fit the Unix stream I/O model). See ioctl_list(2) for a list of many of the known ioctl calls. The ioctl function call appeared in Version 7 AT Unix. - 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/
Re: reiser4 plugins
I got it slightly wrong. One can have hardlinks to a directory without cycles provided that one does not have hardlinks from the children of that directory to any file not a child of that directory. (Mountpoints currently implement that restriction.) Question: can one implement that lesser restriction above with elegant code? Is the greater restriction below easier to code? (If no to the first and yes to the second is correct, then I can accept the greater restriction described below.) One can have hardlinks to directories without cycles provided that one does not allow any child of the directory to have a hardlink. Hans - 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/
Re: reiser4 plugins
David Masover wrote: >Now, can anyone think of a situation where we want user-created >hardlinks inside metadata? More importantly, what do we do about it? > > I think the equivalent of symlinks would be good enough to get by on for now for most linking of metafiles. Maybe some years from now somebody can fault me for saying this and write a patch to fix it to be better, at which point I will be happy to concede the point. So the basic principal here is, one can have hardlinks to directories without cycles provided that one does not allow any child of the directory to have a hardlink. The question is, how cleanly can that relaxed restriction be coded? Hans - 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/
Re: reiser4 plugins
David Masover wrote: >Hans Reiser wrote: > > >>Hubert Chan wrote: >> >> >> >> >>>On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said: >>> >>> >>> >>> >>> >>> >>>>Hubert Chan wrote: >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>>The main thing blocking file-as-dir is that there are some >>>>>locking(IIRC?) issues. And, of course, some people wouldn't want it >>>>>to be merged into the mainline kernel. (Of course, the latter >>>>>doesn't prevent Namesys from maintaining their own patches for people >>>>>to play around with.) >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>>>What's the locking issue? I think that was more about transactions... >>>> >>>> >>>> >>>> >>>It was whatever was Al Viro's (technical) complaint about file-as-dir. >>>I don't remember exactly what it was. The technical people know what it >>>is (and the Namesys guys are probably working on it), and the exact >>>issue doesn't concern us non-technical people that much, so I don't feel >>>like looking it up. But if you want to, just look for Al Viro's message >>>in this thread. >>> >>> >>> >>> >>> >>Cycle detection when hard links to directories are allowed. There is a >>debate over whether cycle detection is feasible that can only be >>resolved by working code or a formal proof that it is not >>computationally feasible. >> >> > >Ah. But then, one solution was to avoid the issue at all, and have the >directory inside a file act as a mountpoint. After all, mount --bind >doesn't cause problems... > > Can you explain this idea at greater length? >Hey! This sounds like metafs (/meta) already! I wonder if we can do >file-as-dir in /meta, and just not support user-created hardlinks there? > (other than creating brand-new files, of course...) > > > > - 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/
Re: reiser4 plugins
Hubert Chan wrote: >On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said: > > > >>Hubert Chan wrote: >> >> > > > >>>The main thing blocking file-as-dir is that there are some >>>locking(IIRC?) issues. And, of course, some people wouldn't want it >>>to be merged into the mainline kernel. (Of course, the latter >>>doesn't prevent Namesys from maintaining their own patches for people >>>to play around with.) >>> >>> > > > >>What's the locking issue? I think that was more about transactions... >> >> > >It was whatever was Al Viro's (technical) complaint about file-as-dir. >I don't remember exactly what it was. The technical people know what it >is (and the Namesys guys are probably working on it), and the exact >issue doesn't concern us non-technical people that much, so I don't feel >like looking it up. But if you want to, just look for Al Viro's message >in this thread. > > > Cycle detection when hard links to directories are allowed. There is a debate over whether cycle detection is feasible that can only be resolved by working code or a formal proof that it is not computationally feasible. Hans - 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/
Re: reiser4 plugins
Hubert Chan wrote: On Fri, 01 Jul 2005 03:06:19 -0500, David Masover [EMAIL PROTECTED] said: Hubert Chan wrote: The main thing blocking file-as-dir is that there are some locking(IIRC?) issues. And, of course, some people wouldn't want it to be merged into the mainline kernel. (Of course, the latter doesn't prevent Namesys from maintaining their own patches for people to play around with.) What's the locking issue? I think that was more about transactions... It was whatever was Al Viro's (technical) complaint about file-as-dir. I don't remember exactly what it was. The technical people know what it is (and the Namesys guys are probably working on it), and the exact issue doesn't concern us non-technical people that much, so I don't feel like looking it up. But if you want to, just look for Al Viro's message in this thread. Cycle detection when hard links to directories are allowed. There is a debate over whether cycle detection is feasible that can only be resolved by working code or a formal proof that it is not computationally feasible. Hans - 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/
Re: reiser4 plugins
David Masover wrote: Hans Reiser wrote: Hubert Chan wrote: On Fri, 01 Jul 2005 03:06:19 -0500, David Masover [EMAIL PROTECTED] said: Hubert Chan wrote: The main thing blocking file-as-dir is that there are some locking(IIRC?) issues. And, of course, some people wouldn't want it to be merged into the mainline kernel. (Of course, the latter doesn't prevent Namesys from maintaining their own patches for people to play around with.) What's the locking issue? I think that was more about transactions... It was whatever was Al Viro's (technical) complaint about file-as-dir. I don't remember exactly what it was. The technical people know what it is (and the Namesys guys are probably working on it), and the exact issue doesn't concern us non-technical people that much, so I don't feel like looking it up. But if you want to, just look for Al Viro's message in this thread. Cycle detection when hard links to directories are allowed. There is a debate over whether cycle detection is feasible that can only be resolved by working code or a formal proof that it is not computationally feasible. Ah. But then, one solution was to avoid the issue at all, and have the directory inside a file act as a mountpoint. After all, mount --bind doesn't cause problems... Can you explain this idea at greater length? Hey! This sounds like metafs (/meta) already! I wonder if we can do file-as-dir in /meta, and just not support user-created hardlinks there? (other than creating brand-new files, of course...) - 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/
Re: reiser4 plugins
David Masover wrote: Now, can anyone think of a situation where we want user-created hardlinks inside metadata? More importantly, what do we do about it? I think the equivalent of symlinks would be good enough to get by on for now for most linking of metafiles. Maybe some years from now somebody can fault me for saying this and write a patch to fix it to be better, at which point I will be happy to concede the point. So the basic principal here is, one can have hardlinks to directories without cycles provided that one does not allow any child of the directory to have a hardlink. The question is, how cleanly can that relaxed restriction be coded? Hans - 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/
Re: reiser4 plugins
I got it slightly wrong. One can have hardlinks to a directory without cycles provided that one does not have hardlinks from the children of that directory to any file not a child of that directory. (Mountpoints currently implement that restriction.) Question: can one implement that lesser restriction above with elegant code? Is the greater restriction below easier to code? (If no to the first and yes to the second is correct, then I can accept the greater restriction described below.) One can have hardlinks to directories without cycles provided that one does not allow any child of the directory to have a hardlink. Hans - 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/
Re: reiser4 plugins
Jeremy Maitin-Shepard wrote: Okay, so you are suggesting that file-as-dir would provide the user interface for enabling the encryption or compression. Alternatively, though, an ioctl could be used to control compression and encryption. Why is it that /proc does not use an ioctl? Use of metafiles could allow eliminating ioctl(), which most folks I know hate as an interface. Wouldn't it be cleaner if we could find out what ioctl()s are supported by a given file using ls filename//ioctl? Excerpt from the ioctl man page, which lacks a list of what features are implemented or how to find out. CONFORMING TO No single standard. Arguments, returns, and semantics of ioctl(2) vary according to the device driver in question (the call is used as a catch-all for operations that don't cleanly fit the Unix stream I/O model). See ioctl_list(2) for a list of many of the known ioctl calls. The ioctl function call appeared in Version 7 ATT Unix. - 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/
Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
Adrian Bunk wrote: >On Tue, Mar 22, 2005 at 09:50:14AM -0800, Hans Reiser wrote: > > > >>All of my technical arguments on this topic were nicely obliterated by >>Andrew. The only real reason remaining (that I know of) is that I want >>to first eliminate all things which are a barrier to inclusion before >>dealing with this because it requires man hours to fix it. If you want >>to send us a cleanup patch that fixes it, I would be grateful for your >>time donatioin. >> >> > >My plan is to send a patch to Andrew that unconditionally enables >4KSTACKS for shaking out the last bugs before possibly removing >8 kB stacks completely. > >I don't know whether this is barrier to inclusion, but this will make >reiser4 unavailable on i386... > > > >>Hans >> >> > >cu >Adrian > > > Sigh. Could you wait a few weeks until we have done all the other things, and then I can have Vladimir work with you on it? - 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/
Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
Adrian Bunk wrote: >Hi Hans, > >REISER4_FS is the only option with a dependency on !4KSTACKS which is >bad since 8 kB stacks on i386 won't stay forever. > >Could fix the problems with 4 kB stacks? > >Running > > make checkstacks | grep reiser4 > >inside te kernel sources after compiling gives you hints where problems >might come from. > > >TIA >Adrian > > > All of my technical arguments on this topic were nicely obliterated by Andrew. The only real reason remaining (that I know of) is that I want to first eliminate all things which are a barrier to inclusion before dealing with this because it requires man hours to fix it. If you want to send us a cleanup patch that fixes it, I would be grateful for your time donatioin. Hans - 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/
Re: 2.6.12-rc1-mm1: REISER4_FS - 4KSTACKS
Adrian Bunk wrote: Hi Hans, REISER4_FS is the only option with a dependency on !4KSTACKS which is bad since 8 kB stacks on i386 won't stay forever. Could fix the problems with 4 kB stacks? Running make checkstacks | grep reiser4 inside te kernel sources after compiling gives you hints where problems might come from. TIA Adrian All of my technical arguments on this topic were nicely obliterated by Andrew. The only real reason remaining (that I know of) is that I want to first eliminate all things which are a barrier to inclusion before dealing with this because it requires man hours to fix it. If you want to send us a cleanup patch that fixes it, I would be grateful for your time donatioin. Hans - 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/
Re: 2.6.12-rc1-mm1: REISER4_FS - 4KSTACKS
Adrian Bunk wrote: On Tue, Mar 22, 2005 at 09:50:14AM -0800, Hans Reiser wrote: All of my technical arguments on this topic were nicely obliterated by Andrew. The only real reason remaining (that I know of) is that I want to first eliminate all things which are a barrier to inclusion before dealing with this because it requires man hours to fix it. If you want to send us a cleanup patch that fixes it, I would be grateful for your time donatioin. My plan is to send a patch to Andrew that unconditionally enables 4KSTACKS for shaking out the last bugs before possibly removing 8 kB stacks completely. I don't know whether this is barrier to inclusion, but this will make reiser4 unavailable on i386... Hans cu Adrian Sigh. Could you wait a few weeks until we have done all the other things, and then I can have Vladimir work with you on it? - 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/
Re: [2.6.11-rc5-mm1 patch] fs/reiser4/: possible cleanups
vs, please review and respond in 2 weeks. (vs is sick at the moment)
Thanks Adrian,
Hans
Adrian Bunk wrote:
>This patch contains possible cleanups including the following:
>- make needlessly global code static
>- plugin/compress/minilzo.c: many cleanups
>- remove or #if 0 the following unused global functions:
> - context.c: check_contexts
> - flush.c: jnode_tostring
> - flush.c: znode_tostring
> - flush.c: pos_tostring
> - flush_queue.c: fq_by_jnode
> - inode.c: get_reiser4_inode_by_key
> - lock.c: lock_mode
> - plugin/cryptcompress.c: set_nrpages_by_inode
> - file.c: readpages_unix_file
> - plugin/item/ctail.c: ctail_make_unprepped_cluster
> - plugin/item/extent_item_ops.c: show_extent
> - plugin/item/tail.c: show_tail
> - tree_walk.c: tree_walk
>
>Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
>---
>
>This patch was already sent on:
>- 3 Mar 2005
>
> fs/reiser4/block_alloc.c |2
> fs/reiser4/cluster.h |3
> fs/reiser4/context.c |2
> fs/reiser4/debug.c | 13 +
> fs/reiser4/debug.h |2
> fs/reiser4/flush.c |6
> fs/reiser4/flush.h |4
> fs/reiser4/flush_queue.c |7
> fs/reiser4/inode.c |6
> fs/reiser4/inode.h |3
> fs/reiser4/jnode.c |8 -
> fs/reiser4/jnode.h |2
> fs/reiser4/lock.c|2
> fs/reiser4/lock.h|1
> fs/reiser4/page_cache.c |2
> fs/reiser4/plugin/compress/lzoconf.h | 23 --
> fs/reiser4/plugin/compress/minilzo.c | 179 +--
> fs/reiser4/plugin/cryptcompress.c| 15 -
> fs/reiser4/plugin/file/file.c| 14 -
> fs/reiser4/plugin/file/funcs.h |2
> fs/reiser4/plugin/item/ctail.c |4
> fs/reiser4/plugin/item/ctail.h |1
> fs/reiser4/plugin/item/extent.h |1
> fs/reiser4/plugin/item/extent_item_ops.c |2
> fs/reiser4/plugin/item/tail.c|5
> fs/reiser4/plugin/item/tail.h|1
> fs/reiser4/plugin/object.c |2
> fs/reiser4/plugin/object.h |1
> fs/reiser4/tree_walk.c |4
> fs/reiser4/txnmgr.h |1
> fs/reiser4/vfs_ops.c | 14 -
> fs/reiser4/wander.c |2
> fs/reiser4/znode.c |4
> 33 files changed, 66 insertions(+), 272 deletions(-)
>
>--- linux-2.6.11-rc5-mm1-full/fs/reiser4/block_alloc.c.old 2005-03-01
>21:18:07.0 +0100
>+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/block_alloc.c 2005-03-01
>21:18:14.0 +0100
>@@ -932,7 +932,7 @@
> #if REISER4_DEBUG
>
> /* check "allocated" state of given block range */
>-void
>+static void
> reiser4_check_blocks(const reiser4_block_nr * start, const reiser4_block_nr *
> len, int desired)
> {
> sa_check_blocks(start, len, desired);
>--- linux-2.6.11-rc5-mm1-full/fs/reiser4/context.c.old 2005-03-01
>21:18:31.0 +0100
>+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/context.c 2005-03-01
>21:19:08.0 +0100
>@@ -47,6 +47,7 @@
> /* lock protecting access to active_contexts. */
> spinlock_t active_contexts_lock;
>
>+#if 0
> void
> check_contexts(void)
> {
>@@ -58,6 +59,7 @@
> }
> spin_unlock(_contexts_lock);
> }
>+#endif /* 0 */
>
> #endif /* REISER4_DEBUG */
>
>--- linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.h.old 2005-03-01
>21:19:25.0 +0100
>+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.h 2005-03-01
>21:19:31.0 +0100
>@@ -176,8 +176,6 @@
> REISER4_CHECK_NODE = 0x0008
> } reiser4_debug_flags;
>
>-extern int reiser4_is_debugged(struct super_block *super, __u32 flag);
>-
> extern int is_in_reiser4_context(void);
>
> /*
>--- linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.c.old 2005-03-01
>21:19:38.0 +0100
>+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.c 2005-03-01
>22:54:38.0 +0100
>@@ -61,6 +61,11 @@
> */
> static spinlock_t panic_guard = SPIN_LOCK_UNLOCKED;
>
>+#if REISER4_DEBUG
>+static int
>+reiser4_is_debugged(struct super_block *super, __u32 flag);
>+#endif
>+
> /* Your best friend. Call it on each occasion. This is called by
> fs/reiser4/debug.h:reiser4_panic(). */
> reiser4_internal void
>@@ -303,19 +308,19 @@
> return result;
> }
>
>-/* REISER4_DEBUG */
>-#endif
>-
> /*
> * check that some bits specified by @flags are set in ->debug_flags of the
> * super block.
> */
>-reiser4_internal int
>+static int
> reiser4_is_debugged(struct super_block *super, __u32 flag)
> {
> return get_super_private(super)->debug_flags & flag;
> }
>
>+/* REISER4_DEBUG */
>+#endif
>+
> /* allocate memory. This calls kmalloc(), performs some additional checks, and
>keeps track
Re: [2.6.11-rc5-mm1 patch] fs/reiser4/: possible cleanups
vs, please review and respond in 2 weeks. (vs is sick at the moment)
Thanks Adrian,
Hans
Adrian Bunk wrote:
This patch contains possible cleanups including the following:
- make needlessly global code static
- plugin/compress/minilzo.c: many cleanups
- remove or #if 0 the following unused global functions:
- context.c: check_contexts
- flush.c: jnode_tostring
- flush.c: znode_tostring
- flush.c: pos_tostring
- flush_queue.c: fq_by_jnode
- inode.c: get_reiser4_inode_by_key
- lock.c: lock_mode
- plugin/cryptcompress.c: set_nrpages_by_inode
- file.c: readpages_unix_file
- plugin/item/ctail.c: ctail_make_unprepped_cluster
- plugin/item/extent_item_ops.c: show_extent
- plugin/item/tail.c: show_tail
- tree_walk.c: tree_walk
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 3 Mar 2005
fs/reiser4/block_alloc.c |2
fs/reiser4/cluster.h |3
fs/reiser4/context.c |2
fs/reiser4/debug.c | 13 +
fs/reiser4/debug.h |2
fs/reiser4/flush.c |6
fs/reiser4/flush.h |4
fs/reiser4/flush_queue.c |7
fs/reiser4/inode.c |6
fs/reiser4/inode.h |3
fs/reiser4/jnode.c |8 -
fs/reiser4/jnode.h |2
fs/reiser4/lock.c|2
fs/reiser4/lock.h|1
fs/reiser4/page_cache.c |2
fs/reiser4/plugin/compress/lzoconf.h | 23 --
fs/reiser4/plugin/compress/minilzo.c | 179 +--
fs/reiser4/plugin/cryptcompress.c| 15 -
fs/reiser4/plugin/file/file.c| 14 -
fs/reiser4/plugin/file/funcs.h |2
fs/reiser4/plugin/item/ctail.c |4
fs/reiser4/plugin/item/ctail.h |1
fs/reiser4/plugin/item/extent.h |1
fs/reiser4/plugin/item/extent_item_ops.c |2
fs/reiser4/plugin/item/tail.c|5
fs/reiser4/plugin/item/tail.h|1
fs/reiser4/plugin/object.c |2
fs/reiser4/plugin/object.h |1
fs/reiser4/tree_walk.c |4
fs/reiser4/txnmgr.h |1
fs/reiser4/vfs_ops.c | 14 -
fs/reiser4/wander.c |2
fs/reiser4/znode.c |4
33 files changed, 66 insertions(+), 272 deletions(-)
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/block_alloc.c.old 2005-03-01
21:18:07.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/block_alloc.c 2005-03-01
21:18:14.0 +0100
@@ -932,7 +932,7 @@
#if REISER4_DEBUG
/* check allocated state of given block range */
-void
+static void
reiser4_check_blocks(const reiser4_block_nr * start, const reiser4_block_nr *
len, int desired)
{
sa_check_blocks(start, len, desired);
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/context.c.old 2005-03-01
21:18:31.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/context.c 2005-03-01
21:19:08.0 +0100
@@ -47,6 +47,7 @@
/* lock protecting access to active_contexts. */
spinlock_t active_contexts_lock;
+#if 0
void
check_contexts(void)
{
@@ -58,6 +59,7 @@
}
spin_unlock(active_contexts_lock);
}
+#endif /* 0 */
#endif /* REISER4_DEBUG */
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.h.old 2005-03-01
21:19:25.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.h 2005-03-01
21:19:31.0 +0100
@@ -176,8 +176,6 @@
REISER4_CHECK_NODE = 0x0008
} reiser4_debug_flags;
-extern int reiser4_is_debugged(struct super_block *super, __u32 flag);
-
extern int is_in_reiser4_context(void);
/*
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.c.old 2005-03-01
21:19:38.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.c 2005-03-01
22:54:38.0 +0100
@@ -61,6 +61,11 @@
*/
static spinlock_t panic_guard = SPIN_LOCK_UNLOCKED;
+#if REISER4_DEBUG
+static int
+reiser4_is_debugged(struct super_block *super, __u32 flag);
+#endif
+
/* Your best friend. Call it on each occasion. This is called by
fs/reiser4/debug.h:reiser4_panic(). */
reiser4_internal void
@@ -303,19 +308,19 @@
return result;
}
-/* REISER4_DEBUG */
-#endif
-
/*
* check that some bits specified by @flags are set in -debug_flags of the
* super block.
*/
-reiser4_internal int
+static int
reiser4_is_debugged(struct super_block *super, __u32 flag)
{
return get_super_private(super)-debug_flags flag;
}
+/* REISER4_DEBUG */
+#endif
+
/* allocate memory. This calls kmalloc(), performs some additional checks, and
keeps track of how many memory was allocated on behalf of current super
block. */
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/flush.h.old 2005-03-01
Re: 2.6.11-rc3-mm1 bad scheduling while atomic + lockup
Maciej Soltysiak wrote:
)
Feb 6 17:07:47 dns kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Feb 6 17:07:47 dns kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
this means bad hard drive, or at least a bad sector on it.
-
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/
Re: 2.6.11-rc3-mm1 bad scheduling while atomic + lockup
Maciej Soltysiak wrote:
)
Feb 6 17:07:47 dns kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Feb 6 17:07:47 dns kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
this means bad hard drive, or at least a bad sector on it.
-
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/
[reiserfs-list] Re: [reiserfs-dev] Re: Note describing poor dcache utilization under high memory pressure
Oliver Xymoron wrote: > >Can we get you to agree that basically all subpage objects are immovable? > No. Certainly not in the general case, and I think Josh found ways to handle the dcache case. If we can simply free the old objects, we don't actually have to move the hot ones, as he points out. > >And as a consequence that garbage collecting at subpage levels doesn't >guarantee freeing up any pages that can then be given up to other >subsystems in response to VM pressure? The GC must think in terms of pages >to actually make progress. > >One of the design goals of slab by the way is that objects of a similar >type will end up having similar lifetimes, avoiding some of the worst >cases of sub-page allocations. > - 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/
[reiserfs-list] Re: [reiserfs-dev] Re: Note describing poor dcache utilization under high memory pressure
Oliver Xymoron wrote: Can we get you to agree that basically all subpage objects are immovable? No. Certainly not in the general case, and I think Josh found ways to handle the dcache case. If we can simply free the old objects, we don't actually have to move the hot ones, as he points out. And as a consequence that garbage collecting at subpage levels doesn't guarantee freeing up any pages that can then be given up to other subsystems in response to VM pressure? The GC must think in terms of pages to actually make progress. One of the design goals of slab by the way is that objects of a similar type will end up having similar lifetimes, avoiding some of the worst cases of sub-page allocations. - 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/
Re: NFS Client patch
Trond Myklebust wrote: > > >>>>> " " == Hans Reiser <[EMAIL PROTECTED]> writes: > > > The current code does rely on hidden knowledge of the filesytem > > on the server, and refuses to operate with any FS that does not > > describe a position in a directory as an offset or hash that > > fits into 32 or 64 bits. > > I'm not saying that ReiserFS is wrong to question the correctness of > this. I'm just saying that NFSv2 and v3 are fixed protocols, and that > it's too late to do anything about them. I read Chris mail as a > suggestion of creating yet another NQNFS, and this would IMHO be a > mistake. Better to concentrate on NFSv4 which is meant to be > extendible. > > > But be calm, I am not planning on fixing this myself anytime in > > the next year, we have an ugly and hideous hack deployed in > > ReiserFS that works, for now I am just saying the folks who > > designed NFS did a bad job and resolutely continue doing a bad > > job, and if someone wanted to fix it, they could fix cookies to > > use filenames instead of byte offsets for those filesytems able > > to better use filenames than byte offsets to describe a > > position within a directory, and for those clients and servers > > who are both smart enough to understand filenames instead of > > cookies (able to understand the cookie monster protocol). > > This is something which I believe you raised in the NFSv4 group, and > which could indeed be a candidate for an NFSv4 extension. After all, > this is in essence a recognition of the method most NFS clients > implement for recovering from an EBADCOOKIE error. Why was the idea > dropped? Lack of desire to do anything, near as I could tell. > > (Note: As I said, under Linux we're currently hampered when > considering the above alternatives by the fact that glibc requires the > ability to lseek() on directories. This is a bug that they could > easily fix, and it affects not only your suggestion, but also all the > other suggestions in which one implements non-permanent cookies) I would be quite happy if you (or anyone) could fix it, sometime in the next 3 years. > > Cheers, >Trond - 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/
Re: NFS Client patch
Trond Myklebust wrote: == Hans Reiser [EMAIL PROTECTED] writes: The current code does rely on hidden knowledge of the filesytem on the server, and refuses to operate with any FS that does not describe a position in a directory as an offset or hash that fits into 32 or 64 bits. I'm not saying that ReiserFS is wrong to question the correctness of this. I'm just saying that NFSv2 and v3 are fixed protocols, and that it's too late to do anything about them. I read Chris mail as a suggestion of creating yet another NQNFS, and this would IMHO be a mistake. Better to concentrate on NFSv4 which is meant to be extendible. But be calm, I am not planning on fixing this myself anytime in the next year, we have an ugly and hideous hack deployed in ReiserFS that works, for now I am just saying the folks who designed NFS did a bad job and resolutely continue doing a bad job, and if someone wanted to fix it, they could fix cookies to use filenames instead of byte offsets for those filesytems able to better use filenames than byte offsets to describe a position within a directory, and for those clients and servers who are both smart enough to understand filenames instead of cookies (able to understand the cookie monster protocol). This is something which I believe you raised in the NFSv4 group, and which could indeed be a candidate for an NFSv4 extension. After all, this is in essence a recognition of the method most NFS clients implement for recovering from an EBADCOOKIE error. Why was the idea dropped? Lack of desire to do anything, near as I could tell. (Note: As I said, under Linux we're currently hampered when considering the above alternatives by the fact that glibc requires the ability to lseek() on directories. This is a bug that they could easily fix, and it affects not only your suggestion, but also all the other suggestions in which one implements non-permanent cookies) I would be quite happy if you (or anyone) could fix it, sometime in the next 3 years. Cheers, Trond - 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/
Re: NFS Client patch
Trond Myklebust wrote: > > > " " == Chris Mason <[EMAIL PROTECTED]> writes: > > > Well, returning the last filename won't do much for filesystems > > that don't have any directory indexes, but that's besides the > > point. Could nfsv4 be better than it is? probably. Can we > > change older NFS protocols to have a linux specific hack that > > makes them more filesystem (or at least reiserfs) friendly? > > probably. > > NFSv2 and v3 have a fixed format for readdir calls. There's bugger all > you can do to change this without making the resulting protocol > incompatible with NFS. > > If you don't want Reiserfs to be NFS compatible, then fine, but I > personally don't want to see hacks to the NFS v2/v3 code that rely on > 'hidden knowledge' of the filesystem on the server. > > Cheers, > Trond > - > 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/ The current code does rely on hidden knowledge of the filesytem on the server, and refuses to operate with any FS that does not describe a position in a directory as an offset or hash that fits into 32 or 64 bits. But be calm, I am not planning on fixing this myself anytime in the next year, we have an ugly and hideous hack deployed in ReiserFS that works, for now I am just saying the folks who designed NFS did a bad job and resolutely continue doing a bad job, and if someone wanted to fix it, they could fix cookies to use filenames instead of byte offsets for those filesytems able to better use filenames than byte offsets to describe a position within a directory, and for those clients and servers who are both smart enough to understand filenames instead of cookies (able to understand the cookie monster protocol). Hans - 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/
Re: NFS Client patch
Trond Myklebust wrote: == Chris Mason [EMAIL PROTECTED] writes: Well, returning the last filename won't do much for filesystems that don't have any directory indexes, but that's besides the point. Could nfsv4 be better than it is? probably. Can we change older NFS protocols to have a linux specific hack that makes them more filesystem (or at least reiserfs) friendly? probably. NFSv2 and v3 have a fixed format for readdir calls. There's bugger all you can do to change this without making the resulting protocol incompatible with NFS. If you don't want Reiserfs to be NFS compatible, then fine, but I personally don't want to see hacks to the NFS v2/v3 code that rely on 'hidden knowledge' of the filesystem on the server. Cheers, Trond - 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/ The current code does rely on hidden knowledge of the filesytem on the server, and refuses to operate with any FS that does not describe a position in a directory as an offset or hash that fits into 32 or 64 bits. But be calm, I am not planning on fixing this myself anytime in the next year, we have an ugly and hideous hack deployed in ReiserFS that works, for now I am just saying the folks who designed NFS did a bad job and resolutely continue doing a bad job, and if someone wanted to fix it, they could fix cookies to use filenames instead of byte offsets for those filesytems able to better use filenames than byte offsets to describe a position within a directory, and for those clients and servers who are both smart enough to understand filenames instead of cookies (able to understand the cookie monster protocol). Hans - 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/
Re: Security hooks, "standard linux security" & embedded use
Hi Linda, This seems very much in line with what Reiser4 is doing for DARPA, and what SE Linux is doing for the NSA. Or at least what Linus told the SE Linux folks he would like them to write.:-) I am quite supportive of what you advocate generally, and I look forward to cooperating with you in the details. May I suggest we contact the SE Linux folks, and each of our teams establish a point-of-contact to work on developing the details of what needs to be done? We call your security hooks "security plugins" or "secplugs" in Reiser4, mostly to identify that they are a component of the Reiser4 "plugin" approach to extensibility. Reiser4 is getting underway this month. We are willing to adapt our terminology and coding to be be consistent with yours. We don't really have a need to be the leaders in this area. We just need to get the job done, and to ensure that nothing that is done crimps our ability to accomplish our objectives. Our project objectives are somewhat describable as "make it easy for folks like the NSA and the DoD to add new security features to Reiser4 by building the infrastructure for them." We will ship one implementation on top of that infrastructure that will implement ACLs, but we are more interested in enabling others than in doing ourselves. If the NSA or SGI wants to lead us a bit on this, that is fine with us. Our main insistence is going to be that the hooks should be very general, but I suspect you and the NSA also want that. We also need to have coding completed in ~8 months, so that it can all be debugged and stable and sent to Linus by Sep. 30th of next year. Do you have a list of all the hooks, etc., yet? Do you have anything like a general architecture for, given some vfs operation, and given some pluginid indicating object type, and given some secplugid (e.g. it might be the id of a secplug implementing an ACL), have the plugin check that the operation is allowable by calling the secplug (security hook) indicated by the secplugid? I think what is needed is an MxN matrix of security checks, where M is the number of vfs operations, and N is the number of secplugs. I am open to the idea that it should be MxNxO, where O is the number of security policies, though I don't plan to personally implement more than one security policy to ship with Reiser4 by default because I am pretty lazy. It won't surprise me if I end up shipping only one secplug with reiser4 initially (probably one implementing something embodying NT ACLs and unix permissions), and leave it to others to add the rest of them). I am quite supportive of your notion that some users have no need at all for security, and that they should be allowed a lightweight solution for their needs, though I will leave it to them to write that on top of the infrastructure I/we give them.:-) I envision the VFS operation invoking the plugin which invokes the secplug whose implementation varies with the choice of security policy compiled in. I don't honestly see the real usage critical need for dynamic loading of security policy modules, but I can yield on this if you see the need and code it since it probably isn't complex to code. I do like the idea of all of the code implementing a given security policy being isolated into its own single file/directory. Do you have any ideas on how to export to user space the ability to query what the permissions are, given that the permissions are being abstracted like this? I got your email, but I wasn't on the to: or cc: list. This confused me, so I invented a to: list that should reach all those likely to be interested in this. I am guessing this will be okay with you. Best, Hans LA Walsh wrote: > > Dear Linus et al., > > Sorry for the 'form' letter instead of individual names, but I > didn't want to have to send this out separately to every kernel developer > I know on LKML. > > I am asking for your input on the concept of moving the standard > Linux security checks into a "Linux Security Module". > > Discussion has come up on the Linux Security Module list > about whether or not the current linux security (file mode bits, uid > checking, etc.) should be modularized in the development of an LSM > framework implementation > > This would entail moving all of the standard checks out of the > kernel into a "standard security" module that, by default, would be > the security policy selected and compiled in during kernel configuration > and build. > > This seems to us (@sgi) to be the best solution to allow a > completely configurable security policy. This option allows > a policy creator complete flexibility in how or whether or not > existing security is called. For example, in POSIX 1e style Mandatory > Access Control, the information in the inode is also part of the > protected object. So if a process doesn't have access under MAC, the > DAC checks wouldn't even be executed since it
Re: Security hooks, standard linux security embedded use
Hi Linda, This seems very much in line with what Reiser4 is doing for DARPA, and what SE Linux is doing for the NSA. Or at least what Linus told the SE Linux folks he would like them to write.:-) I am quite supportive of what you advocate generally, and I look forward to cooperating with you in the details. May I suggest we contact the SE Linux folks, and each of our teams establish a point-of-contact to work on developing the details of what needs to be done? We call your security hooks security plugins or secplugs in Reiser4, mostly to identify that they are a component of the Reiser4 plugin approach to extensibility. Reiser4 is getting underway this month. We are willing to adapt our terminology and coding to be be consistent with yours. We don't really have a need to be the leaders in this area. We just need to get the job done, and to ensure that nothing that is done crimps our ability to accomplish our objectives. Our project objectives are somewhat describable as make it easy for folks like the NSA and the DoD to add new security features to Reiser4 by building the infrastructure for them. We will ship one implementation on top of that infrastructure that will implement ACLs, but we are more interested in enabling others than in doing ourselves. If the NSA or SGI wants to lead us a bit on this, that is fine with us. Our main insistence is going to be that the hooks should be very general, but I suspect you and the NSA also want that. We also need to have coding completed in ~8 months, so that it can all be debugged and stable and sent to Linus by Sep. 30th of next year. Do you have a list of all the hooks, etc., yet? Do you have anything like a general architecture for, given some vfs operation, and given some pluginid indicating object type, and given some secplugid (e.g. it might be the id of a secplug implementing an ACL), have the plugin check that the operation is allowable by calling the secplug (security hook) indicated by the secplugid? I think what is needed is an MxN matrix of security checks, where M is the number of vfs operations, and N is the number of secplugs. I am open to the idea that it should be MxNxO, where O is the number of security policies, though I don't plan to personally implement more than one security policy to ship with Reiser4 by default because I am pretty lazy. It won't surprise me if I end up shipping only one secplug with reiser4 initially (probably one implementing something embodying NT ACLs and unix permissions), and leave it to others to add the rest of them). I am quite supportive of your notion that some users have no need at all for security, and that they should be allowed a lightweight solution for their needs, though I will leave it to them to write that on top of the infrastructure I/we give them.:-) I envision the VFS operation invoking the plugin which invokes the secplug whose implementation varies with the choice of security policy compiled in. I don't honestly see the real usage critical need for dynamic loading of security policy modules, but I can yield on this if you see the need and code it since it probably isn't complex to code. I do like the idea of all of the code implementing a given security policy being isolated into its own single file/directory. Do you have any ideas on how to export to user space the ability to query what the permissions are, given that the permissions are being abstracted like this? I got your email, but I wasn't on the to: or cc: list. This confused me, so I invented a to: list that should reach all those likely to be interested in this. I am guessing this will be okay with you. Best, Hans LA Walsh wrote: Dear Linus et al., Sorry for the 'form' letter instead of individual names, but I didn't want to have to send this out separately to every kernel developer I know on LKML. I am asking for your input on the concept of moving the standard Linux security checks into a Linux Security Module. Discussion has come up on the Linux Security Module list about whether or not the current linux security (file mode bits, uid checking, etc.) should be modularized in the development of an LSM framework implementation This would entail moving all of the standard checks out of the kernel into a standard security module that, by default, would be the security policy selected and compiled in during kernel configuration and build. This seems to us (@sgi) to be the best solution to allow a completely configurable security policy. This option allows a policy creator complete flexibility in how or whether or not existing security is called. For example, in POSIX 1e style Mandatory Access Control, the information in the inode is also part of the protected object. So if a process doesn't have access under MAC, the DAC checks wouldn't even be executed since it doesn't have access to the permission
Re: directory order of files
Edmund GRIMLEY EVANS wrote: > > With Linux ext2, and some other systems, when you create files in a > new directory, the file system remembers their order: > > $ mkdir new > $ cd new > $ touch one two three four > $ ls -U > one two three four > > (1) Is there any standard that says a system should behave this way? > Is there any software that depends on this behaviour? Unix filesystem hierarchies are defined to be a partial ordering, not a full ordering. > > (2) Are there Linux file systems that don't work this way? Maybe > someone with a mounted writable reiserfs could do a quick check. > > Please copy replies to me as I am not subscribed. Thanks. bash-2.05# mkdir fu bash-2.05# cd fu bash-2.05# touch one two three four bash-2.05# ls -U one two four three Hans - 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/
Re: directory order of files
Edmund GRIMLEY EVANS wrote: With Linux ext2, and some other systems, when you create files in a new directory, the file system remembers their order: $ mkdir new $ cd new $ touch one two three four $ ls -U one two three four (1) Is there any standard that says a system should behave this way? Is there any software that depends on this behaviour? Unix filesystem hierarchies are defined to be a partial ordering, not a full ordering. (2) Are there Linux file systems that don't work this way? Maybe someone with a mounted writable reiserfs could do a quick check. Please copy replies to me as I am not subscribed. Thanks. bash-2.05# mkdir fu bash-2.05# cd fu bash-2.05# touch one two three four bash-2.05# ls -U one two four three Hans - 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/
Re: Oops while unmounting a reiserfs partition
get patch from www.namesys.com, bug was added and fixed by viro, we just put the patch up while waiting for 2.4.6 to come out. Hans Mathieu Chouquet-Stringer wrote: > > Hello! > > I just mkreiserfsed a new partition (a 50g hardware raid0 array, I know > this is just a testing machine), mounted it, and then unmounted it, and > OOPS! My kernel version is plain 2.4.5... > If you need more information, let me know. > > Jun 4 17:25:03 nynetops03 kernel: reiserfs: checking transaction log (device 08:11) >... > Jun 4 17:25:07 nynetops03 kernel: Using r5 hash to sort names > Jun 4 17:25:07 nynetops03 kernel: ReiserFS version 3.6.25 > Jun 4 17:26:11 nynetops03 kernel: journal_begin called without kernel lock held > Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! > Jun 4 17:26:11 nynetops03 kernel: invalid operand: > Jun 4 17:26:11 nynetops03 kernel: CPU:1 > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] > Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 > Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 >edx: 0001 > Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 >esp: d8e15eac > Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 > Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) > Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf >c0268a61 d7e75250 00e8 > Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 >0018 d8e15f24 df9c5400 c02a8620 > Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 >000a c017ffdc d8e15f24 > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] >[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] >[kill_super+162/288] [path_release+41/48] > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] >[] [] [] [] [] > Jun 4 17:26:11 nynetops03 kernel:[sys_umount+301/352] [sys_munmap+51/80] >[sys_oldumount+12/16] [system_call+51/56] > Jun 4 17:26:11 nynetops03 kernel:[] [] [] >[] > Jun 4 17:26:11 nynetops03 kernel: > Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 >00 00 00 8d bc 27 > > And the decoded output: > ksymoops 2.4.0 on i686 2.4.5. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.5/ (default) > -m /boot/System.map-2.4.5 (default) > > Warning: You did not tell me where to find symbol information. I will > assume that the log matches the kernel and modules that are running > right now and I'll use the default options above for symbol resolution. > If the current kernel and/or modules do not match the log, you can get > more accurate output by telling me the kernel version and where to find > map, modules, ksyms etc. ksymoops -h explains the options. > > Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not >found in System.map. Ignoring ksyms_base entry > Warning (compare_maps): ksyms_base symbol >machine_real_restart_R__ver_machine_real_restart not found in System.map. Ignoring >ksyms_base entry > Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! > Jun 4 17:26:11 nynetops03 kernel: invalid operand: > Jun 4 17:26:11 nynetops03 kernel: CPU:1 > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 > Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 >edx: 0001 > Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 >esp: d8e15eac > Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 > Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) > Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf >c0268a61 d7e75250 00e8 > Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 >0018 d8e15f24 df9c5400 c02a8620 > Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 >000a c017ffdc d8e15f24 > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] >[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] >[kill_super+162/288] [path_release+41/48] > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] >[] [] [] [] [] > Jun 4 17:26:11 nynetops03 kernel:[] [] [] >[] > Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 >00 00 00 8d bc 27 > > >>EIP; c018bb98<= > Trace; c018e2cf >
Re: Oops while unmounting a reiserfs partition
get patch from www.namesys.com, bug was added and fixed by viro, we just put the patch up while waiting for 2.4.6 to come out. Hans Mathieu Chouquet-Stringer wrote: Hello! I just mkreiserfsed a new partition (a 50g hardware raid0 array, I know this is just a testing machine), mounted it, and then unmounted it, and OOPS! My kernel version is plain 2.4.5... If you need more information, let me know. Jun 4 17:25:03 nynetops03 kernel: reiserfs: checking transaction log (device 08:11) ... Jun 4 17:25:07 nynetops03 kernel: Using r5 hash to sort names Jun 4 17:25:07 nynetops03 kernel: ReiserFS version 3.6.25 Jun 4 17:26:11 nynetops03 kernel: journal_begin called without kernel lock held Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! Jun 4 17:26:11 nynetops03 kernel: invalid operand: Jun 4 17:26:11 nynetops03 kernel: CPU:1 Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[c018bb98] Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 edx: 0001 Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 esp: d8e15eac Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf c0268a61 d7e75250 00e8 Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 0018 d8e15f24 df9c5400 c02a8620 Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 000a c017ffdc d8e15f24 Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] [journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] [kill_super+162/288] [path_release+41/48] Jun 4 17:26:11 nynetops03 kernel: Call Trace: [c018e2cf] [c018e516] [c017ffdc] [c014bf3f] [c0137494] [c013bd72] [c0140e79] Jun 4 17:26:11 nynetops03 kernel:[sys_umount+301/352] [sys_munmap+51/80] [sys_oldumount+12/16] [system_call+51/56] Jun 4 17:26:11 nynetops03 kernel:[c013c22d] [c0126ec3] [c013c26c] [c0106e0b] Jun 4 17:26:11 nynetops03 kernel: Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 00 00 00 8d bc 27 And the decoded output: ksymoops 2.4.0 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /boot/System.map-2.4.5 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol machine_real_restart_R__ver_machine_real_restart not found in System.map. Ignoring ksyms_base entry Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! Jun 4 17:26:11 nynetops03 kernel: invalid operand: Jun 4 17:26:11 nynetops03 kernel: CPU:1 Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[c018bb98] Using defaults from ksymoops -t elf32-i386 -a i386 Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 edx: 0001 Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 esp: d8e15eac Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf c0268a61 d7e75250 00e8 Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 0018 d8e15f24 df9c5400 c02a8620 Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 000a c017ffdc d8e15f24 Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] [journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] [kill_super+162/288] [path_release+41/48] Jun 4 17:26:11 nynetops03 kernel: Call Trace: [c018e2cf] [c018e516] [c017ffdc] [c014bf3f] [c0137494] [c013bd72] [c0140e79] Jun 4 17:26:11 nynetops03 kernel:[c013c22d] [c0126ec3] [c013c26c] [c0106e0b] Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3
Re: [RFC] yet another knfsd-reiserfs patch
Why are people afraid to put Neil Brown's code into 2.4? It works, we have tons
of users using it, it is the only nfs solution that has a tested reiserfs user
base, don't worry that it isn't tested and shouldn't go into 2.4 because it is
better tested than any of these quick fixes that are floated by people afraid of
Neil's code am I missing something?
Hans
Chris Mason wrote:
>
> > On Monday, April 23, 2001 10:45:14 AM -0400 Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Hi guys,
> >>
> >> This patch is not meant to replace Neil Brown's knfsd ops stuff, the
> >> goal was to whip up something that had a chance of getting into 2.4.x,
> >> and that might be usable by the AFS guys too. Neil's patch tries to
> >> address a bunch of things that I didn't, and looks better for the
> >> long run.
> >>
> >
>
> Updated to 2.4.5, with the nfs list cc'd this time in hopes of comments
> or flames...
>
> -chris
>
> diff -Nru a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> --- a/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
> +++ b/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
> @@ -116,40 +116,12 @@
> return error;
> }
>
> -/* this should be provided by each filesystem in an nfsd_operations interface as
> - * iget isn't really the right interface
> - */
> -static struct dentry *nfsd_iget(struct super_block *sb, unsigned long ino, __u32
>generation)
> +static struct dentry *dentry_from_inode(struct inode *inode)
> {
> -
> - /* iget isn't really right if the inode is currently unallocated!!
> -* This should really all be done inside each filesystem
> -*
> -* ext2fs' read_inode has been strengthed to return a bad_inode if the inode
> -* had been deleted.
> -*
> -* Currently we don't know the generation for parent directory, so a
>generation
> -* of 0 means "accept any"
> -*/
> - struct inode *inode;
> struct list_head *lp;
> struct dentry *result;
> - inode = iget(sb, ino);
> - if (is_bad_inode(inode)
> - || (generation && inode->i_generation != generation)
> - ) {
> - /* we didn't find the right inode.. */
> - dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
> - inode->i_ino,
> - inode->i_nlink, atomic_read(>i_count),
> - inode->i_generation,
> - generation);
> -
> - iput(inode);
> - return ERR_PTR(-ESTALE);
> - }
> - /* now to find a dentry.
> -* If possible, get a well-connected one
> + /*
> +* If possible, get a well-connected dentry
> */
> spin_lock(_lock);
> for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) {
> @@ -173,6 +145,92 @@
> return result;
> }
>
> +static struct inode *__inode_from_fh(struct super_block *sb, int ino,
> +int generation)
> +{
> + struct inode *inode ;
> +
> + inode = iget(sb, ino);
> + if (is_bad_inode(inode)
> + || (generation && inode->i_generation != generation)
> + ) {
> + /* we didn't find the right inode.. */
> + dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
> + inode->i_ino,
> + inode->i_nlink, atomic_read(>i_count),
> + inode->i_generation,
> + generation);
> +
> + iput(inode);
> + return ERR_PTR(-ESTALE);
> + }
> + return inode ;
> +}
> +
> +static struct inode *inode_from_fh(struct super_block *sb,
> + __u32 *datap,
> + int len)
> +{
> + if (sb->s_op->inode_from_fh)
> + return sb->s_op->inode_from_fh(sb, datap, len) ;
> + return __inode_from_fh(sb, datap[0], datap[1]) ;
> +}
> +
> +static struct inode *parent_from_fh(struct super_block *sb,
> + __u32 *datap,
> + int len)
> +{
> + if (sb->s_op->parent_from_fh)
> + return sb->s_op->parent_from_fh(sb, datap, len) ;
> +
> + if (len >= 3)
> + return __inode_from_fh(sb, datap[2], 0) ;
> + return ERR_PTR(-ESTALE);
> +}
> +
> +/*
> + * two iget funcs, one for inode, and one for parent directory
> + *
> + * this should be provided by each filesystem in an nfsd_operations interface as
> + * iget isn't really the right interface
> + *
> + * If the filesystem doesn't provide funcs to get inodes from datap,
> + * it must be: inum, generation, dir inum. Length of 2 means the
> + * dir inum isn't there.
> + *
> + * iget isn't really right if the inode is currently unallocated!!
> + * This should really all be done inside each filesystem
> + *
> + * ext2fs'
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
Alexander Viro wrote: > > On Fri, 1 Jun 2001, Hans Reiser wrote: > > > known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use > > 2.4.4 > > Different issue. Missing lock_kernel()/unlock_kernel() in kill_super() > appeared in -pre6 and was fixed in -ac2 or so. -ac5 apparently had > introduced something new, that had been reverted (fixing the problem) > in -ac6. thanks for clarification. Hans - 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/
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
Alexander Viro wrote: On Fri, 1 Jun 2001, Hans Reiser wrote: known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use 2.4.4 Different issue. Missing lock_kernel()/unlock_kernel() in kill_super() appeared in -pre6 and was fixed in -ac2 or so. -ac5 apparently had introduced something new, that had been reverted (fixing the problem) in -ac6. thanks for clarification. Hans - 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/
Re: [RFC] yet another knfsd-reiserfs patch
Why are people afraid to put Neil Brown's code into 2.4? It works, we have tons
of users using it, it is the only nfs solution that has a tested reiserfs user
base, don't worry that it isn't tested and shouldn't go into 2.4 because it is
better tested than any of these quick fixes that are floated by people afraid of
Neil's code am I missing something?
Hans
Chris Mason wrote:
On Monday, April 23, 2001 10:45:14 AM -0400 Chris Mason [EMAIL PROTECTED] wrote:
Hi guys,
This patch is not meant to replace Neil Brown's knfsd ops stuff, the
goal was to whip up something that had a chance of getting into 2.4.x,
and that might be usable by the AFS guys too. Neil's patch tries to
address a bunch of things that I didn't, and looks better for the
long run.
Updated to 2.4.5, with the nfs list cc'd this time in hopes of comments
or flames...
-chris
diff -Nru a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
--- a/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
+++ b/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
@@ -116,40 +116,12 @@
return error;
}
-/* this should be provided by each filesystem in an nfsd_operations interface as
- * iget isn't really the right interface
- */
-static struct dentry *nfsd_iget(struct super_block *sb, unsigned long ino, __u32
generation)
+static struct dentry *dentry_from_inode(struct inode *inode)
{
-
- /* iget isn't really right if the inode is currently unallocated!!
-* This should really all be done inside each filesystem
-*
-* ext2fs' read_inode has been strengthed to return a bad_inode if the inode
-* had been deleted.
-*
-* Currently we don't know the generation for parent directory, so a
generation
-* of 0 means accept any
-*/
- struct inode *inode;
struct list_head *lp;
struct dentry *result;
- inode = iget(sb, ino);
- if (is_bad_inode(inode)
- || (generation inode-i_generation != generation)
- ) {
- /* we didn't find the right inode.. */
- dprintk(fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n,
- inode-i_ino,
- inode-i_nlink, atomic_read(inode-i_count),
- inode-i_generation,
- generation);
-
- iput(inode);
- return ERR_PTR(-ESTALE);
- }
- /* now to find a dentry.
-* If possible, get a well-connected one
+ /*
+* If possible, get a well-connected dentry
*/
spin_lock(dcache_lock);
for (lp = inode-i_dentry.next; lp != inode-i_dentry ; lp=lp-next) {
@@ -173,6 +145,92 @@
return result;
}
+static struct inode *__inode_from_fh(struct super_block *sb, int ino,
+int generation)
+{
+ struct inode *inode ;
+
+ inode = iget(sb, ino);
+ if (is_bad_inode(inode)
+ || (generation inode-i_generation != generation)
+ ) {
+ /* we didn't find the right inode.. */
+ dprintk(fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n,
+ inode-i_ino,
+ inode-i_nlink, atomic_read(inode-i_count),
+ inode-i_generation,
+ generation);
+
+ iput(inode);
+ return ERR_PTR(-ESTALE);
+ }
+ return inode ;
+}
+
+static struct inode *inode_from_fh(struct super_block *sb,
+ __u32 *datap,
+ int len)
+{
+ if (sb-s_op-inode_from_fh)
+ return sb-s_op-inode_from_fh(sb, datap, len) ;
+ return __inode_from_fh(sb, datap[0], datap[1]) ;
+}
+
+static struct inode *parent_from_fh(struct super_block *sb,
+ __u32 *datap,
+ int len)
+{
+ if (sb-s_op-parent_from_fh)
+ return sb-s_op-parent_from_fh(sb, datap, len) ;
+
+ if (len = 3)
+ return __inode_from_fh(sb, datap[2], 0) ;
+ return ERR_PTR(-ESTALE);
+}
+
+/*
+ * two iget funcs, one for inode, and one for parent directory
+ *
+ * this should be provided by each filesystem in an nfsd_operations interface as
+ * iget isn't really the right interface
+ *
+ * If the filesystem doesn't provide funcs to get inodes from datap,
+ * it must be: inum, generation, dir inum. Length of 2 means the
+ * dir inum isn't there.
+ *
+ * iget isn't really right if the inode is currently unallocated!!
+ * This should really all be done inside each filesystem
+ *
+ * ext2fs' read_inode has been strengthed to return a bad_inode if the inode
+ * had been deleted.
+ *
+ * Currently we don't know the generation for parent directory,
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use
2.4.4
Hans
[EMAIL PROTECTED] wrote:
>
> On Thu, May 31, 2001 at 05:04:50PM -0500, Jordan wrote:
> > Alan Cox wrote:
> > >
> > > > I'm staying on 2.4.5-ac5 for whatever it's worth (putting my life on the
> > > > line for the community? kidding...) and will report anything new. I will
> > > > be on the lookout for later ac patches, 2.4.6 ... and hopefully anything
> > > > anybody can share with me about this. I hope we'll see an end to these
> > >
> > > Can you tell me if 2.4.5-ac4 is ok. ac5 has a small 'obviously correct'
> > > reiserfs module unload change that seems the first suspect
> > >
> > > 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/
> >
> > I have seen this same problem with unmounting in 2.4.5-ac5, it was
> > perfectly fine in 2.4.5-ac3 and ac4. I would guess the module unload is
> > what did it.
> >
> 2.4.5-ac4 was fine, 2.4.5-ac5:
>
> /space in /etc/fstab:
>
> /dev/hda10 /space1 reiserfsdefaults 1 2
>
> strace umount /space1:
>
> open("/usr/lib/locale/en_US/LC_TIME", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0
> old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
> old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0
> old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
> close(3)= 0
> SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0
> semop(1074993880, 0x40130210, 0)= 0
> brk(0x8056000) = 0x8056000
> readlink("/space1", 0xbfffe51c, 4095) = -1 EINVAL (Invalid argument)
> open("/etc/mtab", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x40021000
> read(3, "/dev/hde1 / ext2 rw 0 0\nproc /pr"..., 4096) = 680
> read(3, "", 4096) = 0
> close(3)= 0
> munmap(0x40021000, 4096)= 0
> oldumount("/space1"
>
> and there it hangs. The kernel doesn't hang, but while 'mount' displays
> /space1 as mounted, ls /space1/ says nothing. df -m reveals:
>
> Filesystem 1M-blocks Used Available Use% Mounted on
> /dev/hda102015 907 1005 48% /space1
>
> Good luck,
> Jurriaan
> --
> The music in my heart I bore long after it was heard no more.
> William Wordsworth
> GNU/Linux 2.4.5-ac5 SMP/ReiserFS 2x1402 bogomips load av: 5.60 2.71 1.16
> -
> 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/
-
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/
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use
2.4.4
Hans
[EMAIL PROTECTED] wrote:
On Thu, May 31, 2001 at 05:04:50PM -0500, Jordan wrote:
Alan Cox wrote:
I'm staying on 2.4.5-ac5 for whatever it's worth (putting my life on the
line for the community? kidding...) and will report anything new. I will
be on the lookout for later ac patches, 2.4.6 ... and hopefully anything
anybody can share with me about this. I hope we'll see an end to these
Can you tell me if 2.4.5-ac4 is ok. ac5 has a small 'obviously correct'
reiserfs module unload change that seems the first suspect
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/
I have seen this same problem with unmounting in 2.4.5-ac5, it was
perfectly fine in 2.4.5-ac3 and ac4. I would guess the module unload is
what did it.
2.4.5-ac4 was fine, 2.4.5-ac5:
/space in /etc/fstab:
/dev/hda10 /space1 reiserfsdefaults 1 2
strace umount /space1:
open(/usr/lib/locale/en_US/LC_TIME, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0
old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
close(3)= 0
open(/usr/lib/locale/en_US/LC_NUMERIC, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002
close(3)= 0
open(/usr/lib/locale/en_US/LC_CTYPE, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0
old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
close(3)= 0
SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0
semop(1074993880, 0x40130210, 0)= 0
brk(0x8056000) = 0x8056000
readlink(/space1, 0xbfffe51c, 4095) = -1 EINVAL (Invalid argument)
open(/etc/mtab, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40021000
read(3, /dev/hde1 / ext2 rw 0 0\nproc /pr..., 4096) = 680
read(3, , 4096) = 0
close(3)= 0
munmap(0x40021000, 4096)= 0
oldumount(/space1
and there it hangs. The kernel doesn't hang, but while 'mount' displays
/space1 as mounted, ls /space1/ says nothing. df -m reveals:
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/hda102015 907 1005 48% /space1
Good luck,
Jurriaan
--
The music in my heart I bore long after it was heard no more.
William Wordsworth
GNU/Linux 2.4.5-ac5 SMP/ReiserFS 2x1402 bogomips load av: 5.60 2.71 1.16
-
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/
-
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/
Re: [reiserfs-list] Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: > Graciously accepted. Coming up with something sensible in a mere 6 > months would be a minor miracle. ;-) > > - what happens if the user forgets to close the transaction? then the user has branched into his own version, or at least that would be my take on it. Another possible method is to expire transactions by persons who lack permission to keep them open indefinitely. I suppose one could expire them to abort, or expire them to commit, both being valid under some circumstances. > >I plan to set a checkpoint there (because the transaction got >too big) and log the fact that it's open. > > - issues of lock/transaction duration > >Once again relying on checkpoints, when the transaction gets >uncomfortably big for cache, set a checkpoint. I haven't thought >about locks > > - transaction batching > >1) Explicit transaction batch close 2) Cache gets past a certain >fullness. In both cases, no new transactions are allowed to start >and as soon as all current ones are closed we close the batch.re6; > > - of levels of isolation > - concurrent transactions modifying global fs metadata >and some but not all of those concurrent transactions receiving a >rollback > >First I was going to write 'huh?' here, then I realized you're >talking about real database ops, not just filesystem ops. I had >in mind something more modest: transactions are 'mv', 'read/write' >(if the 'atomic read/write' is set), other filesystem operations I've >forgotten, and anything the user puts between open_xact and >close_xact. You are raising the ante a little ;-) > >In my case (Tux2) I could do an efficient rollback to the beginning > of the batch (phase), then I would have had to have kept an >in-memory log of the transactions for selective replay. With a >journal log you can obviously do the same thing, but perhaps more >efficiently if your journal design supports undo/redo. > >The above is a pure flight of fancy, we won't be seeing anything >so fancy as an API across filesystems. It is just a matter of time, and we will. I think that the major release AFTER 2.6 will see it. First we have to get a prototype done in time for 2.6 > > - permissions relating to keeping transactions open. >We can see this one in the light of a simple filesystem >transaction: what happens if we are in the middle of a mv and >someone changes the permissions? Go with the starting or >ending permissions? > > Well, the database side of this is really interesting, but to get > something generic across filesystems, the scope pretty well has to be > limited to journal-type transactions, don't you think? don't know what a journal-type transaction is and how it differs from a database transaction. > > -- > Daniel - 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/
Re: NULL characters in file on ReiserFS again.
Andrej Borsenkow wrote: > > This happened to me yesterday on kernel-2.4.4-6mdk (Mandrake cooker, based > on 2.4.4-ac14), single reiser root filesystem, mounted with default options. > Hardware - ASUS CUSL2 (i815e chipset), Fujitsu UDMA-4 drive. > > I tried to change hostname and did not have the corresponding entry in > /etc/hosts (or anywhere). As a tesult, startx hung starting X server; it was > not possible to switch to alpha console or kill X server. I pressed reset > and after reboot looked into /var/log/XFree86*log - and there were a bunch > of ^@ there. > > I then run fsck from another system (installed on another partition) but > there was no errors (well, new errors - there was off-by-one free blocks > bitmap mismatch but it was always there, I do not know how to correct it). I > tried the above once more but this time XFree log was O.K. > > So, I really do not know how to reproduce it, but I wanted to give a warning > that a problem still exists (albeit in emergency situation). As Reiser does > not do any fsck after crash, the problem is serious enough IMHO. > > -andrej > > - > 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/ this is the nature of metadata journaling filesystems. - 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/
Re: NULL characters in file on ReiserFS again.
Andrej Borsenkow wrote: This happened to me yesterday on kernel-2.4.4-6mdk (Mandrake cooker, based on 2.4.4-ac14), single reiser root filesystem, mounted with default options. Hardware - ASUS CUSL2 (i815e chipset), Fujitsu UDMA-4 drive. I tried to change hostname and did not have the corresponding entry in /etc/hosts (or anywhere). As a tesult, startx hung starting X server; it was not possible to switch to alpha console or kill X server. I pressed reset and after reboot looked into /var/log/XFree86*log - and there were a bunch of ^@ there. I then run fsck from another system (installed on another partition) but there was no errors (well, new errors - there was off-by-one free blocks bitmap mismatch but it was always there, I do not know how to correct it). I tried the above once more but this time XFree log was O.K. So, I really do not know how to reproduce it, but I wanted to give a warning that a problem still exists (albeit in emergency situation). As Reiser does not do any fsck after crash, the problem is serious enough IMHO. -andrej - 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/ this is the nature of metadata journaling filesystems. - 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/
Re: [reiserfs-list] Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: Graciously accepted. Coming up with something sensible in a mere 6 months would be a minor miracle. ;-) - what happens if the user forgets to close the transaction? then the user has branched into his own version, or at least that would be my take on it. Another possible method is to expire transactions by persons who lack permission to keep them open indefinitely. I suppose one could expire them to abort, or expire them to commit, both being valid under some circumstances. I plan to set a checkpoint there (because the transaction got too big) and log the fact that it's open. - issues of lock/transaction duration Once again relying on checkpoints, when the transaction gets uncomfortably big for cache, set a checkpoint. I haven't thought about locks - transaction batching 1) Explicit transaction batch close 2) Cache gets past a certain fullness. In both cases, no new transactions are allowed to start and as soon as all current ones are closed we close the batch.re6; - of levels of isolation - concurrent transactions modifying global fs metadata and some but not all of those concurrent transactions receiving a rollback First I was going to write 'huh?' here, then I realized you're talking about real database ops, not just filesystem ops. I had in mind something more modest: transactions are 'mv', 'read/write' (if the 'atomic read/write' is set), other filesystem operations I've forgotten, and anything the user puts between open_xact and close_xact. You are raising the ante a little ;-) In my case (Tux2) I could do an efficient rollback to the beginning of the batch (phase), then I would have had to have kept an in-memory log of the transactions for selective replay. With a journal log you can obviously do the same thing, but perhaps more efficiently if your journal design supports undo/redo. The above is a pure flight of fancy, we won't be seeing anything so fancy as an API across filesystems. It is just a matter of time, and we will. I think that the major release AFTER 2.6 will see it. First we have to get a prototype done in time for 2.6 - permissions relating to keeping transactions open. We can see this one in the light of a simple filesystem transaction: what happens if we are in the middle of a mv and someone changes the permissions? Go with the starting or ending permissions? Well, the database side of this is really interesting, but to get something generic across filesystems, the scope pretty well has to be limited to journal-type transactions, don't you think? don't know what a journal-type transaction is and how it differs from a database transaction. -- Daniel - 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/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: > > On Tuesday 22 May 2001 22:10, Andreas Dilger wrote: > > Peter Braam writes: > > > File system journal recovery can corrupt a snapshot, because it > > > copies data that needs to be preserved in a snapshot. During > > > journal replay such data may be copied again, but the source can > > > have new data already. > > > > The way it is implemented in reiserfs is to wait for existing > > transactions to complete, entirely flush the journal and block all > > new transactions from starting. Stephen implemented a journal flush > > API to do this for ext3, but the hooks to call it from LVM are not in > > place yet. This way the journal is totally empty at the time the > > snapshot is done, so the read-only copy does not need to do journal > > recovery, so no problems can arise. > > I suppose I'm just reiterating the obvious, but we should eventually > have a generic filesystem transaction API at the VFS level, once we > have enough data points to know what the One True API should be. > > -- > Daniel > - > 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/ Daniel, implementing transactions is not a trivial thing as you probably know. It requires that you resolve such issues as, what happens if the user forgets to close the transaction, issues of lock/transaction duration, of transaction batching, of levels of isolation, of concurrent transactions modifying global fs metadata and some but not all of those concurrent transactions receiving a rollback, and of permissions relating to keeping transactions open. I would encourage you to participate in the reiser4 design discussion we will be having over the next 6 months, and give us your opinions. Josh will be leading that design effort for the ReiserFS team. Hans - 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/
Re: Dying disk and filesystem choice.
Erik Mouw wrote: > > On Thu, May 24, 2001 at 09:53:45AM -0700, Hans Reiser wrote: > > No, reiserfs does have badblock support > > > > You just have to get it as a separate patch from us because it was > > written after code freeze. > > IMHO we are not that deep into code freeze anymore. Freevxfs got added > in linux-2.4.5-pre*, so I think that a patch that adds a useful feature > like badblock support would be OK. > > Erik > > -- > J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department > of Electrical Engineering, Faculty of Information Technology and Systems, > Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands > Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] > WWW: http://www-ict.its.tudelft.nl/~erik/ > - > 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/ vxfs is probably a completely separate fs that won't destabilize other filesystems, or at least I hope so. ReiserFS is stable code now, we aren't going to change that by adding features unless they go into the ac series for six weeks or so first. ReiserFS is the SuSE recommended FS, and we can't go destabilizing it. I am told by sistina.com (maintainers of LVM) that in their surveys of the users of LVM, 90% use ReiserFS, and the users of LVM tend very much to be persons with mission critical servers. We sent Linus a patch to mark us as stable not experimental. When we say stable, it means something. Right now it means zero (yes, zero) new bug reports that are not user error or old versions or fsck, since 2.4.4 came out. fsck is improving dramatically in stability every week. I used it myself last week, and got my data back minus the root directory after trashing the front of my partition accidentally. (Which gave me a chance to review its end user usability, which is also improving.) We aren't yet ready to pass the zero a random block and see it recover always excepting what was zero'd test, but we will be before long. One of the things we realized recently is that if the user knows what got trashed, and he can tell this to the FS, it can be very useful for bitmap blocks. Sorry, I wander here. Hans - 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/
Re: Dying disk and filesystem choice.
J Sloan wrote: > > Excellent! > > Will this be in resierfs 4.0 then? > > cu > > jjs > > Hans Reiser schrieb: > > > No, reiserfs does have badblock support > > > > You just have to get it as a separate patch from us because it was written after > > code freeze. No, version 4 won't ship until september 2002, these features are all v3.7, which will be sent to Linus as soon as 2.5.1 opens up. Hans - 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/
Re: Dying disk and filesystem choice.
Andi Kleen wrote: > > On Thu, May 24, 2001 at 12:58:14AM -0600, Andreas Dilger wrote: > > Well reiserfs is probably a very bad choice at this point. It > > does not have any bad blocks support (yet), so as soon as you have > > a bad block you are stuck. > > reiserfs doesn't, but the HD usually has transparently in its firmware. > So it hits a bad block; you see an IO error and the next time you hit > the block the firmware has mapped in a fresh one from its internal > reserves. > > -Andi > - > 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/ No, reiserfs does have badblock support You just have to get it as a separate patch from us because it was written after code freeze. Hans - 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/
Re: Dying disk and filesystem choice.
Andi Kleen wrote: On Thu, May 24, 2001 at 12:58:14AM -0600, Andreas Dilger wrote: Well reiserfs is probably a very bad choice at this point. It does not have any bad blocks support (yet), so as soon as you have a bad block you are stuck. reiserfs doesn't, but the HD usually has transparently in its firmware. So it hits a bad block; you see an IO error and the next time you hit the block the firmware has mapped in a fresh one from its internal reserves. -Andi - 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/ No, reiserfs does have badblock support You just have to get it as a separate patch from us because it was written after code freeze. Hans - 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/
Re: Dying disk and filesystem choice.
J Sloan wrote: Excellent! Will this be in resierfs 4.0 then? cu jjs Hans Reiser schrieb: No, reiserfs does have badblock support You just have to get it as a separate patch from us because it was written after code freeze. No, version 4 won't ship until september 2002, these features are all v3.7, which will be sent to Linus as soon as 2.5.1 opens up. Hans - 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/
