Messages in this thread | | | Date | Sun, 12 Mar 2000 21:17:42 +0300 | From | Hans Reiser <> | Subject | Re: patch: reiserfs for 2.3.49 |
| |
The only intrusive VFS change is the one below, and we are more than happy to have it be solved in other ways, tell us and we shall follow.
The change is architected to minimize intrusion upon other filesystems and VFS. We understand that you have more sweeping changes to fix this in your plans, and we encourage you all the way. This fix is, I think, quite reasonable for the short term, and easily discarded later. Any other fix we will eagerly use the moment it is available.
I understand you are upset that we have not closely tracked your recent code and learned from its example. We will learn from your instruction, and thank you for it. The guys in Russia are beginning to wake up now, and I am forwarding your email to them. I think we can address the points you raised with specificity by 8am California time.
I say this because it seems that our 2.3.51 port is now stable, we fixed several bugs this weekend, and I am quite pleased by how our team came together for it. Thanks to your points we will now also be able to increase our speed by several thousandths of a percent.
By the way, I have heard a rumor that RedHat is going to bundle VxFS as a proprietary kernel module. Is this true? Does RedHat envision VxFS becoming a defacto industry standard if there are no journaling file system in 2.4, and it bundles VxFS onto its CDs? Do you have access to the source code for VxFS personally, perhaps under NDA? I imagine it will be quite interesting if major kernel functionality starts going into closed source kernel modules. I think none of us really believed that anything of consequence would ever go into a closed source kernel module back when the issue first came up. The social consequences of some folks having source code access, and others being excluded, if one of these kernel modules were to ever become the defacto standard for some key piece of the kernel, quite interesting I would say. I look forward to benchmarking versus the RedHat/Veritas VxFS modules when 2.4 comes out, it will be interesting to see if the open approach is robust in more than theory in my obscure niche of CS. If the rumor is untrue, I apologize, and I offer RedHat this opportunity to make clear that a rumor you may not have heard is making the rounds is as false as we would all hope it is.
Hans
Andrea Arcangeli wrote: > > On Sun, 12 Mar 2000, Alexander Viro wrote: > > > [..] IMNSHO reiserfs in the official tree right now is the worst > >thing one can do to VFS. [..] > > The _only_ VFS change involved in the 2.3.x reiserfs port is this: > > - sb->s_op->read_inode(inode); > + > + /* reiserfs specific hack right here. We don't > + ** want this to last, and are looking for VFS changes > + ** that will allow us to get rid of it. > + ** -- mason@suse.com > + */ > + if (sb->s_op->read_inode2) { > + sb->s_op->read_inode2(inode, opaque) ; > + } else { > + sb->s_op->read_inode(inode); > + } > [..] > @@ -694,6 +698,14 @@ > */ > struct super_operations { > void (*read_inode) (struct inode *); > + > + /* reiserfs kludge. reiserfs needs 64 bits of information to > + ** find an inode. We are using the read_inode2 call to get > + ** that information. We don't like this, and are waiting on some > + ** VFS changes for the real solution. > + ** iget4 calls read_inode2, iff it is defined > + */ > + void (*read_inode2) (struct inode *, void *) ; > void (*write_inode) (struct inode *); > void (*put_inode) (struct inode *); > void (*delete_inode) (struct inode *); > > That's not nice indeed but it's also obviously safe and non very > intrusive. It's definitely _not_ the "worst thing one can do to the VFS" > IMHO :). > > Andrea
-- You can get ReiserFS at http://devlinux.org/namesys, and customizations and industrial grade support at reiser@idiom.com.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |