1. That may actually work, but I think that you are missing the real source of ->read_inode() ugliness. It's not a union in the inode, it's the fact that ->read_inode() itself is ill-defined. IMO iget() should eventually go away - the only reason why it is still there is knfsd and Roman's patches look pretty interesting in that respect. I suspect that one of possible solutions is to have a variant of iget() that would return the marked inode instead of doing ->read_inode(). And let the fs (in foo_lookup()) call that, check whether inode is marked (== new) and if it is - fill it directly. I.e. do whatever your read_inode() would do, but with the arguments passed explicitly instead of trying to fit them into ->i_ino. Filesystems that do not allow links are already doing something similar (they are pretty much guaranteed an icache miss). If you want more details - let's take it to fsdevel, OK? It's _not_ a 2.4 project, though. Allocation is completely separate beast. 2. I'll say... generic IO stuff _does_ belong to VFS, unless you are going to redefine meaning of the word. 3. Care to show something better? If you know how to do it - I'm sure that Erez will be rather interested in your help. 6. You know how it happens? Interface-changing patch gets submitted to Linus and there is no way in hell to tell how many iterations it will take and when it will go into the tree. And iterations may be rather fast. It's not a CVS, Linus does not use it. He has every right to prefer other methods - no point complaining, but the reality is that process _is_ different. Summary of which version of patch do you want? All of them, slightly changing and separated by 5-10 minutes? Wow. I know that I would not be happy about that, but tastes differ. If you think that I don't get the same problems - well, I have a nice bridge for you. For non-trivial changes summary usually goes _after_ the final variant gets into the tree. Tough. Oh, well... I'm going down right now, if you want to talk about the read_inode() and union-killing stuff - let's take it to fsdevel where it belongs. BTW, same goes for another variant - the problem I see with it is that we would have to put the icache into a large bunch of caches (size of element is a constant) and that's going to make icache eviction interesting.
You know, it's not a CPSU and there is no party line (if somebody happens to have such a beast - FWIC they may shove it up their arse, I'm not playing these games). There are two more or less similar technics, with different tradeoffs and benefits. So far nobody had actually done a comparison of them on the same kernel and fs layout (OK, there was a recent work on FreeBSD, but there are some subtle points). Nothing prevents having both implemented, moreover, they will require more or less the same functionality from the whole whorehouse - VM, VFS-to-devices glue, etc. At that point nobody can actually say "this variant is clear win". The only honest way is to do one you consider more promising, do it as best as you can and compare. Then (hopefully) learn from the details of that comparison and see what can be improved. Lather, rinse, repeat... It's not like we had to have One True Fs(tm) - there is no such thing, simply because there are different tasks, different loads and solution that is good for one may suck for another. So no, I don't think that journalling folks are wasting their time. I also don't think that s-u folks are doing that. The only agenda I have here is curiosity - I want to know how far can these variants be pushed. And it means that cheating is not an option - not to mention anything else, it simply defeats the purpose of the exercise;-) In other words, personal opinion is exactly that - personal opinion. Personally I find s-u more attractive, but I'm pretty interested in seeing Chris, Stephen, XFS folks, [substitute the list of journalling projects] doing their best. So far everyone needs the same infrastructure and I'm quite happy to see what Chris and Stephen are doing. Moreover, once it will be there we are not going to stomp on each other's toes - after that point work belongs to individual filesystems. I have no strong opinions on the way this stuff will look like - needs are similar enough and guys doing that are in much better position to decide - they have more or less debugged code to look at, and that's a big help. In principle, the less code duplication they will get, the better (less pain to catch bugs afterwards), but IMO it's for them to decide. AFAICS they are working together quite fine, so the best thing for everybody who doesn't actively participate right now (e.g. for me) is to avoid interfering.
1. Search l-k archives for the last couple of weeks and you'll see there my posting proposing (one more time) exactly that, with details on implementation. Subject to approval of individual fs maintainers. BTW, any fs _may_ use ->generic_ip - quite a few do exactly that. Reiserfs can use it right now and could do so a year ago. At that point decision on each fs belongs to fs maintainers, in that case - to Hans. All infrastructure is there since long and many filesystems are using it. Oh, and that contributes _nothing_ to HFS problems. 2. Keep your attributions straight, I don't think that journalling is a good idea at all. Personally, I prefer soft-updates. 3. Check the work of Erez Zadok. He has a stacking toolkit and working filesystems based on it. With the current VFS. There are problems with his code, but they are mostly semantical (i.e. nobody knows what is actually the right thing in several corner cases). Again, his code works with current VFS. 4. And what would I do with it? Split in per-fs parts and send to fs maintainers? Sure, I can do that, but this stuff has nothing with VFS at this stage, each fs may do such switch quite fine and decision definitely belongs to maintainers. 5. I'm _not_ Linus. Ask him. BTW, I don't get 100% patch inclusion (nobody does). 6. read fsdevel. Design stuff is posted and discussed there. 7. Huh???
BTW, _all_ the stuff you are asking about is available in archives of l-k and fsdevel. I understand that you simply don't have free time to read it, but I'm sure that you can understand that other may have no time for retyping it for you. And get a clue, already - search would take less than it took you to type your posting.
Has Linux development become too political, bottlenecked and ego-driven? Witness the recent exchange between Hans Reiser, of ReiserFS fame, and Alexander Viro (VFS maintainer) on Linux-Kernel; Hans, and others, were griping about Viro refusing patches and ideas on principle, and Viro keeps telling people to shut up and read the code.
Sigh... Folks, what about getting the story straight? 1. Hans (or anyone in Reiserfs team, for that matter) did not submit any patches _to_ VFS. The only piece that modifies VFS itself is, as all sides agree, ugly but fixable and did not cause any objections. 2. Patch contained a large chunk of code that obviously was not reviewed for a couple of years, which is a bad thing, especially for interface code. Again, all sides seem to agree on that. 3. "Others" in that context probably means Richard with devfs stuff? Well, the problem with devfs was that it did _not_ change VFS. Instead it tried to do everything in a filesystem and that gave a huge bunch of races and major ugliness. Richard refused (search l-k archives) to move the relevant parts of changes into VFS. Many times. After being asked to do that, since that would make things much cleaner. 4. Ideas are good when the author knows what he is talking about. In particular, if the idea starts with "let's make this to do that" it would better be supported by understanding how "this" currently works or willingness to redo it completely and make sure that nothing breaks. If it is there - fine, things get discussed (tons of examples in archives). If not - too bad. 5. Reading the code is definitely useful thing - especially if you want to change that code. No? 6. Rumors about the need to submit stuff through me are greatly exaggregated (read: provably are pure BS). Discussing the stuff on maillists _is_ needed. _Submitting_ it to me (or anybody other than Linus) is not. 7. During 2.3 there had been several large changes of VFS. If you are claiming that Andrea, Ingo, Stephen and I are the same person... <shudder> As for the "external pressure" - get a grip. Really. As far as I'm concerned this stuff is done on technical merits. You can't build a pressure sufficient to make me act against that. And I mean it - I consider self-respect more valuable than having a paid job. YMMV. You can't force anyone of us to do what you like. You can learn the kernel and start submitting patches that would be acceptable to Linus on their technical merits. That's how it works. I would be glad to see anyone joining the VFS/fs work. Learn it and go ahead. Or keep wanking - nobody can deprive you of that right.
Slashdot Mirror
1. That may actually work, but I think that you are missing the real source of ->read_inode() ugliness. It's not a union in the inode, it's the fact that ->read_inode() itself is ill-defined. IMO iget() should eventually go away - the only reason why it is still there is knfsd and Roman's patches look pretty interesting in that respect. I suspect that one of possible solutions is to have a variant of iget() that would return the marked inode instead of doing ->read_inode(). And let the fs (in foo_lookup()) call that, check whether inode is marked (== new) and if it is - fill it directly. I.e. do whatever your read_inode() would do, but with the arguments passed explicitly instead of trying to fit them into ->i_ino. Filesystems that do not allow links are already doing something similar (they are pretty much guaranteed an icache miss). If you want more details - let's take it to fsdevel, OK? It's _not_ a 2.4 project, though. Allocation is completely separate beast.
2. I'll say... generic IO stuff _does_ belong to VFS, unless you are going to redefine meaning of the word.
3. Care to show something better? If you know how to do it - I'm sure that Erez will be rather interested in your help.
6. You know how it happens? Interface-changing patch gets submitted to Linus and there is no way in hell to tell how many iterations it will take and when it will go into the tree. And iterations may be rather fast. It's not a CVS, Linus does not use it. He has every right to prefer other methods - no point complaining, but the reality is that process _is_ different. Summary of which version of patch do you want? All of them, slightly changing and separated by 5-10 minutes? Wow. I know that I would not be happy about that, but tastes differ. If you think that I don't get the same problems - well, I have a nice bridge for you. For non-trivial changes summary usually goes _after_ the final variant gets into the tree. Tough.
Oh, well... I'm going down right now, if you want to talk about the read_inode() and union-killing stuff - let's take it to fsdevel where it belongs. BTW, same goes for another variant - the problem I see with it is that we would have to put the icache into a large bunch of caches (size of element is a constant) and that's going to make icache eviction interesting.
You know, it's not a CPSU and there is no party line (if somebody happens to have such a beast - FWIC they may shove it up their arse, I'm not playing these games). There are two more or less similar technics, with different tradeoffs and benefits. So far nobody had actually done a comparison of them on the same kernel and fs layout (OK, there was a recent work on FreeBSD, but there are some subtle points). Nothing prevents having both implemented, moreover, they will require more or less the same functionality from the whole whorehouse - VM, VFS-to-devices glue, etc. At that point nobody can actually say "this variant is clear win". The only honest way is to do one you consider more promising, do it as best as you can and compare. Then (hopefully) learn from the details of that comparison and see what can be improved. Lather, rinse, repeat... ;-)
It's not like we had to have One True Fs(tm) - there is no such thing, simply because there are different tasks, different loads and solution that is good for one may suck for another.
So no, I don't think that journalling folks are wasting their time. I also don't think that s-u folks are doing that. The only agenda I have here is curiosity - I want to know how far can these variants be pushed. And it means that cheating is not an option - not to mention anything else, it simply defeats the purpose of the exercise
In other words, personal opinion is exactly that - personal opinion. Personally I find s-u more attractive, but I'm pretty interested in seeing Chris, Stephen, XFS folks, [substitute the list of journalling projects] doing their best. So far everyone needs the same infrastructure and I'm quite happy to see what Chris and Stephen are doing. Moreover, once it will be there we are not going to stomp on each other's toes - after that point work belongs to individual filesystems.
I have no strong opinions on the way this stuff will look like - needs are similar enough and guys doing that are in much better position to decide - they have more or less debugged code to look at, and that's a big help.
In principle, the less code duplication they will get, the better (less pain to catch bugs afterwards), but IMO it's for them to decide. AFAICS they are working together quite fine, so the best thing for everybody who doesn't actively participate right now (e.g. for me) is to avoid interfering.
1. Search l-k archives for the last couple of weeks and you'll see there my posting proposing (one more time) exactly that, with details on implementation. Subject to approval of individual fs maintainers. BTW, any fs _may_ use ->generic_ip - quite a few do exactly that. Reiserfs can use it right now and could do so a year ago. At that point decision on each fs belongs to fs maintainers, in that case - to Hans. All infrastructure is there since long and many filesystems are using it. Oh, and that contributes _nothing_ to HFS problems.
2. Keep your attributions straight, I don't think that journalling is a good idea at all. Personally, I prefer soft-updates.
3. Check the work of Erez Zadok. He has a stacking toolkit and working filesystems based on it. With the current VFS. There are problems with his code, but they are mostly semantical (i.e. nobody knows what is actually the right thing in several corner cases). Again, his code works with current VFS.
4. And what would I do with it? Split in per-fs parts and send to fs maintainers? Sure, I can do that, but this stuff has nothing with VFS at this stage, each fs may do such switch quite fine and decision definitely belongs to maintainers.
5. I'm _not_ Linus. Ask him. BTW, I don't get 100% patch inclusion (nobody does).
6. read fsdevel. Design stuff is posted and discussed there.
7. Huh???
BTW, _all_ the stuff you are asking about is available in archives of l-k and fsdevel. I understand that you simply don't have free time to read it, but I'm sure that you can understand that other may have no time for retyping it for you. And get a clue, already - search would take less than it took you to type your posting.
As for the "external pressure" - get a grip. Really. As far as I'm concerned this stuff is done on technical merits. You can't build a pressure sufficient to make me act against that. And I mean it - I consider self-respect more valuable than having a paid job. YMMV. You can't force anyone of us to do what you like. You can learn the kernel and start submitting patches that would be acceptable to Linus on their technical merits. That's how it works. I would be glad to see anyone joining the VFS/fs work. Learn it and go ahead. Or keep wanking - nobody can deprive you of that right.