Question about Reiser4

Question about Reiser4

[Eric Hopper]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

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/)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Question about Reiser4

[Lee Revell]

On 4/22/07, Eric Hopper <hopper@omnifarious.org> wrote:
> I'm not an LKML subscriber.
>

Did you try searching LKML archives?

Lee

Re: Question about Reiser4

[Rik van Riel]

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.

Re: Question about Reiser4

[William Heimbigner]

> 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
icxcnika@mar.tar.cc

Re: Question about Reiser4

[Rik van Riel]

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.

Re: Question about Reiser4

[William Heimbigner]

> 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
icxcnika@mar.tar.cc

Re: Question about Reiser4

[Rik van Riel]

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.

Re: Question about Reiser4

[William Heimbigner]

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
icxcnika@mar.tar.cc

Re: Question about Reiser4

[Rik van Riel]

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.

Re: Question about Reiser4

[William Heimbigner]

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
icxcnika@mar.tar.cc

Re: Question about Reiser4

[Andrew Morton]

On Mon, 23 Apr 2007 06:42:24 +0000 (GMT) William Heimbigner <icxcnika@mar.tar.cc> 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.  

Re: Question about Reiser4

[l.genoni]

Here is something I don't understand...
It seems there is a maintainer, namesys people, which is what I was 
supposing, and probably it is the most qualified one for reiser4,

but it also seems you imply that they are not interested right now in 
kernel inclusion, since they are not asking "in this moment" for it.

Do I misunderstand? To me it seems they are implicitally interested in 
kernel inclusion since they are maintaining the code, and they alredy 
asked for this.

regards

Luigi
On Mon, 23 Apr 2007, 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.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Question about Reiser4

[Eric Hopper]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

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/)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Question about Reiser4

[Andrew Morton]

On Mon, 23 Apr 2007 06:52:16 -0700
Eric Hopper <hopper@omnifarious.org> 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.

Re: Question about Reiser4

[Miguel Ojeda]

On 4/23/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> 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.
> -

Just an idea: And what about creating a new tree (like -r4),
maintained by namesys people, tested by several people, with dedicated
mailing list, etc.?

That way, the code could be patched, updated and cleaned over the time
(without firing up people), it could be tested without pain, people
would send more bug reports and every work would be centralized.
Reiser4 would get much more attention.

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm

Re: Question about Reiser4

[Andi Kleen]

Andrew Morton <akpm@linux-foundation.org> 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). 

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 would expect that reviewing that would be much smoother
because people could actually concentrate on the technical details.

-Andi

Re: Question about Reiser4

[Theodore Tso]

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

Re: Question about Reiser4

[H. Peter Anvin]

Theodore Tso wrote:
> 
> 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.
> 

Now, to be fair, there are probably a number of cases where 
open/lseek/readv/close and open/lseek/writev/close would be worth doing 
as a single system call.  The big problem as far as I can see involves 
EINTR handling; such a system call has serious restartability implications.

Of course, there are Ingo's syslets...

	-hpa

Re: Question about Reiser4

[Neil Brown]

On Monday April 23, hpa@zytor.com wrote:
> Theodore Tso wrote:
> > 
> > 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.
> > 
> 
> Now, to be fair, there are probably a number of cases where 
> open/lseek/readv/close and open/lseek/writev/close would be worth doing 
> as a single system call.  The big problem as far as I can see involves 
> EINTR handling; such a system call has serious restartability implications.
> 
> Of course, there are Ingo's syslets...

Our you could think outside the circle:
Store all your "small files" as symlinks, then use "symlink" to create
them and "readlink" to read them. (You would probably end up use
symlinkat and readlinkat).
Only one system call instead of three.
I guess you don't get meaningful permission bits then... I wonder if
that really matters.

NeilBrown

Re: Question about Reiser4

[H. Peter Anvin]

Neil Brown wrote:
> 
> Our you could think outside the circle:
> Store all your "small files" as symlinks, then use "symlink" to create
> them and "readlink" to read them. (You would probably end up use
> symlinkat and readlinkat).
> Only one system call instead of three.
> I guess you don't get meaningful permission bits then... I wonder if
> that really matters.
> 

For some applications, oh yes it does.

	-hpa

