The future of Reiser4 was raised on the lkml, with the filesystem's creator, Hans Reiser [interview], awaiting his May 7'th trial [story]. Concerns that the filesystem wasn't being maintained were laid to rest when Andrew Morton [interview] stated, "the namesys engineers continue to maintain reiser4 and I continue to receive patches for it." He further added, "the namesys guys are responsive and play well with others." As to why the filesystem hasn't yet been merged into the 2.6 kernel, Andrew explained, "to get it unstuck we'd need a general push, get people looking at and testing the code, get the vendors to have a serious think about it, etc. We could do that - it'd require that the namesys people (and I) start making threatening noises about merging it, I guess." He then made joking reference to the recent debate regarding the new CPU schedulers [story], "or we could move all the reiser4 code into kernel/sched.c - that seems to get people fired up."

Namesys developer and author of the Reiser4 encryption and compression plugins, Edward Shiskin, offered some updates. Replying to some comments about the need to remove plugins from the Reiser4 code he explained, "the popular opinion that plugins make more sense in the VFS is a great delusion, as plugins are entities related to reiser4 disk layouts." In an earlier thread it had been suggested that the plugins were misnamed and would be better called an internal abstraction layer [story]. Edward went on to note, "currently there are two namesys employees working [on Reiser4] mostly on enthusiasm." He linked to a wiki page listing known issues with the code needing to be fixed before it's likely to be merged into the 2.6 kernel, "the main issues here are xattrs and support for blocksize != pagesize. I think that adding xattrs will take ~1 month of full-time working. Not sure about blocksize support." When it was noted that other filesystems have already been merged without support for either of these features, Edward said that they'd lower their priority and finish up with the other remaining issues left on the old todo list and resume the merge discussion at that time.

From: Eric Hopper [email blocked]
To:  linux-kernel
Subject: Question about Reiser4
Date:	Sun, 22 Apr 2007 19:00:46 -0700

I know that this whole effort has been put in disarray by the
prosecution of Hans Reiser, but I'm curious as to its status.  Is
Reiser4 going to be going into the Linus kernel anytime soon?  Is there
somewhere I should be looking to find this out without wasting bandwidth
here?

I'm not an LKML subscriber.

Thanks,
-- 
Eric Hopper (http://www.omnifarious.org/~hopper/)



From: Rik van Riel [email blocked]
Subject: Re: Question about Reiser4
Date:	Sun, 22 Apr 2007 23:56:11 -0400

Eric Hopper wrote:
> I know that this whole effort has been put in disarray by the
> prosecution of Hans Reiser, but I'm curious as to its status. 

It was in disarray well before.  Many of the reiser4 features,
like filesystem plugins, make more technical sense in the Linux
VFS, but made more business sense for Namesys as a reiserfs 4
thing.  That lead to a stalemate.

 > Is Reiser4 going to be going into the Linus kernel anytime soon?

I wouldn't count on it.



From: William Heimbigner [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 03:56:00 +0000 (GMT)

> Eric Hopper wrote:
>>  I know that this whole effort has been put in disarray by the
>>  prosecution of Hans Reiser, but I'm curious as to its status. 
>
> It was in disarray well before.  Many of the reiser4 features,
> like filesystem plugins, make more technical sense in the Linux
> VFS, but made more business sense for Namesys as a reiserfs 4
> thing.  That lead to a stalemate.
>
Shouldn't it be a matter of stability though? Benchmarks suggest that 
reiser4 is a good file system; reiser4 is the successor to the 
already-accepted reiserfs; we've got experimental ext4 support but no 
reiser4 support, etc.

I don't see why something like plugins should matter. If it works enough 
to be marked as experimental, why shouldn't reiser4 support be included?
It's a pain for me personally to have to patch any kernel with reiser4 
support so I can use the reiser4 fs.

William Heimbigner
[email blocked]



From: Rik van Riel [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 01:47:04 -0400

William Heimbigner wrote:
>> Eric Hopper wrote:
>>>  I know that this whole effort has been put in disarray by the
>>>  prosecution of Hans Reiser, but I'm curious as to its status. 
>>
>> It was in disarray well before.  Many of the reiser4 features,
>> like filesystem plugins, make more technical sense in the Linux
>> VFS, but made more business sense for Namesys as a reiserfs 4
>> thing.  That lead to a stalemate.
>>
> Shouldn't it be a matter of stability though? 

A lot of other things matter.  Things like a willingness to
maintain the code after it gets merged, or at least turning
the code into something the community is willing to maintain
if the original developers stop maintaining it.

> Benchmarks suggest that 
> reiser4 is a good file system; reiser4 is the successor to the 
> already-accepted reiserfs; we've got experimental ext4 support but no 
> reiser4 support, etc.

Namesys kind of abandoned reiserfs after work on reiser4
started.  Taking in a new code base on such a track record
is not a good idea when the code is not in a shape where
the community wants to maintain it.

> I don't see why something like plugins should matter. If it works enough 
> to be marked as experimental, why shouldn't reiser4 support be included?
> It's a pain for me personally to have to patch any kernel with reiser4 
> support so I can use the reiser4 fs.

You basically have three options:

1) keep patching every time you upgrade the kernel

2) use another filesystem

3) become the new reiser4 maintainer and turn the code
    into something that Linus is willing to accept

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.



