Andi Kleen wrote:
>
> On Tue, Jun 06, 2000 at 12:11:08AM -0700, Hans Reiser wrote:
> > I want to add reiserfs to linux, not merge it into ext3. This is the crux of
> > the argument. Alan says I should wait until ext3 is added so that I can let
> > them write part of our FS for us.
>
> I actually didn't read it as that. He wrote that it needs checking
> what parts of the journaling code can use common hooks.
Expressed this way I of course agree that it should be done. I don't see why it
should cause reiserfs integration to be delayed though. ReiserFS is easy to
rewrite.:-) I don't see what the problem is with minorly rewriting reiserfs in
2.5 to match whatever API changes are called for. I also hope that we will
contribute some of them. zam is right now working on memory pressure hooks, and
they are intended to be general hooks that we hope the rest of the kernel folks
will like once we have a patch working to submit.
If you say evolve toward a common journaling operations VFS API in 2.5, I nod my
head. If you say delay reiserfs for that API to be defined, I ask why? Define
it and we'll change reiserfs! It is not like we aren't used to changing
reiserfs extensively every year to deal with VFS changes.:-/
>
> Examples where common hooks are needed:
> - A path to signal memory pressure to the journal to make it flush its
> transaction data (currently there are deadlock situations which are neither
> solved in ext3 nor reiser)
>
> - A common solution for the deadlock of nesting journal traffic on
> page cleaning (Chris' dirty_inode hook, I'm not sure how Stephen
> solves the problem)
>
> - Use a common layer for the write barriers [but Linus seems to prefer
> handling them in the fs/journal code anyways]
>
> - There are probably other ``common problems''
>
> There are lots of stuff that can be done to give a common interface
> to journal subsystems, without merging them completely. Of course having
> a common internal journal API would make sense anyways. It is e.g.
> badly needed for writeable snapshots in LVM or reliable Software Raid --
> for performance reasons Block Devices and File systems should write to
> the same journal. There are other services that could benefit too,
> like log failover from nfs servers that share a single disk in case
> of a crash. Maybe a kind of ``VFS for journal services'' makes sense
> for this?
>
> I don't think it will end up with your fears of ext3 ``eating reiserfs''
>
> -Andi
-
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/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:24 EST