Re: Question about Reiser4

[Jan Engelhardt]

On Apr 23 2007 17:21, H. Peter Anvin wrote:
> Neil Brown wrote:
>> 
>> Our you could think outside the circle:
>> Store all your "small files" as symlinks, then use "symlink" to create
>> them and "readlink" to read them. (You would probably end up use
>> symlinkat and readlinkat).
>> Only one system call instead of three.
>> I guess you don't get meaningful permission bits then... I wonder if
>> that really matters.
>
> For some applications, oh yes it does.

Put them in a protected directory.


Jan
-- 

Re: Question about Reiser4

[Theodore Tso]

On Mon, Apr 23, 2007 at 04:53:03PM -0700, H. Peter Anvin wrote:
> Theodore Tso wrote:
> >
> >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.
> >
> 
> Now, to be fair, there are probably a number of cases where 
> open/lseek/readv/close and open/lseek/writev/close would be worth doing 
> as a single system call.  The big problem as far as I can see involves 
> EINTR handling; such a system call has serious restartability implications.

Sure, but Hans wants to change /etc/inetd.conf into /etc/inetd.conf.d,
where you have: /etc/inetd.conf.d/telnet/port,
/etc/inetd.conf.d/telnet/protocol, /etc/inetd.conf.d/telnet/wait,
/etc/inetd.conf.d/telnet/userid, /etc/inetd.conf.d/telnet/daemon,
etc. for each individual line in /etc/inetd.conf.  (And where each
file might only contains 2-4 characters each: i.e., "23", "tcp",
"root", etc.)

So it's not enough just to collapse open/pread/close into a single
system call; in order to gain back the performance squandered by all
of these itsy-bitsy tiny little files.  You want to collapse the
open/pread/close for many of these little files into a single system
call, hence Hans's insistence on sys_reiser4(); otherwise his scheme
doesn't work all that well at all.

						- Ted

Re: Question about Reiser4

[H. Peter Anvin]

Theodore Tso wrote:
>>>
>> Now, to be fair, there are probably a number of cases where 
>> open/lseek/readv/close and open/lseek/writev/close would be worth doing 
>> as a single system call.  The big problem as far as I can see involves 
>> EINTR handling; such a system call has serious restartability implications.
> 
> Sure, but Hans wants to change /etc/inetd.conf into /etc/inetd.conf.d,
> where you have: /etc/inetd.conf.d/telnet/port,
> /etc/inetd.conf.d/telnet/protocol, /etc/inetd.conf.d/telnet/wait,
> /etc/inetd.conf.d/telnet/userid, /etc/inetd.conf.d/telnet/daemon,
> etc. for each individual line in /etc/inetd.conf.  (And where each
> file might only contains 2-4 characters each: i.e., "23", "tcp",
> "root", etc.)
> 
> So it's not enough just to collapse open/pread/close into a single
> system call; in order to gain back the performance squandered by all
> of these itsy-bitsy tiny little files.  You want to collapse the
> open/pread/close for many of these little files into a single system
> call, hence Hans's insistence on sys_reiser4(); otherwise his scheme
> doesn't work all that well at all.
> 

Heh.  sys_read_tree() -- walk a directory tree and return it as a data 
structure in memory :)

	-hpa

Re: Question about Reiser4

[Theodore Tso]

On Mon, Apr 23, 2007 at 05:31:29PM -0700, H. Peter Anvin wrote:
> Heh.  sys_read_tree() -- walk a directory tree and return it as a data 
> structure in memory :)

But maybe you don't want every single file in the directory, but some
subset of the files in the directory tree.  So before you know it:

sys_fs_sql("SELECT port,userid,daemon FROM /etc/inetd.conf.d "
	"WHERE protocol=='tcp'", buf, sizeof(buf));

The question is where do you stop on the slippery slope, and is it
really all that harder than simply parsing a /etc/gitconfig or
/etc/e2fsck.conf file.  There are plenty of parsers or database
libraries already written, and many of them are quite efficient.  And
personally, I'd much rather edit a single /etc/gitconfig or
/etc/e2fsck.conf file using emacs than have to cd through 3 or 4
levels of directories to edit each 2-3 byte file one at a time.  But
to each their own....

					- Ted