From: William Heimbigner [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 05:57:53 +0000 (GMT)

> William Heimbigner wrote:
>> >  Eric Hopper wrote:
>> > >   I know that this whole effort has been put in disarray by the
>> > >   prosecution of Hans Reiser, but I'm curious as to its status. 
>> > 
>> >  It was in disarray well before.  Many of the reiser4 features,
>> >  like filesystem plugins, make more technical sense in the Linux
>> >  VFS, but made more business sense for Namesys as a reiserfs 4
>> >  thing.  That lead to a stalemate.
>> >
>>  Shouldn't it be a matter of stability though? 
>
> A lot of other things matter.  Things like a willingness to
> maintain the code after it gets merged, or at least turning
> the code into something the community is willing to maintain
> if the original developers stop maintaining it.
>
>>  Benchmarks suggest that reiser4 is a good file system; reiser4 is the
>>  successor to the already-accepted reiserfs; we've got experimental ext4
>>  support but no reiser4 support, etc.
>
> Namesys kind of abandoned reiserfs after work on reiser4
> started.  Taking in a new code base on such a track record
> is not a good idea when the code is not in a shape where
> the community wants to maintain it.
>
>>  I don't see why something like plugins should matter. If it works enough
>>  to be marked as experimental, why shouldn't reiser4 support be included?
>>  It's a pain for me personally to have to patch any kernel with reiser4
>>  support so I can use the reiser4 fs.
>
> You basically have three options:
>
> 1) keep patching every time you upgrade the kernel
>
> 2) use another filesystem
>
> 3) become the new reiser4 maintainer and turn the code
>    into something that Linus is willing to accept

I suppose. I have a feeling there's an underlying issue behind "code 
standards" (and even then, I think that code standards is ultimately an 
excuse for not integrating reiser4 support into the kernel, but that's 
just my opinion). However, is the code really in such a shape that the 
community doesn't want to maintain it? Obviously there's a significant 
number of people interested in reiser4 - if there weren't, questions like 
this wouldn't keep getting asked.

William Heimbigner
[email blocked]



From: Rik van Riel [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 02:07:46 -0400

William Heimbigner wrote:

> However, is the code really in such a shape that the 
> community doesn't want to maintain it? Obviously there's a significant 
> number of people interested in reiser4 - if there weren't, questions 
> like this wouldn't keep getting asked.

There are people interested in using it, yes.

However, nobody appears to have stepped up to maintain the code.
If somebody really wanted to maintain the code, there would be a
new maintainer already.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.



From: William Heimbigner [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 06:14:04 +0000 (GMT)

On Mon, 23 Apr 2007, Rik van Riel wrote:
> William Heimbigner wrote:
>
>>  However, is the code really in such a shape that the community doesn't
>>  want to maintain it? Obviously there's a significant number of people
>>  interested in reiser4 - if there weren't, questions like this wouldn't
>>  keep getting asked.
>
> There are people interested in using it, yes.
>
> However, nobody appears to have stepped up to maintain the code.
> If somebody really wanted to maintain the code, there would be a
> new maintainer already.

On that note, what exactly is wanted for (assuming there was a maintainer) 
reiser4 to be suitable for inclusion in the kernel? To my knowledge (and 
I'll admit, I haven't looked in to it very far) the primary reason for 
rejection was that it broke coding standards.

If there was 1) a maintainer and 2) code that didn't break "coding 
standards", would it be included in the kernel?

William Heimbigner
[email blocked]



