lkml.org 
[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.135 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site