Re: Question about Reiser4

[Denis Vlasenko]

> Theodore Tso wrote:
> >
> > 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.
> >
>
> Now, to be fair, there are probably a number of cases where
> open/lseek/readv/close and open/lseek/writev/close would be worth doing
> as a single system call.  The big problem as far as I can see involves
> EINTR handling; such a system call has serious restartability implications.
>
> Of course, there are Ingo's syslets...

I definitely would like open/readv/close syscall a lot.
Actually, a set of four syscalls

open/readv/close
open/pread/close
open/writev/close
open/pwrite/close

will allow to reduce syscall overhead for a number of cases.
--
vda

Re: Question about Reiser4

[Eric M. Hopper]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

On Mon, 2007-04-23 at 20:19 -0400, Theodore Tso wrote:
> Sure, but Hans wants to change /etc/inetd.conf into /etc/inetd.conf.d,
> where you have: /etc/inetd.conf.d/telnet/port,
> /etc/inetd.conf.d/telnet/protocol, /etc/inetd.conf.d/telnet/wait,
> /etc/inetd.conf.d/telnet/userid, /etc/inetd.conf.d/telnet/daemon,
> etc. for each individual line in /etc/inetd.conf.  (And where each
> file might only contains 2-4 characters each: i.e., "23", "tcp",
> "root", etc.)

One interesting thing is that /proc already does this.  You can often
generate interesting behavior by writing something into a file in /proc.
If the config file for inetd.conf.d/tellnet/port changed, inetd could
automatically reconfigure that service, and just that service.  No more
re-reading a config file and trying to figure out what changed, you are
notified as soon as it changes on the FS by the FS change detection code
already in place.

It seems to me that being able to be more transparent about how your
on-disk data structures are structured has many interesting implications
and possible advantages.  It should be able to be explored by the wider
sphere of app developers.  Perhaps you are right, and the performance
implications of making all those system calls will be too much.  Or
maybe there's some good way nobody has thought of yet to handle that
problem.  But until the idea can be experimented on and played with,
nobody will know.

And realistically for that to happen Reiser4 has to be available as an
option in the kernels shipped by the major distributions.  And this in
turn requires that it be part of the mainline kernel.

Also, regardless of whether tiny files and on-disk datastructure
transparency exist, I think filesystems should also support ACID.  I
would, in fact, be much happier with ACID support at the filesystem
level than on-disk datastructure transparency.  And while Reiser4
doesn't do this, as I understand it (and I might be wrong) there is some
limited support for transactions built into it beyond simple lock
handling.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 185 bytes --]

Re: Question about Reiser4

[lkml777]

On Tue, 24 Apr 2007 23:39:36 -0700, "Eric M. Hopper"
<hopper@omnifarious.org> said:
> On Tue, 2007-04-24 at 17:12 -0700, lkml777@123mail.org wrote:
> > On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
> > > <hopper@omnifarious.org> said:
> > 
> > > I did.  That whole thread is some guy spouting off a ludicrous Bonnie++
> > > benchmark showing that compressing long strings of 0s results in things
> > > taking up very little space and being very fast.
> > 
> > I think you are deliberately being stupid here.
> > 
> > You are claiming that REISER4's good speed results when using
> > compression actually has a simple explanation and THEREFORE all good
> > result for the filesystem, even those results that have nothing to do
> > with compression, are negated.
> 
> I am claiming nothing of the sort. You are assuming that I'm claiming
> this for some random reason.  And in so doing, you are hurting your
> cause and mine.

Yes you are. Your claim may have only been implicit, but it was also
VERY clear.

You complain that Reiser4's excellent speed results when using
compression might have a simple explanation. 

You then implicitly write off the whole set of results on this basis,
which is just plain dishonest.

You could have pointed out that most of the results did NOT use
compression, but instead you just ignored them.

You could have asked by how much, bonnie++'s use of files that are
mainly zeroes, affected the excellent speeds.

But you didn't, because you weren't really interested.

You ignored about 90% of the benchmarks and concentrated on a very small
area that you could raise a question about.

That is not someone looking for the truth. That is a propagandist
working against Reiser4.