From: Rik van Riel [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 02:20:36 -0400

William Heimbigner wrote:

> If there was 1) a maintainer and 2) code that didn't break "coding 
> standards", would it be included in the kernel?

While I cannot speak for Linus and Andrew, code that fulfills
these criteria (and is useful to have - reiser4 seems to have
enough user interest) usually gets accepted.

http://kernelnewbies.org/UpstreamMerge has some hints.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.



From: William Heimbigner [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 06:42:24 +0000 (GMT)


On Mon, 23 Apr 2007, Rik van Riel wrote:
> William Heimbigner wrote:
>
>>  If there was 1) a maintainer and 2) code that didn't break "coding
>>  standards", would it be included in the kernel?
>
> While I cannot speak for Linus and Andrew, code that fulfills
> these criteria (and is useful to have - reiser4 seems to have
> enough user interest) usually gets accepted.
>
> http://kernelnewbies.org/UpstreamMerge has some hints.

So in conclusion / to answer Eric's question,
1) reiser4 needs a maintainer
2) reiser4 needs the code quality cleaned up
3) Until those two things happen, it's extremely unlikely that it will be 
included in the kernel.

Correct?
William Heimbigner
[email blocked]



From: Andrew Morton [email  blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 01:04:45 -0700

On Mon, 23 Apr 2007 06:42:24 +0000 (GMT) William Heimbigner [email blocked] wrote:

> 
> On Mon, 23 Apr 2007, Rik van Riel wrote:
> > William Heimbigner wrote:
> >
> >>  If there was 1) a maintainer and 2) code that didn't break "coding
> >>  standards", would it be included in the kernel?
> >
> > While I cannot speak for Linus and Andrew, code that fulfills
> > these criteria (and is useful to have - reiser4 seems to have
> > enough user interest) usually gets accepted.
> >
> > http://kernelnewbies.org/UpstreamMerge has some hints.
> 
> So in conclusion / to answer Eric's question,
> 1) reiser4 needs a maintainer
> 2) reiser4 needs the code quality cleaned up
> 3) Until those two things happen, it's extremely unlikely that it will be 
> included in the kernel.
> 

The namesys engineers continue to maintain reiser4 and I continue to
receive patches for it.

Right now I'd say that the main blockages for reiser4 are a) the developers
aren't presently asking for inclusion (afaik) and b) lack of reviewing
effort from other kernel developers.  



