Again, some bad Reiser4 (ReiserFS) 'reviews'

Again, some bad Reiser4 (ReiserFS) 'reviews'

[Dieter Nützel]

http://rufus.hackish.org/wiki/2.6FileSystemBenchmarks

Greetings,
	Dieter

Reiser4 InterMezzo reimplementation?

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




I always liked some of the ideas behind InterMezzo -- particularly,
using it as a secure alternative to NFS and being able to have a huge
cache.  In fact, it can be exactly as fast as local FS access for cached
files.

Unfortunately, InterMezzo seems (very) poorly maintained, and may not
play nice with Reiser4.  Could a Reiser4 plugin be written to do this?

I know this was mentioned before, and it was marked for a later version
(5, 6, 7, or something) -- but could some basic functionality be written
quickly that would be extensible enough to be able to "upgrade" to this
new version?

(Think if someone were to add ..meta to reiser3, but not plugins,
dancing trees, or anything else.)

CODA would work, AFS would work.  Lustre or InterMezzo would work if
they were available in a stable form for the 2.6 kernel.  I just think
it'd be faster with reiser4 as the cache.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQPXtQ3gHNmZLgCUhAQJ3ZBAAjZ9QhiETD6ENXc/nzPc1a0zysQxcaRcg
q1utQYvuXBl7xkvQEPAh6wYjJXfjfXzqLG+mw6v1dwY1FHHzUVBF7cFw783Xc/0D
+WenecCoxaobbrTf+Mbp+RIeNMxtHbKMcNVEc1CHWQbmx+vlrlZ/Hg9fIXTN6ows
6rjkmzeLPmnQ8iArphBNP/OytB0BoesQANrF5psXyvtlgpf7YiVDMI9sdywwA08V
lszhRtLhP8kwUM04n+/vDOvhrTMvVz+rF7mbRVNU7LhsZ1vqhFYXj9WmYchG4eGV
vOff4zrJKw8FyyBTSphLmvpcs/JCxUDL+ZZYILzH528ZH6suO/uIeta2GLoCeNp4
ims3tBGdFjuthIJpduK3Bd+xW8KHExb8Iexono2bMmFToQu1U9WTNB4u22KK73lO
kkSjJBvObU8Az4tBaWHIOyetkZIaoRGtBZwrDtWhQrl++HWZlnTG5NgndOSy38/w
LNCwjUwZktWy5cgp+mnaR8cjZL7pCFbE93s7tWWlvb+S3k8ViujoCOxP9TT/BHuz
VXKGZDcmmROElri11IrsTbo4m0QmLgYrqNTYWR0p8ACxlOkB9dFxDYz7wAtwP1a0
zfBuou/vsY9unaw2Eg5g5SnBXTEPHZ0vvI1PDYqaau7SW/HOfONuRba2cMrDO9fU
tVFXzZETsBI=
=9GWr
-----END PGP SIGNATURE-----

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Hans Reiser]

Dieter Nützel wrote:

>http://rufus.hackish.org/wiki/2.6FileSystemBenchmarks
>
>Greetings,
>	Dieter
>
>
>  
>
I think he has an fsync intensive workload, which reiser4 is not good at 
because we haven't bothered with it yet, and we care more about maturing 
the atomic functionality.  I have no idea what ccache does with the fs.  
Does it use fsync?

How he got tar to be slow is hard to understand, I don't remember seeing 
a slow tar using reiser4, does anyone else?  I am guessing he created 
the tarball using ext2, and didn't know that readdir order matters and 
affects the tarball, and that he should create it on the filesystem 
being benchmarked.  Maybe the tarball ordering also affects subsequent 
compiles, I don't know.

zam, would you confirm that the fibration plugin is our current default 
plugin?

Hans

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Alex Zarochentsev]

On Thu, Jul 15, 2004 at 10:56:24AM -0700, Hans Reiser wrote:
> Dieter N?tzel wrote:
> 
> >http://rufus.hackish.org/wiki/2.6FileSystemBenchmarks
> >
> >Greetings,
> >	Dieter
> >
> >
> > 
> >
> I think he has an fsync intensive workload, which reiser4 is not good at 
> because we haven't bothered with it yet, and we care more about maturing 
> the atomic functionality.  I have no idea what ccache does with the fs.  
> Does it use fsync?
> 
> How he got tar to be slow is hard to understand, I don't remember seeing 
> a slow tar using reiser4, does anyone else?  I am guessing he created 
> the tarball using ext2, and didn't know that readdir order matters and 
> affects the tarball, and that he should create it on the filesystem 
> being benchmarked.  Maybe the tarball ordering also affects subsequent 
> compiles, I don't know.
> 
> zam, would you confirm that the fibration plugin is our current default 
> plugin?

"dot-o fibrate" is default.

> Hans

-- 
Alex.

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[mjt]

On Thu, Jul 15, 2004 at 10:22:09PM +0400, Alex Zarochentsev wrote:
>> zam, would you confirm that the fibration plugin is our current default 
>> plugin?
>
>"dot-o fibrate" is default.