Your conclusion was that of someone who is trying to destroy Reiser4,
while PRETENDING to support it.

Well. At least that is what it looks like to me.

> and ranting about how everybody is ignoring all the good parts of it and
> focusing on the bad parts makes things even worse.

Yes YOU are ignoring all the good parts of it and focusing on the (well
not bad parts but) parts that seem too good to be true.
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service

Re: Question about Reiser4

[Jeff Chua]

On 4/23/07, William Heimbigner <icxcnika@mar.tar.cc> wrote:

> Obviously there's a significant number of people interested in reiser4

Count me in.

Jeff.

Re: Question about Reiser4

[Edward Shishkin]

Hello everyone.

>Begin forwarded message:
>
>Date: 23 Apr 2007 21:05:13 +0200
>From: Andi Kleen <andi@firstfloor.org>
>To: Andrew Morton <akpm@linux-foundation.org>
>Cc: Eric Hopper <hopper@omnifarious.org>, linux-kernel@vger.kernel.org
>Subject: Re: Question about Reiser4
>
>
>Andrew Morton <akpm@linux-foundation.org> 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.

Re: Question about Reiser4

[Andi Kleen]

> 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

Re: Question about Reiser4

[Edward Shishkin]

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.

Re: Question about Reiser4

[Jeff Chua]

On 4/25/07, Edward Shishkin <edward@namesys.com> wrote:

> 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.

Will you be releasing a patch for 2.6.21-rc7 for those who are keen to
test it? The latest version I can find is
reiser4-for-2.6.19-3.patch.gz.

Reiser4 has great potential and I'll be more than happy to test it.

Thanks,
Jeff.

Re: Question about Reiser4

[lkml777]

On Wed, 25 Apr 2007 22:49:11 +0800, "Jeff Chua"
<jeff.chua.linux@gmail.com> said:

> Will you be releasing a patch for 2.6.21-rc7 for those who are keen to
> test it? The latest version I can find is reiser4-for-2.6.19-3.patch.gz.
> 
> Reiser4 has great potential and I'll be more than happy to test it.
> 

Laurent Riffard's Reiser4 patch to the default linux-2.6.20 kernel and a
couple of others.

One of these pages contain a link to them:

http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://linuxhelp.150m.com/installs/compile-kernel.htm
http://m.domaindlx.com/LinuxHelp/fs-benchmarks.htm
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

Re: Question about Reiser4

[Jeff Chua]

On 4/25/07, lkml777@123mail.org <lkml777@123mail.org> wrote:

> Laurent Riffard's Reiser4 patch to the default linux-2.6.20 kernel and a
> couple of others.

Thank you. Got it. Testing it now.

Jeff.

Re: Question about Reiser4

[lkml777]

On Wed, 25 Apr 2007 23:50:22 +0800, "Jeff Chua"
<jeff.chua.linux@gmail.com> said:
> On 4/25/07, lkml777@123mail.org <lkml777@123mail.org> wrote:
> 
> > Laurent Riffard's Reiser4 patch to the default linux-2.6.20 kernel and a
> > couple of others.
> 
> Thank you. Got it. Testing it now.
> 
> Jeff.

What plugins etc are you looking at?
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free

Re: Question about Reiser4

[Jeff Chua]

On 4/26/07, lkml777@123mail.org <lkml777@123mail.org> wrote:
>
> What plugins etc are you looking at?

None. Just want vanilla reiser4 as I've many small files to deal with.

Jeff.

Re: Question about Reiser4

[lkml777]

On Wed, 25 Apr 2007 22:49:11 +0800, "Jeff Chua"
<jeff.chua.linux@gmail.com> said:
> 
> Reiser4 has great potential and I'll be more than happy to test it.
> 
Yeah,... let us know the details of your testing.
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are

Re: Question about Reiser4

[Jeff Chua]

On 4/26/07, lkml777@123mail.org <lkml777@123mail.org> wrote:
>
> On Wed, 25 Apr 2007 22:49:11 +0800, "Jeff Chua"
> <jeff.chua.linux@gmail.com> said:
> >
> > Reiser4 has great potential and I'll be more than happy to test it.
> >
> Yeah,... let us know the details of your testing.