From: Eric Hopper [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 06:52:16 -0700

On Mon, Apr 23, 2007 at 01:04:45AM -0700, Andrew Morton wrote:
> The namesys engineers continue to maintain reiser4 and I continue to
> receive patches for it.
> 
> Right now I'd say that the main blockages for reiser4 are a) the developers
> aren't presently asking for inclusion (afaik) and b) lack of reviewing
> effort from other kernel developers.  

If someone else started asking for it to be included and responded to
requests for the various code changes required to increase its quality
to the required level, wouldn't that be enough?  Basically, if someone
forked it.

Or does it specifically have to be namesys engineers?

Oh, two things really interest me about Reiser4.  First, I despise
having to care about how many tiny files I leave lying around when
writing a program.  Berkeley DB and its ilk are evil, evil programs that
obscure data and make things harder.  Secondly, the moves Reiser4 has
made towards having actual transactions at the filesystem level also
intrigue me.

I want to use the filesystem as a DB.  IMHO, there is no reason that
filesystems shouldn't be a DB sans query language.  If there were a more
DB-like way to deal with filesystems, I think that it would be that much
easier to make something that was a decent replacement for NFS and
actually worked.

Sadly, unless someone pays me to maintain it, I can't do the fork
myself, and I likely wouldn't anyway as being a kernel hacker of
something as important as a filesystem is a full-time job and I have
other things that interest me a lot more.

Just curious,
-- 
Eric Hopper (http://www.omnifarious.org/~hopper/)



From: Andrew Morton [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 10:40:42 -0700

On Mon, 23 Apr 2007 06:52:16 -0700
Eric Hopper [email blocked] wrote:

> On Mon, Apr 23, 2007 at 01:04:45AM -0700, Andrew Morton wrote:
> > The namesys engineers continue to maintain reiser4 and I continue to
> > receive patches for it.
> > 
> > Right now I'd say that the main blockages for reiser4 are a) the developers
> > aren't presently asking for inclusion (afaik) and b) lack of reviewing
> > effort from other kernel developers.  
> 
> If someone else started asking for it to be included and responded to
> requests for the various code changes required to increase its quality
> to the required level, wouldn't that be enough?  Basically, if someone
> forked it.
> 
> Or does it specifically have to be namesys engineers?

That's not where the problem lies - the namesys guys are responsive and play
well with others.  But they haven't received any "requests for the various code
changes" in over a year.

And I'm in the same boat as most everyone else: I haven't looked at the reiser4
code in ages.  Right now I don't have anything like a list of outstanding
technical issues.

To get it unstuck we'd need a general push, get people looking at and testing
the code, get the vendors to have a serious think about it, etc.  We could do
that - it'd require that the namesys people (and I) start making threatening
noises about merging it, I guess.

Or we could move all the reiser4 code into kernel/sched.c - that seems to get
people fired up.



From: Theodore Tso [email blocked]
Subject: Re: Question about Reiser4
Date:	Mon, 23 Apr 2007 18:56:41 -0400

On Mon, Apr 23, 2007 at 06:52:16AM -0700, Eric Hopper wrote:
> Oh, two things really interest me about Reiser4.  First, I despise
> having to care about how many tiny files I leave lying around when
> writing a program.  Berkeley DB and its ilk are evil, evil programs that
> obscure data and make things harder.  Secondly, the moves Reiser4 has
> made towards having actual transactions at the filesystem level also
> intrigue me.
> 
> I want to use the filesystem as a DB.  IMHO, there is no reason that
> filesystems shouldn't be a DB sans query language.  If there were a more
> DB-like way to deal with filesystems, I think that it would be that much
> easier to make something that was a decent replacement for NFS and
> actually worked.

One of the big problems of using a filesystem as a DB is the system
call overheads.  If you use huge numbers of tiny files, then each
attempt read an atom of information from the DB takes three system
calls --- an open(), read(), and close(), with all of the overheads in
terms of dentry and inode cache.

Hans of course had a solution to this problem --- namely the
sys_reiser4 system call, where you download a program to the kernel to
execute a open/read/close via a single system call, and which returns
the combined results to userspace.  But now you have more complexity
since there is now a reseir4-specific interpreter embeddeed in the
kernel, the userspace application needs to write the equivalent of an
channel program such as what was found in an IBM/360 mainframe (need I
mention this can be a rich source of security bugs), and then the
userspace application *still* needs to parse the result returned by
the sys_reiser4() system call?

So it adds a huge amount of complexity, and at the end of the day,
given that you don't have the search capability, it is (a) less
functional, (b) more complexitated, and (c) probably less performant
than simply calling out to a database.

> Sadly, unless someone pays me to maintain it, I can't do the fork
> myself, and I likely wouldn't anyway as being a kernel hacker of
> something as important as a filesystem is a full-time job and I have
> other things that interest me a lot more.

Unfortunately, the way OSS works is that you either (a) have to do the
work yourself, (b) convince someone else to do the work, or (c)
convince someone that it's worth paying you to do it.

Personally, if I controlled large budget for Linux filesystem
development, I'd put a lot more money into something like Val's
chunkfs idea than resier4.  Being able to have filesystems designed
for fast recovery given disks getting larger and larger (but not more
reliable), is a whole lot more improtant than trying to create an
alternate solution to an already solved problem --- namely that of a
database.  When you consider that a similar idea, WinFS, was partially
responsible for delaying Vista by years due to the complexity of
shoving a database where it has no place being, it's another reason
why I personally think that chunkfs is a much more promising avenue
for future filesystem investment than reiserfs.

But hey, the advantage of Open Source is that if *you* want to work on
Reiser4, you're perfectly free to do so.  My personal opinion is that
it'd be a waste of your time, but you're free to spend your time
whichever way that you want.  What you don't get do is whine about how
other people get to spend *their* time, or *their* money.

						- Ted


From: Edward Shishkin [email blocked]
Subject: Re: Question about Reiser4
Date:	Tue, 24 Apr 2007 18:43:59 +0400

Hello everyone.

>Begin forwarded message:
>
>Date: 23 Apr 2007 21:05:13 +0200
>From: Andi Kleen [email blocked]
>Cc: Eric Hopper [email blocked], linux-kernel
>Subject: Re: Question about Reiser4
>
>
>Andrew Morton [email blocked] writes:
>  
>
>>To get it unstuck we'd need a general push, get people looking at and testing
>>the code, get the vendors to have a serious think about it, etc.  We could do
>>that - it'd require that the namesys people (and I) start making threatening
>>noises about merging it, I guess.
>>    
>>
>
>My impression was that a lot of negative discussion came out of some of the
>user interface inventions in r4 (like sys_reiser4 and the
>new incompatible EA interface). 
>
>  
>

sys_reiser4 and metas interface were removed (current -mm stuff
doesn't contain them).

>I guess a good strategy to get it going would be to extract just
>a "core reiser4" out of it that is just a file system without
>any new interfaces like this.
>
>  
>

I think that current reiser4 is exactly that "core", which responds solely
to VFS. The popular opinion that plugins make more sense in the VFS
is a great delusion, as plugins are entities related to reiser4 disk 
layouts.
There are many aspects where plugin architecture is useful, I tried to
describe one of them -- backward compatibility that was got with
minimal efforts: http://dev.namesys.com/Version4.X.Y
If this needs more comments, then we will proceed the documentation.

>I would expect that reviewing that would be much smoother
>because people could actually concentrate on the technical details.
>
>-Andi
>
>  
>

Other comments:

1. Why Namesys developers aren't presently asking for inclusion?

Because there are unaddressed items in this todo list:
http://pub.namesys.com/Reiser4/ToDo
The main issues here are xattrs and support for blocksize != pagesize.
I think that adding xattrs will take ~1 month of full-time working.
Not sure about blocksize support. Also, the statement about "main
issues" may be too optimistic. Let's try to estimate..

2. Who will maintain this?

Currently there are two namesys employees working mostly on
enthusiasm. Divide them into 2 file systems, plus many people who
really help with fixing problems.

So we need to estimate how dramatic the situation with reiser4 is
(experts are welcome). In the worst case (no funding for this in the
perspective) I hope to devote ~25% of my working time to this
project. Vladimir might want to add something here, but he is sick
for now. By the way, he has its own opinion what part of current
reiser4 should go to mainline (separating tail's support (which
makes things complicated) as special incremental update available
on our website).

Thanks,
Edward.



From: Andi Kleen [email blocked]
Subject: Re: Question about Reiser4
Date:	Tue, 24 Apr 2007 21:39:21 +0200

> Because there are unaddressed items in this todo list:
> http://pub.namesys.com/Reiser4/ToDo
> The main issues here are xattrs and support for blocksize != pagesize.

I would consider both to be optional. We have various file systems
in tree that don't support either (e.g. JFS only supports 4K blocks
and OCFS2 doesn't support xattr) They shouldn't block merging.

> 2. Who will maintain this?
> 
> Currently there are two namesys employees working mostly on
> enthusiasm. Divide them into 2 file systems, plus many people who
> really help with fixing problems.

Merging will probably be a peak of work for the necessary changes,
then hopefully the work will be less once you're in tree because
you don't need to track mainline anymore
(assuming not to many bugs come in from users) 

-Andi



From: Edward Shishkin [email blocked]
Subject: Re: Question about Reiser4
Date:	Wed, 25 Apr 2007 18:35:03 +0400

Andi Kleen wrote:

>>Because there are unaddressed items in this todo list:
>>http://pub.namesys.com/Reiser4/ToDo
>>The main issues here are xattrs and support for blocksize != pagesize.
>>    
>>
>
>I would consider both to be optional. We have various file systems
>in tree that don't support either (e.g. JFS only supports 4K blocks
>and OCFS2 doesn't support xattr) They shouldn't block merging.
>
>  
>

xattrs also were considered as some guarantee of vendor support.
If possible, then we'll address it as low-priority issue.
Maybe somebody will help.. (xattrs support should go as incremental
update of FPL-subversion for reiser4 kernel module and reiser4progs).

>>2. Who will maintain this?
>>
>>Currently there are two namesys employees working mostly on
>>enthusiasm. Divide them into 2 file systems, plus many people who
>>really help with fixing problems.
>>    
>>
>
>Merging will probably be a peak of work for the necessary changes,
>then hopefully the work will be less once you're in tree because
>you don't need to track mainline anymore
>(assuming not to many bugs come in from users) 
>
>-Andi
>  
>

Hope we survive this, at least such peaks is not something new in
our practice.

Well, gentlemen, so we'll address other items (except #26, 27) and
resume this discussion.

Thanks,
Edward.

• Archive of above thread
• KernelTrap interview with Rik van Riel
• KernelTrap interview with Andrew Morton