This always puzzles me. Would not ext-1-fibre give the same results for

This always puzzles me. Would not ext-1-fibre give the same results for
.o files but also the same bonus with all source code and such with .c
and .h?

I at least overrode the default because of that :)

-- 
mjt

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Markus Törnqvist wrote:

| This always puzzles me. Would not ext-1-fibre give the same results for
| .o files but also the same bonus with all source code and such with .c
| and .h?

For that matter, what about for generic extensions?  Take this perl
pseudocode:

if ($file->[name} =~  /.\.(\w{1,4})$/) {
	$file->fibrate_by($1);
}



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQPgx9HgHNmZLgCUhAQJSKw//cab8Yn/PQYO2NSooVCWAeMlo3MQMx079
R/h0/4sgeKP7vcUNIte0b8KObIL5bC0MPtTkebVb1KPzzrRn4/5eEnTNpz270m0c
Xl9apPfc6K2Hrrx7PviROj2xDtgpwRc+qSfq4x7F0rNThxLidkhqy2AFVU2wDGpu
EWVQYvDL2/ggo/iFkVPUoKimyHR6fynjp/oAYSIkjGEj7xel2rIbNajbf3NlYE/m
4fz6eu3nec/hng7m89fzmsfl6CiD3g+hQhS781L/jadkCSuIVN2KMREeBYFsl9Rg
suH2Y+CoA+Gj7AclWLbVneKJQo9iTNLYIOhx/ONvzbpP1qYgQ1/9a/OtHEStkqOb
wPi66rfACocr3ezAQtU8Q7fThyRcJPucrPKnYeVWILRTmaJhrdWbF6jVn9nCAmZB
QV82DLEAq+yZOVkfA7V3NPimHi1K62hAmbE8aVk75ySEAQyGQV33ZM6RDcKH5aBT
fJlzpyvlF4lcCERqIL9pP2vahvQSwlSR+Q4oumNgt6kvS6Cjh25e4pPu9eUnpDIi
bptYRvk1qd8de/75b+5U7wsEL2WmnVYG1BFj9373y00WOenlyw+XWiAueiLZutU8
UkeOmnw6LRxfPvKMAtlWNUIPAnjzaRdmydcRNhtzuMpuABg583IULN5zjb3cp1ev
KLsoMQ/Bxz8=
=rSJy
-----END PGP SIGNATURE-----

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Hans Reiser]

David Masover wrote:

>
>
> Markus Törnqvist wrote:
>
> | This always puzzles me. Would not ext-1-fibre give the same results for
> | .o files but also the same bonus with all source code and such with .c
> | and .h?
>
> For that matter, what about for generic extensions?  Take this perl
> pseudocode:
>
> if ($file->[name} =~  /.\.(\w{1,4})$/) {
>     $file->fibrate_by($1);
> }
>
>
>
Please consider creating a plugin.;-)   In C....;-)

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Hans Reiser]

Markus Törnqvist wrote:

>On Thu, Jul 15, 2004 at 10:22:09PM +0400, Alex Zarochentsev wrote:
>  
>
>>>zam, would you confirm that the fibration plugin is our current default 
>>>plugin?
>>>      
>>>
>>"dot-o fibrate" is default.
>>    
>>
>
>This always puzzles me. Would not ext-1-fibre give the same results for
>
>This always puzzles me. Would not ext-1-fibre give the same results for
>.o files but also the same bonus with all source code and such with .c
>and .h?
>
>I at least overrode the default because of that :)
>
>  
>
nikita, is there a reason, or did inertia rule and we should change it?

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Nikita Danilov]

Hans Reiser writes:
 > Markus Törnqvist wrote:
 > 
 > >On Thu, Jul 15, 2004 at 10:22:09PM +0400, Alex Zarochentsev wrote:
 > >  
 > >
 > >>>zam, would you confirm that the fibration plugin is our current default 
 > >>>plugin?
 > >>>      
 > >>>
 > >>"dot-o fibrate" is default.
 > >>    
 > >>
 > >
 > >This always puzzles me. Would not ext-1-fibre give the same results for
 > >
 > >This always puzzles me. Would not ext-1-fibre give the same results for
 > >.o files but also the same bonus with all source code and such with .c
 > >and .h?
 > >
 > >I at least overrode the default because of that :)
 > >
 > >  
 > >
 > nikita, is there a reason, or did inertia rule and we should change it?
 > 

This is my fault, ext-1 should be the default, I just forgot to change
it.

Nikita.

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Hans Reiser]

Nikita Danilov wrote:

>Hans Reiser writes:
> > Markus Tц╤rnqvist wrote:
> > 
> > >On Thu, Jul 15, 2004 at 10:22:09PM +0400, Alex Zarochentsev wrote:
> > >  
> > >
> > >>>zam, would you confirm that the fibration plugin is our current default 
> > >>>plugin?
> > >>>      
> > >>>
> > >>"dot-o fibrate" is default.
> > >>    
> > >>
> > >
> > >This always puzzles me. Would not ext-1-fibre give the same results for
> > >
> > >This always puzzles me. Would not ext-1-fibre give the same results for
> > >.o files but also the same bonus with all source code and such with .c
> > >and .h?
> > >
> > >I at least overrode the default because of that :)
> > >
> > >  
> > >
> > nikita, is there a reason, or did inertia rule and we should change it?
> > 
>
>This is my fault, ext-1 should be the default, I just forgot to change
>it.
>
>Nikita.
>
>
>  
>
vs, please change it if Nikita did not already.

Markus, thanks for catching it.

Hans

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Francesco Biscani]

On Sunday 18 July 2004 08:44, Hans Reiser wrote:
> Nikita Danilov wrote:
> >Hans Reiser writes:
> > > nikita, is there a reason, or did inertia rule and we should change it?
> >
> >This is my fault, ext-1 should be the default, I just forgot to change
> >it.
> >
> >Nikita.
>
> vs, please change it if Nikita did not already.
>
> Markus, thanks for catching it.
>
> Hans

Sorry for the newbish question, but does it mean that one has to re-run mkfs 
to change this? Or is this just a mount option?

Thanks,

  Francesco

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Redeeman]

On Thu, 2004-07-15 at 10:56 -0700, Hans Reiser wrote:
> Dieter Nützel wrote:
> 
> >http://rufus.hackish.org/wiki/2.6FileSystemBenchmarks
> >
> >Greetings,
> >	Dieter
> >
> >
> >  
> >
> I think he has an fsync intensive workload, which reiser4 is not good at 
> because we haven't bothered with it yet, and we care more about maturing 
> the atomic functionality.  I have no idea what ccache does with the fs.  
> Does it use fsync?
> 
> How he got tar to be slow is hard to understand, I don't remember seeing 
> a slow tar using reiser4, does anyone else?  I am guessing he created 
> the tarball using ext2, and didn't know that readdir order matters and 
> affects the tarball, and that he should create it on the filesystem 
> being benchmarked.  Maybe the tarball ordering also affects subsequent 
> compiles, I don't know.
wow, i didnt know i had to create on the filesystem i benchmark, i
always just created on what i had, and that werent reiser4, but still
reiser4 proved to be the fastest (alot faster than the other)

> 
> zam, would you confirm that the fibration plugin is our current default 
> plugin?
> 
> Hans
> 
-- 
Redeeman <redeeman@metanurb.dk>

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Hans Reiser]

Redeeman wrote:

>On Thu, 2004-07-15 at 10:56 -0700, Hans Reiser wrote:
>  
>
>>Dieter Nützel wrote:
>>
>>    
>>
>>>http://rufus.hackish.org/wiki/2.6FileSystemBenchmarks
>>>
>>>Greetings,
>>>	Dieter
>>>
>>>
>>> 
>>>
>>>      
>>>
>>I think he has an fsync intensive workload, which reiser4 is not good at 
>>because we haven't bothered with it yet, and we care more about maturing 
>>the atomic functionality.  I have no idea what ccache does with the fs.  
>>Does it use fsync?
>>
>>How he got tar to be slow is hard to understand, I don't remember seeing 
>>a slow tar using reiser4, does anyone else?  I am guessing he created 
>>the tarball using ext2, and didn't know that readdir order matters and 
>>affects the tarball, and that he should create it on the filesystem 
>>being benchmarked.  Maybe the tarball ordering also affects subsequent 
>>compiles, I don't know.
>>    
>>
>wow, i didnt know i had to create on the filesystem i benchmark, i
>always just created on what i had, and that werent reiser4, but still
>reiser4 proved to be the fastest (alot faster than the other)
>  
>
;-)

Maybe somebody should try to reproduce his benchmark.  Maybe he either 
made more errors than I guessed at, or, quite likely, he found a 
weakness that we should look into.

fsync we suck at though.  Maybe in 6 months we can look at optimizing it 
(I know that fsync matters in the real world, I just don't have spare 
resources at the moment).

>  
>
>>zam, would you confirm that the fibration plugin is our current default 
>>plugin?
>>
>>Hans
>>
>>    
>>

Re: Again, some bad Reiser4 (ReiserFS) 'reviews'

[Peter Nelson]

Dieter Nützel wrote:

> http://rufus.hackish.org/wiki/2.6FileSystemBenchmarks
>
> Greetings,
>     Dieter

Hi, sorry for the late reply, but I've been on vacation for the past 
month.  When I originally ran these benchmarks a few months ago I had 
posted them to the LKML and this list, but it was linked to a different 
website (which has been renamed a few times now).  After a good amount 
of discussion on the LKML, this benchmark was actually what prompted 
Hans "to add a nice little optimization for compiles to Reiser4 as a 
result of thinking about compile benchmarks" (sorting by the last 
character).  Anyway, I'm going to be building a new system in around 1 
months time which will be the perfect opportunity to rerun all these 
benchmarks.  If anyone has suggestions on how to make the test better, 
feel free to pass them along.  The thing I'd be most interested in 
testing is if there's a way to flush file caches to see how much of a 
difference having the file cached in ram compared to reading off disk makes.

-Peter Nelson