Ok, got reiser4 running on 1 full 250GB partition on Linux-2.6.21-rc7,
and up running reiser4 on another 2 systems. Have done a lot copy and
have not run into an problem since last night.

I'll try it with 2.6.21 soon.

What would be nice is to get grub2 to boot up on the reiser4
partition. I've seen patch for grub, but not for grub2.

I planning to deploy this for squid caching soon.

Thanks,
Jeff.

Re: Question about Reiser4

[Jeff Chua]

> I'll try it with 2.6.21 soon.

Just to inform you that the reiserfs4 patch cleanly on 2.6.21 and
working well. I've not encountered any problem so far.

Thanks,
Jeff.

Re: Question about Reiser4

[lkml777]

> Just to inform you that the reiserfs4 patch cleanly on 2.6.21 and
> working well. I've not encountered any problem so far.
> 
> Thanks,
> Jeff.

Hi Jeff, could you outline the procedure that YOU used to get Reiser4
installed and running.

Thanks a million. 
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - The professional email service

Re: Question about Reiser4

[lkml777]

On Wed, 25 Apr 2007 19:03:12 +0400, "Edward Shishkin"
<edward@namesys.com> said:
> lkml777@123mail.org wrote:
> 
> >
> >As I understand it, the default Reiser4 DOES NOT USE any compression at
> >all, not even tail compression,
> >
> 
> ^tail compression^tail conversion
> Reiser4 does use tail conversion by default.
> 
> > but saves space by eliminating block
> >alignment wastage (tail compression is an option).
> >
> >So lets LOSE the statistics that involve compression. The results now
> >look like this:
> >
> >.-------------------------.
> >| FILESYSTEM | TIME |DISK |
> >| TYPE       |(secs)|USAGE|
> >.-------------------------.
> >|REISER4     | 3462 | 692 |
> >|EXT2        | 4092 | 816 |
> >|JFS         | 4225 | 806 |
> >|EXT4        | 4408 | 816 |
> >|EXT3        | 4421 | 816 |
> >|XFS         | 4625 | 779 |
> >|REISER3     | 6178 | 793 |
> >|FAT32       |12342 | 988 |
> >|NTFS-3g     |10414 | 772 |
> >.-------------------------.
> >
> >These results are still EXTREMELY GOOD for REISER4.
> >  
> >
> 
> Everything is not so simple in the science of testing..
> Would you please change direction of your activity to stressing
> instead of benchmarking? Caught oopses would have great value..
> OK?
> 
> Regards,
> Edward.
> 

Tail conversion is NOT compression,....

So what exactly is your point?

By "tail compression" I mean plugin ctail40, but since I was never able
to get it to work, maybe its not tail compression at all.
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again

Re: Question about Reiser4

[lkml777]

On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
> <hopper@omnifarious.org> said:

> I did.  That whole thread is some guy spouting off a ludicrous Bonnie++
> benchmark showing that compressing long strings of 0s results in things
> taking up very little space and being very fast.

I think you are deliberately being stupid here.

You are claiming that REISER4's good speed results when using
compression actually has a simple explanation and THEREFORE all good
result for the filesystem, even those results that have nothing to do
with compression, are negated.

NOTHING COULD BE FURTHER FROM THE TRUTH.

Your conclusion is a total travesty of logic.

As I understand it, the default Reiser4 DOES NOT USE any compression at
all, not even tail compression, but saves space by eliminating block
alignment wastage (tail compression is an option).

So lets LOSE the statistics that involve compression. The results now
look like this:

.-------------------------.
| FILESYSTEM | TIME |DISK |
| TYPE       |(secs)|USAGE|
.-------------------------.
|REISER4     | 3462 | 692 |
|EXT2        | 4092 | 816 |
|JFS         | 4225 | 806 |
|EXT4        | 4408 | 816 |
|EXT3        | 4421 | 816 |
|XFS         | 4625 | 779 |
|REISER3     | 6178 | 793 |
|FAT32       |12342 | 988 |
|NTFS-3g     |10414 | 772 |
.-------------------------.

These results are still EXTREMELY GOOD for REISER4.

These results still say that Reiser4 is a truly remarkable filesystem,
as stated in:

http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://m.domaindlx.com/LinuxHelp/fs-benchmarks.htm

So why do I see an anti-Reiser religion, in all that you people say.

You, concentrate on the fact that bonnie++'s use of files that are
mainly zeroes, will make the results using compression less good than
they are.

I can't see anywhere where this has been denied.

In fact the other set of statistics that you just ignore, states that in
more realistic situations, the compression speedup is slightly negative.

What is wrong here, is:

You say that the Bonnie++ tests using compression are subject to
interpretation. No argument here.
You ignore the tests that confirm your statement. You are clearly not
interested in the actual results or their interpretation.
You, by some incredibly twisted "logic" the state that Reiser4 is
therefore not good, even though it is clearly the best filesystem when
NOT using compression.

This of course is completely deceitful "logic".

That the speed advantage from compression would be small is clear from
the OTHER data that you ignore, namely:

.-------------------------------------------------.
|File         |Disk |Copy |Copy |Tar  |Unzip| Del |
|System       |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
|Type         | (MB)| (1) | (2) |655MB|655MB| Gig |
.-------------------------------------------------.
|REISER4 lzo  | 278 | 138 |  56 |  80 |  34 |  84 |
|REISER4 gzip | 213 | 148 |  68 |  83 |  48 |  70 |
|REISER4      | 692 | 148 |  55 |  67 |  25 |  56 |
|EXT4         | 816 | 174 |  70 |  74 |  42 |  50 |
.-------------------------------------------------.


> So, the speed increase with compression (on very compressible kernel sources) is slightly negative,
> 
> but the speed is still comparable to that of EXT4.
> 
> > On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
> > <hopper@omnifarious.org> said:
> >
> > > 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?
> >
> > There was a thread the other day, that talked about Reiser4.
> >
> > It took a while but I have found it (actually two)
> >
> > http://lkml.org/lkml/2007/4/5/360
> > http://lkml.org/lkml/2007/4/9/4
> >
> > You may want to check them out.
> 
> I did.  That whole thread is some guy spouting off a ludicrous Bonnie++
> benchmark showing that compressing long strings of 0s results in things
> taking up very little space and being very fast.
> 
> Such things will produce lots of flames and no useful information
> whatsoever as is evinced by the half conspiracy theory, half truth the
> thread degenerated into in the second message you linked to.
> 
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - mmm... Fastmail...

Re: Question about Reiser4

[Eric M. Hopper]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

On Tue, 2007-04-24 at 17:12 -0700, lkml777@123mail.org wrote:
> On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
> > <hopper@omnifarious.org> said:
> 
> > I did.  That whole thread is some guy spouting off a ludicrous Bonnie++
> > benchmark showing that compressing long strings of 0s results in things
> > taking up very little space and being very fast.
> 
> I think you are deliberately being stupid here.
> 
> You are claiming that REISER4's good speed results when using
> compression actually has a simple explanation and THEREFORE all good
> result for the filesystem, even those results that have nothing to do
> with compression, are negated.

I am claiming nothing of the sort.  You are assuming that I'm claiming
this for some random reason.  And in so doing, you are hurting your
cause and mine.

If you would bother to read, I really like the ideas in Reiser4, and I
definitely think it has distinct performance advantages in some much
more common situations than the highly flawed benchmark with Bonnie++
and compression.  I would like it included in the mainline kernel.  In
arguing with me, you are arguing against someone who (as far as I can
tell) you actually share a cause with.

But, bringing in benchmarks that have serious flaws as a general
use-case and attempting to use them as an argument does way more to hurt
your cause than help.  It brands you as a crackpot and a crank (note
that I am not calling you either of those things) and that impression
will also bleed off onto all those who share an association with you by
way of sharing some of your opinions.

Additionally, repeatedly posting something everybody has already read
and ranting about how everybody is ignoring all the good parts of it and
focusing on the bad parts makes things even worse.

I will not respond to you again.  Please stop jumping into discussions
about Reiser4.  I would like it included in the mainline kernel, and you
are hurting that cause.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 185 bytes --]

Re: Question about Reiser4

[Edward Shishkin]

lkml777@123mail.org wrote:

>
>As I understand it, the default Reiser4 DOES NOT USE any compression at
>all, not even tail compression,
>

