Re: fs changes in 2.3
On Mon, 01 May 2000, Ani Joshi wrote: > hello, can someone point me to a rough list (if there is one) of all the > things that need to be changed in each fs driver for 2.3? i'm not subscribed > to this list so if this was posted before, please point me to a list archive > if there is one. I am afraid, changes in vfs from 2.2.x to 2.3.99-x are too many to list. There have been many changes in vm also. If you are porting a fs which is currently working on 2.2.x, you may want to look at 2.2.x and 2.3.99-x ext2 source. > > > thanks, > > ani > > > please CC me to any replies -- Amit Kale Veritas Software ( http://www.veritas.com )
Re: fs changes in 2.3
On Sun, Apr 30, 2000 at 10:59:57PM -0700, Ani Joshi wrote: > hello, can someone point me to a rough list (if there is one) of all the > things that need to be changed in each fs driver for 2.3? Not off the top of my head; one thing that might be instructive is to compare the implementations of a couple of "simple" filesystems (minix, romfs, ext2) in 2.2 and 2.3. > i'm not subscribed to this list so if this was posted before, please point > me to a list archive if there is one. Try http://www.kernelnotes.org/lnxlists> (from memory, that may not be exactly right); Anything from Al Viro with [RFC] or similar in the subject is likely to be relevant.
Re: fs changes in 2.3
I think that improving support from folks who change VFS code for folks who are affected is needed. I don't much care for the screaming at people who don't track your changes by reading ext2 code updates development model that is currently in place. (E.g. the amiga FS emails seen on this list) Perhaps a set of comments in the VFS code saying here is what you do to interface with me would be better. Perhaps in 2.5 the ReiserFS team will start contributing towards improving VFS in this direction as we start trying to move linux VFS towards something richer in functionality.:) VFS code needs to be maintained by persons with supportive personalities. Hans
Re: fs changes in 2.3
Hans Reiser wrote: > > I think that improving support from folks who change VFS code > for folks who are affected is needed. Hei Hans! I second that. I had to stop maintaining the steganographic file system around 2.3.7 because I did not have that much time to find out where my fs is "broken" and needs to be "fixed". I think the VFS needs a better documentation. Correct me if I am mistaken in this matter but I cannot find anything that is nearly up to date and I don't want to read and understand the sources for two or three file systems I do not have any strong affections to. One should be able to interface to the VFS without having to know or learn intimacies of the second extended file system. Peter
Re: fs changes in 2.3
On Sun, Apr 30, 2000 at 10:09:45PM -0700, Hans Reiser wrote: > I think that improving support from folks who change VFS code for folks who are > affected is needed. Hans, what are you talking about ? Are you talking about large solution provider who should change its attitude and be more customer friendly or are you talking about people who spend their *own* time hacking around sources ? > I don't much care for the screaming at people who don't track your changes by Again, Hans, what. are. you. talking. about. ? > reading ext2 code updates development model that is currently in place. > (E.g. the amiga FS emails seen on this list) > Perhaps a set of comments in the VFS code saying here is what you do to > interface with me would be better. > > Perhaps in 2.5 the ReiserFS team will start contributing towards improving VFS I guess, you were unable to to this for a 2.3 due to some fundamental reason? If no, just do it. Do not make proposals -- just do it. > in this direction as we start trying to move linux VFS towards something richer > in functionality.:) Oh, no! "richer in functionality", where we are? A trade show ? > > VFS code needs to be maintained by persons with supportive personalities. Hans, I do not want to be unpleasant, but you behave like an second level manager who can not get to the first level for quite a long time. Stop ranting. Read sources. Write good code. Discuss reasonable things. And please, let us know what was the message of this message. Roman.
Re: fs changes in 2.3
"Roman V. Shaposhnick" wrote: > Hans, I do not want to be unpleasant, but you behave like an second level > manager who can not get to the first level for quite a long time. Ok, let me put it in different lingo. Viro is a fucking asshole who makes life miserable for people trying to add functionality to Linux. What's more, he has no imagination and his contributions do not begin to make up for the shit he gives people like Gooch who is trying to add something that wasn't in System 7 and is therefor beyond Viro's ability to cope with. It takes more than a license to make source code open. He shouldn't be let near the source code, his existence is a net loss for Linux. There, is that less like a second line manager? If any of you prefer second line manager lingo, stick with the previous email.:-) In 2.5 we'll add stuff to VFS. We might even try to sneak some stuff into 2.3 if Viro keeps 2.4 from being ready for another two weeks. Hans
Re: fs changes in 2.3
On Tue, 2 May 2000, Hans Reiser wrote: [ more senseless flame ] > > He surely hasn't fixed the nfs problem for us either now has he? > Al Viro has zero obligation to fix anything for us, especially since we aren't in the kernel, and the NFS features that need fixing work just fine with the filesystems that are. So the reiserfs team has to fix a problem NFS only has when interacting with reiserfs. Yes, it would have been nice if someone else had the chance to do it for us, but to expect them to, and to be mad when they don't, is more than a little silly. Its time to move on Hans, we have more important things to worry about. -chris
Re: fs changes in 2.3
On Mon, 1 May 2000, Hans Reiser wrote: > "Roman V. Shaposhnick" wrote: > > > Hans, I do not want to be unpleasant, but you behave like an second level > > manager who can not get to the first level for quite a long time. > > Ok, let me put it in different lingo. [senseless flame] Hans, what are you doing? Is your real objective here to ruin any chance of working well with Al Viro? Suck it up, we are the new kids on the block, and its our job to play nice with the existing kernel developers. If you can't do that, go home now. Al had legitimate gripes without first patch. He helped us fix the problems, read the code, and sent advice. I wasn't wild about his presentation style, but you don't have to read many l-k posts to see that he treated us the same as everyone else. I got over it, you need to as well. -chris
Re: fs changes in 2.3
Chris Mason wrote: > > On Mon, 1 May 2000, Hans Reiser wrote: > > > "Roman V. Shaposhnick" wrote: > > > > > Hans, I do not want to be unpleasant, but you behave like an second level > > > manager who can not get to the first level for quite a long time. > > > > Ok, let me put it in different lingo. > > [senseless flame] > > Hans, what are you doing? Is your real objective here to ruin any chance > of working well with Al Viro? Suck it up, we are the new kids on the > block, and its our job to play nice with the existing kernel developers. > If you can't do that, go home now. > > Al had legitimate gripes without first patch. He helped us fix the > problems, read the code, and sent advice. I wasn't wild about his > presentation style, but you don't have to read many l-k posts to see that > he treated us the same as everyone else. I got over it, you need to as > well. > > -chris Yes, he is an asshole to everyone not at redhat, we have agreement on that. He had absolutely no intention of being helpful to us, you can tell from his emails that his objective was to maximize the noise and minimize the assistance by being as unspecific as possible. He didn't give a damn about helping us to fix bugs, he wrote his emails solely for the objective of keeping us from competing with ext3 in 2.4. Actually, if you read what he posts on linux-kernel, he has rather little desire to help anyone at all, what he wants to do is engage in an aggressive display of how much better he knows his corner of the kernel that everyone but him finds too uninteresting to study. He reminds me of a malicious cracker I once knew who used to pick on users who were unsophisticated at computers (but better educated than him in most other ways). I tried asking the cracker why he did these things, but of course there was no answer for that question. He is insecure, and needs to engage in displays of aggression to compensate for other things (which I won't guess at.) He surely hasn't fixed the nfs problem for us either now has he? We'll send patches that fix what we need fixed. Viro is worse than useless to us (or anyone else), and cannot be salvaged, so help Alexei fix knfsd and save the effort. Hans
Re: fs changes in 2.3
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
> On Mon, May 01, 2000 at 06:25:43PM +0200, Peter Schneider-Kamp wrote:
> > I second that. I had to stop maintaining the steganographic file
> > system around 2.3.7 because I did not have that much time to
> > find out where my fs is "broken" and needs to be "fixed".
>
> FYI, the changes which broke filesystems in 2.3.8 were page cache /
> buffer cache changes and as such were VM changes, not VFS. They were
> a major change that was required to make Linux more scalable.
Ideally, developing file systems would involve only the VFS. In practice,
in involves the VM as well. I've worked on stacking interfaces for several
different OSs, and as much as they all want the VFS and VM to be two
completely separate entities, in practice they are not. About half of the
effort I spent on my stacking templates was related to the VM and changes to
the VM (linux/mm/*.c). IOW, most people who maintain file systems must
track changes in both the VFS and the VM.
That said, I'm quite pleased with the changes that happened in late 2.3.40s:
breaking some into address_space ops and more. IMHO the separation b/t the
VFS and the VM became more clear then, and it allowed me to cleanup my
stacking code quite nicely, as well as make easy use of vfs_ calls,
generic_file_{read,write}, and more.
Erez.
Re: fs changes in 2.3
On Mon, 1 May 2000, Hans Reiser wrote: > Ok, let me put it in different lingo. Viro is a fucking asshole who makes life > miserable for people trying to add functionality to Linux. What's more, he has > no imagination and his contributions do not begin to make up for the shit he > gives people like Gooch who is trying to add something that wasn't in System 7 > and is therefor beyond Viro's ability to cope with. It takes more than a > license to make source code open. He shouldn't be let near the source code, his > existence is a net loss for Linux. I don't think that is true. I have no idea what Viro is like as a person but however much I dislike his jargon/swearing (especially in the source code!) one must admit that technically he was only saying the right stuff and the only "frustration" I ever encountered is that even to beging to understand what he is talking about I need to re-read the source code at least 3 times. Just my two p. Regards, Tigran.
Re: fs changes in 2.3
On Sun, Apr 30, 2000 at 10:09:45PM -0700, Hans Reiser wrote: > I think that improving support from folks who change VFS code for folks who > are affected is needed. It's not just VFS that has this issue. It is a general philosophy that kernelspace APIs can change in unstable versions; drivers in the tree get fixed-up by the person making the change, but externally maintained drivers can only be updated by their maintainers. In an ideal world there would be "formal" documentation of the changes, but it doesn't happen. Mailing list archives are pretty useful though, and linux-fsdevel has low enough traffic that searching the archives for changes isn't too difficult. > I don't much care for the screaming at people who don't track your changes by ?? > reading ext2 code updates > development model that is currently in place. (E.g. the amiga FS emails seen > on this list) I agree that "screaming" as such probably isn't useful, but OTOH you can't develop any code module and expect to be able to "close it off" - the world changes :) Also, it works both ways -- if filesystem authors don't read the mailing list, they can't influence the changes in a way which suits them. > Perhaps a set of comments in the VFS code saying here is what you do to > interface with me would be better. Alan Cox and others have come up with a "kernel-doc" system for commenting API functions, and some of the VFS source files are already using this (fs/inode.c and fs/dcache.c, for example). This isn't the ultimate solution - we need structure documentation and "overview" documentation too, but with a standard format and location for such documentation, people might be more inclined to write it :-) [..] > VFS code needs to be maintained by persons with supportive personalities. I don't think the lack of documentation is anything to do with the maintainers' personalities, it's more likely to be due to lack of time. I'm sure you would have no difficulty getting a patch to add Documentation/DocBook/vfs.tmpl into the kernel :-) In the meantime, it might be worth collecting the various announcements that have been posted to linux-fsdevel about 2.3 VFS changes, and adding them to the Documentation directory..
Re: fs changes in 2.3
On Tue, May 02, 2000 at 09:32:24AM -0700, Chris Mason wrote: > On Tue, 2 May 2000, Hans Reiser wrote: > > He surely hasn't fixed the nfs problem for us either now has he? > Al Viro has zero obligation to fix anything for us, especially since we > aren't in the kernel, and the NFS features that need fixing work just > fine with the filesystems that are. Which NFS issue is this? Is it related to the unique inode identifier problem?
RE: fs changes in 2.3
Hi, As a lurker here (just to see if/when fs changes affect USB), Chris is correct here. IMO Hans was on the right track before he began flaming. I no longer have that email, but it was something about documenting changes for other fs developers, making it easier on us/them. The thing to do is one of the things that Linus does best IMO, which is to lead by example. Show us the code, or in this case, show us the docs. Or maybe I misunderstood Hans and read what I think would be a good step for the reiserfs team. Oh yeah, I believe he said _after_ 2.4 is out, but that's understandable. ~Randy #include > -Original Message- > From: Chris Mason [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 02, 2000 8:43 AM > To: Hans Reiser > Cc: Roman V. Shaposhnick; Steve Dodd; Ani Joshi; > [EMAIL PROTECTED] > Subject: Re: fs changes in 2.3 > > On Mon, 1 May 2000, Hans Reiser wrote: > > > "Roman V. Shaposhnick" wrote: > > > > > Hans, I do not want to be unpleasant, but you behave > like an second level > > > manager who can not get to the first level for quite a long time. > > > > Ok, let me put it in different lingo. > > [senseless flame] > > Hans, what are you doing? Is your real objective here to > ruin any chance > of working well with Al Viro? Suck it up, we are the new kids on the > block, and its our job to play nice with the existing kernel > developers. > If you can't do that, go home now. > > Al had legitimate gripes without first patch. He helped us fix the > problems, read the code, and sent advice. I wasn't wild about his > presentation style, but you don't have to read many l-k posts > to see that > he treated us the same as everyone else. I got over it, you > need to as > well. > > -chris
Re: fs changes in 2.3
On Tue, 2 May 2000, Steve Dodd wrote: > On Tue, May 02, 2000 at 09:32:24AM -0700, Chris Mason wrote: > > On Tue, 2 May 2000, Hans Reiser wrote: > > > > He surely hasn't fixed the nfs problem for us either now has he? > > > Al Viro has zero obligation to fix anything for us, especially since we > > aren't in the kernel, and the NFS features that need fixing work just > > fine with the filesystems that are. > > Which NFS issue is this? Is it related to the unique inode identifier > problem? > ReiserFS has unique inode numbers, but they aren't enough to actually find the inode on disk. That requires the inode number, and another 32 bits of information we call the packing locality. The packing locality starts as the parent directory inode number, but does not change across renames. So, we need to add a fh_to_dentry lookup operation for knfsd to use, and perhaps a dentry_to_fh operation as well (but _fh_update in pre6 looks ok for us). -chris
Re: fs changes in 2.3
On Tue, 2 May 2000, Hans Reiser wrote: > Yes, he is an asshole to everyone not at redhat, we have agreement on that. Liar. I'm an asshole to those who in my opinion deserve it. Doesn't correlate with employment - _very_ easy to prove. Besides, opinion about you (OK, technical parts of it - my opinion about your charming PHB personality is a separate story) had been stated in public _way_ before any interactions with redhat, so feel free to drop your conspiracy theories. Since we got into the season of frankness, let me point out that my deepest disrespect to you has nothing to my opinion of reiserfs code. I have no problems with people who actually wrote it. The fact that they got a slimeball as a business manager has nothing with the technical side of story. I find the fact that you claim credit for others' work and especially the way you do it disgusting at extreme, but it doesn't make said work worse. IMO you are... well, I'm not sure which word would express it adequately in English. In Russian it would be "mraz'". > He had absolutely no intention of being helpful to us, you can tell from his > emails that his objective was to maximize the noise and minimize the assistance > by being as unspecific as possible. He didn't give a damn about helping us to > fix bugs, he wrote his emails solely for the objective of keeping us from > competing with ext3 in 2.4. Actually, if you read what he posts on I hate to piss on your parade, but... ext3 is not even submitted and from all SCT ever said it looks like he doesn't plan it for 2.4. Care to do reality checks from time to time? I don't know what drugs you are taking to achieve telepathy, but they obviously (a) do not work and (b) have nasty side effects. [snip the rest of idiocy] ObNFS: weird as it may sound to you, I actually write stuff - not "subcontract" to somebody else. So I'm afraid that I have slightly less free time than you do. FWIC, in Reiserfs context nfsd is a non-issue. Current kludge is not too lovely, but it's well-isolated and can be replaced fast. So ->read_inode2() is ugly, but in my opinion it's not an obstacle. If other problems will be resolved and by that time ->fh_to_dentry() interface will not be in place - count on my vote for temporary adding ->read_inode2().
Re: fs changes in 2.3
On Tue, 2 May 2000, Chris Mason wrote: > So the reiserfs team has to fix a problem NFS only has when interacting > with reiserfs. Yes, it would have been nice if someone else had the > chance to do it for us, but to expect them to, and to be mad when > they don't, is more than a little silly. Its time to move on Hans, we > have more important things to worry about. Sigh... Folks, if the knfsd problem is the only one left - you have my vote for temporary inclusion of the *@!#^* ->read_inode2(). AFAICS it's the least of anyone's problems. It can be fixed, fix is not going to be reiserfs-dependent and is unlikely to require additional code in reiserfs. IWBNI Hans would understand the code in fs/reiserfs/* and existing problems with it, but frankly, I don't see how it really matters. As for the "cooperation" bit - huh? What, Hans can contribute something to discussing the technical side of things? Then he was successfully hiding that fact for years. I definitely have no problems with the rest of your team and my problems with Hans... let's keep them separate, OK? I'll start getting worry about that when I'll see a single technical posting from Hans that would not consist of forwarding most of the questions to other people.
Re: fs changes in 2.3
On Wed, May 03, 2000 at 08:54:54AM +0200, Alexander Viro wrote: [flame snipped -- hopefully everybody can go back to normal work now] > > ObNFS: weird as it may sound to you, I actually write stuff - not > "subcontract" to somebody else. So I'm afraid that I have slightly less > free time than you do. FWIC, in Reiserfs context nfsd is a non-issue. > Current kludge is not too lovely, but it's well-isolated and can be > replaced fast. So ->read_inode2() is ugly, but in my opinion it's not an > obstacle. If other problems will be resolved and by that time > ->fh_to_dentry() interface will not be in place - count on my vote for > temporary adding ->read_inode2(). In the long run some generic support for 64bit inodes will be needed anyways -- other file systems depend on that too (e.g. XFS). So fh_to_dentry only saves you temporarily. I think adding read_inode2 early is the best. -Andi
Re: fs changes in 2.3
On Wed, 3 May 2000, Andi Kleen wrote: > On Wed, May 03, 2000 at 08:54:54AM +0200, Alexander Viro wrote: > > > > ObNFS: weird as it may sound to you, I actually write stuff - not > > "subcontract" to somebody else. So I'm afraid that I have slightly less > > free time than you do. FWIC, in Reiserfs context nfsd is a non-issue. > > Current kludge is not too lovely, but it's well-isolated and can be > > replaced fast. So ->read_inode2() is ugly, but in my opinion it's not an > > obstacle. If other problems will be resolved and by that time > > ->fh_to_dentry() interface will not be in place - count on my vote for > > temporary adding ->read_inode2(). > > In the long run some generic support for 64bit inodes will be needed > anyways -- other file systems depend on that too (e.g. XFS). So > fh_to_dentry only saves you temporarily. I think adding read_inode2 > early is the best. > The problem is the read_inode2 callers need to know what to send, so we need the opaque inode label idea, and an easy way to pass it around. Or, we can just decide 64 bits is enough, and add a 64 bit inode number into struct inode, keeping the 32 bit one for compatibility. -chris
Re: fs changes in 2.3
"Dunlap, Randy" wrote: > The thing to do is one of the things that Linus does > best IMO, which is to lead by example. Show us the > code, or in this case, show us the docs. I am not sure you heard what I said precisely. I am saying to my programmers "code not suck", and then saying Viro is worse than useless, and sucking hasn't gotten Chris NFS fixes, so that is even more reason to code not suck. Andi Kleen found a race condition for us, and told us where it was. Andi is cool. Viro found unecessary checks in our code, and then made it sound like something big. He does this kind of thing a lot to everyone. He discourages every contributor he can for the betterment of his ego. He is damage in the Linux community to route around. Hans
Re: fs changes in 2.3
Hans Reiser wrote: > Andi Kleen found a race condition for us, and told us where it was. Andi is > cool. Viro found unecessary checks in our code, and then made it sound like > something big. He does this kind of thing a lot to everyone. He discourages > every contributor he can for the betterment of his ego. He is damage in the > Linux community to route around. Here's a lesson in life: if you don't want to deal with somebody, don't deal with them. Al Viro isn't the only one allowed to contribute VFS patches. Jeff -- Jeff Garzik | Nothing cures insomnia like the Building 1024| realization that it's time to get up. MandrakeSoft, Inc. |-- random fortune
Re: fs changes in 2.3
Alexander Viro wrote: >I > have no problems with people who actually wrote it. The fact that they got > a slimeball as a business manager has nothing with the technical side of > story. I find the fact that you claim credit for others' work and > especially the way you do it disgusting at extreme, but it doesn't make > said work worse. Viro, throughout the whole initial development of ReiserFS I spent 15-20 hours a week arguing over every algorithm we used (and then I worked 40 hours a week earning the salary that paid everyone in russia working for me). I didn't always get every algorithm done my way, and half the time my way was the wrong way, and surely I learned, and surely I was completely unqualified (we all were), but if you think I played no technical role in the design of reiserfs you couldn't be more wrong. The idea to do the filesystem was mine. The idea to aggregate small files was mine. The idea to use B+trees rather than B-trees was mine, and was shoved down someone's protesting throat by me. Going on farther would be silly. We ALL threw every idea we had into the debate, so the list of ideas that weren't mine is also long. The guys who left left in part because Vladimir outcoded them all, and I told the head of the research center that if he didn't work as hard as Vladimir he wasn't going to get paid as much. You should understand that Vladimir was the most junior member of the research team, and this was a PhD who thought a PhD was something really impressive. That wasn't the major reason though. The larger part of it was that he wanted me to accept his algorithms and I told him that he would use mine or not get paid. It really bothered him to work under the direction of an American with no PhD who wanted to do all these things that weren't in any textbook and were surely wrong therefor. Hee Hee. It still makes me smile. If it concerns you that I don't credit them by name, I guess you weren't listening on the phone when their swedish VC backer who wanted me to sell ReiserFS to them and who was in the protective services business here in Russia, suggested they might hire a hundred researchers to swear in Russian Court that I had no role in creating the filesystem. That was the day the name changed from treefs. You certainly weren't there when they tried to make it very difficult for me to continue ReiserFS without selling it to them by forbidding Vladimir to help me on weekends with commenting their execrable code to the point that I could find the bugs. (He told them he'd leave the job they gave him in America and go back to Russia. They gave in, but eventually he went back to Russia anyway, to work on our project.) I really don't think that persons who leave a project and then do all in their power to choke it out of existence deserve any credit at all. In V4 all of their remaining code will be tossed, we have been getting rid of it in pieces, but it is time to rip the heart out of it. By the way, the swedish protective services guy then proceeded to lose all of the money of the Russian investors backing him (they were vodka factory and casino money). I think the major part of the money ($1 million if I remember right) went to some guys in the secret police who claimed to have an algorithm proving that P=NP, but would not disclose the algorithm because it was so valuable it needed to be kept secret. Said PhD working for me, who had some specialization in this area, did a formal evaluation, and encouraged the investment by the investor. I still wonder if some money went to him to help shape his opinion, but I'll never really know this. In sum, ReiserFS would have been completed faster if I had never met them. Debugging and tweaking their code rather than scrapping it and recoding by myself was a serious mistake of mine. It was one bug away from working for a very long time, and the performance was deeply depressing for a long time. Fortunately the thing that really affected performance was block allocation policy, and that was Vladimir's code so it was extremely easy to work with. The only good thing that came out of that experience was meeting Vladimir. That's a pretty damn good thing though, and maybe that alone was worth all of it. Hans PS I don't think any of the people I see you flame are guilty of doing anything more than trying to contribute to Linux. You could surely tell them what their bugs are without discouraging them from making more contributions in that manner that you do. Think about that. I hope this thread dies soon though.
Re: fs changes in 2.3
On Mon, May 01, 2000 at 06:25:43PM +0200, Peter Schneider-Kamp wrote: > I second that. I had to stop maintaining the steganographic file > system around 2.3.7 because I did not have that much time to > find out where my fs is "broken" and needs to be "fixed". FYI, the changes which broke filesystems in 2.3.8 were page cache / buffer cache changes and as such were VM changes, not VFS. They were a major change that was required to make Linux more scalable.