^tail compression^tail conversion
Reiser4 does use tail conversion by default.

> but saves space by eliminating block
>alignment wastage (tail compression is an option).
>
>So lets LOSE the statistics that involve compression. The results now
>look like this:
>
>.-------------------------.
>| FILESYSTEM | TIME |DISK |
>| TYPE       |(secs)|USAGE|
>.-------------------------.
>|REISER4     | 3462 | 692 |
>|EXT2        | 4092 | 816 |
>|JFS         | 4225 | 806 |
>|EXT4        | 4408 | 816 |
>|EXT3        | 4421 | 816 |
>|XFS         | 4625 | 779 |
>|REISER3     | 6178 | 793 |
>|FAT32       |12342 | 988 |
>|NTFS-3g     |10414 | 772 |
>.-------------------------.
>
>These results are still EXTREMELY GOOD for REISER4.
>  
>

Everything is not so simple in the science of testing..
Would you please change direction of your activity to stressing
instead of benchmarking? Caught oopses would have great value..
OK?

Regards,
Edward.

Re: Question about Reiser4

[lkml777]

Hello Eric, anyone home?

> On Tue, 2007-04-24 at 17:12 -0700, lkml777@123mail.org wrote:
> > On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
> > > <hopper@omnifarious.org> said:
> > 
> > > I did.  That whole thread is some guy spouting off a ludicrous Bonnie++
> > > benchmark showing that compressing long strings of 0s results in things
> > > taking up very little space and being very fast.
> > 
> > I think you are deliberately being stupid here.
> > 
> > You are claiming that REISER4's good speed results when using
> > compression actually has a simple explanation and THEREFORE all good
> > result for the filesystem, even those results that have nothing to do
> > with compression, are negated.
> 
> I am claiming nothing of the sort. You are assuming that I'm claiming
> this for some random reason.  And in so doing, you are hurting your
> cause and mine.

Yes you are. Your claim may have only been implicit, but it was also
VERY clear.

You complain that Reiser4's excellent speed results when using
compression might have a simple explanation. 

You then implicitly write off the whole set of results on this basis,
which is just plain dishonest.

You could have pointed out that most of the results did NOT use
compression, but instead you just ignored them.

You could have asked by how much, bonnie++'s use of files that are
mainly zeroes, affected the excellent speeds.

But you didn't, because you weren't really interested.

You ignored about 90% of the benchmarks and concentrated on a very small
area that you could raise a question about.

That is not someone looking for the truth. That is a propagandist
working against Reiser4.

Your conclusion was that of someone who is trying to destroy Reiser4,
while PRETENDING to support it.

Well. At least that is what it looks like to me.

> and ranting about how everybody is ignoring all the good parts of it and
> focusing on the bad parts makes things even worse.

Yes YOU are ignoring all the good parts of it and focusing on the (well
not bad parts but) parts that seem too good to be true.
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

Re: Question about Reiser4

[lkml777]

On Wed, 25 Apr 2007 19:03:12 +0400, "Edward Shishkin"
<edward@namesys.com> said:
> lkml777@123mail.org wrote:
> 
> >
> >As I understand it, the default Reiser4 DOES NOT USE any compression at
> >all, not even tail compression,
> >
> 
> ^tail compression^tail conversion
> Reiser4 does use tail conversion by default.
> 
> > but saves space by eliminating block
> >alignment wastage (tail compression is an option).
> >
> >So lets LOSE the statistics that involve compression. The results now
> >look like this:
> >
> >.-------------------------.
> >| FILESYSTEM | TIME |DISK |
> >| TYPE       |(secs)|USAGE|
> >.-------------------------.
> >|REISER4     | 3462 | 692 |
> >|EXT2        | 4092 | 816 |
> >|JFS         | 4225 | 806 |
> >|EXT4        | 4408 | 816 |
> >|EXT3        | 4421 | 816 |
> >|XFS         | 4625 | 779 |
> >|REISER3     | 6178 | 793 |
> >|FAT32       |12342 | 988 |
> >|NTFS-3g     |10414 | 772 |
> >.-------------------------.
> >
> >These results are still EXTREMELY GOOD for REISER4.
> >  
> >
> 
> Everything is not so simple in the science of testing..
> Would you please change direction of your activity to stressing
> instead of benchmarking? Caught oopses would have great value..
> OK?
> 
> Regards,
> Edward.
> 

Tail conversion is NOT compression,....

So what exactly is your point?

By "tail compression" I mean plugin ctail40, but since I was never able
to get it to work, maybe its not tail compression at all.
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

Re: Question about Reiser4

[lkml777]

OOn Wed, 25 Apr 2007 19:03:12 +0400, "Edward Shishkin"
<edward@namesys.com> said:
> lkml777@123mail.org wrote:
> 
> >
> >As I understand it, the default Reiser4 DOES NOT USE any compression at
> >all, not even tail compression,
> >
> 
> ^tail compression^tail conversion
> Reiser4 does use tail conversion by default.
> 
> > but saves space by eliminating block
> >alignment wastage (tail compression is an option).
> >
> >So lets LOSE the statistics that involve compression. The results now
> >look like this:
> >
> >.-------------------------.
> >| FILESYSTEM | TIME |DISK |
> >| TYPE       |(secs)|USAGE|
> >.-------------------------.
> >|REISER4     | 3462 | 692 |
> >|EXT2        | 4092 | 816 |
> >|JFS         | 4225 | 806 |
> >|EXT4        | 4408 | 816 |
> >|EXT3        | 4421 | 816 |
> >|XFS         | 4625 | 779 |
> >|REISER3     | 6178 | 793 |
> >|FAT32       |12342 | 988 |
> >|NTFS-3g     |10414 | 772 |
> >.-------------------------.
> >
> >These results are still EXTREMELY GOOD for REISER4.
> >  
> >
> 
> Everything is not so simple in the science of testing..
> Would you please change direction of your activity to stressing
> instead of benchmarking? Caught oopses would have great value..
> OK?
> 
> Regards,
> Edward.
> 

Tail conversion is NOT compression,....

So what exactly is your point?

By "tail compression" I mean plugin ctail40, but since I was never able
to get it to work, maybe its not tail compression at all.
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - mmm... Fastmail...

Re: Question about Reiser4

[lkml777]

Hi Edward, it seems that lkml has contacted both of my email accounts
and cripped them.

I can no longer recieve email from lkml on this account.

I can neither recieve or send email to lkml from my other account.

They have also just deleted the 4 emails I sent to lkml from the page
http://lkml.org/lkml/2007/4/30/

This included one to you.

In case you didn't get it,... here it is again.

(Since you still haven't answered this one).

-----------------

On Wed, 25 Apr 2007 19:03:12 +0400, "Edward Shishkin"
<edward@namesys.com> said:
> lkml777@123mail.org wrote:
> 
> >
> >As I understand it, the default Reiser4 DOES NOT USE any compression at
> >all, not even tail compression,
> >
> 
> ^tail compression^tail conversion
> Reiser4 does use tail conversion by default.
> 
> > but saves space by eliminating block
> >alignment wastage (tail compression is an option).
> >
> >So lets LOSE the statistics that involve compression. The results now
> >look like this:
> >
> >.-------------------------.
> >| FILESYSTEM | TIME |DISK |
> >| TYPE       |(secs)|USAGE|
> >.-------------------------.
> >|REISER4     | 3462 | 692 |
> >|EXT2        | 4092 | 816 |
> >|JFS         | 4225 | 806 |
> >|EXT4        | 4408 | 816 |
> >|EXT3        | 4421 | 816 |
> >|XFS         | 4625 | 779 |
> >|REISER3     | 6178 | 793 |
> >|FAT32       |12342 | 988 |
> >|NTFS-3g     |10414 | 772 |
> >.-------------------------.
> >
> >These results are still EXTREMELY GOOD for REISER4.
> >  
> >
> 
> Everything is not so simple in the science of testing..
> Would you please change direction of your activity to stressing
> instead of benchmarking? Caught oopses would have great value..
> OK?
> 
> Regards,
> Edward.
> 

Tail conversion is NOT compression,....

So what exactly is your point?

By "tail compression" I mean plugin ctail40, but since I was never able
to get it to work, maybe its not tail compression at all.
-- 
  
  lkml777@123mail.org

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow