reiser4.1

reiser4.1

[Gagan Rajpal]

Are there any plans or schedule for a reiser4.1? when will it be safe 
to label reiser4 as safe for using on mission critical servers?

Thanks,
Gagan

reiser4.1

[Gagan Rajpal]

Are there any plans or schedule for a reiser4.1? when will it be safe 
to label reiser4 as safe for using on mission critical servers?

Thanks,
Gagan

Re: reiser4.1

[Vladimir Saveliev]

Hello

On Wed, 2005-03-02 at 07:34, Gagan Rajpal wrote:
> Are there any plans or schedule for a reiser4.1? 

Currently, nobody actively works on repacker (which is the main thing
which is destinated for 4.1). OTOH, some work was done earlier, so
hopefully, when 4.0 is considered stable, 4.1 will not take amount of
time comparable with amount of time 4.0 took.

> when will it be safe 
> to label reiser4 as safe for using on mission critical servers?
> 

After it is one year in Linus kernel.

> Thanks,
> Gagan
> 
> 
> 

Re: reiser4.1

[Hans Reiser]

Vladimir Saveliev wrote:

>Hello
>
>On Wed, 2005-03-02 at 07:34, Gagan Rajpal wrote:
>  
>
>>Are there any plans or schedule for a reiser4.1? 
>>    
>>
>
>Currently, nobody actively works on repacker (which is the main thing
>which is destinated for 4.1). OTOH, some work was done earlier, so
>hopefully, when 4.0 is considered stable, 4.1 will not take amount of
>time comparable with amount of time 4.0 took.
>  
>
Compression is what will be in 4.1, not the repacker.  At least, I hope 
edward gets it done soon.....

>  
>
>>when will it be safe 
>>to label reiser4 as safe for using on mission critical servers?
>>
>>    
>>
>
>After it is one year in Linus kernel.
>
>  
>
>>Thanks,
>>Gagan
>>
>>
>>
>>    
>>
>
>
>
>  
>

Re[2]: reiser4.1

[Pysiak Satriani]

Hi

> Compression is what will be in 4.1, not the repacker.  At least, I hope
> edward gets it done soon.....
I've read an interview with Hans in the polish edition of Chip Special some
time ago.
I remember Hans saying that nowadays CPUs are so fast, they compress
faster than HDDs move the heads around and do the writes. So compression,
if done properly, can be with no negative impact to speed.

Can you say what level of compression with which processors would handle
it without speedloss?

Regards,
Maciej

Re: reiser4.1

[Edward Shishkin]

Pysiak Satriani wrote:

>Hi
>
>  
>
>>Compression is what will be in 4.1, not the repacker.  At least, I hope
>>edward gets it done soon.....
>>    
>>
>I've read an interview with Hans in the polish edition of Chip Special some
>time ago.
>I remember Hans saying that nowadays CPUs are so fast, they compress
>faster than HDDs move the heads around and do the writes.
>

That is the fact. Moreover CPUs tends to develop faster then hard drives.

> So compression,
>if done properly, can be with no negative impact to speed.
>
>Can you say what level of compression with which processors would handle
>it without speedloss?
>
We don't have comprehensive benchmarks as it is not quite stable. The 
following is some
results for 'cp'. Note that the cpu time doesn't include flushing and 
compression:

belka workstation:
Dual Intel(R) Xeon(TM) CPU 2.40GHz;
1G RAM;
36G ide   partition;
SMP on;
Linux 2.6.9-rc1-mm5
reiser4 (Large keys)

Creation of 20 linux source trees

UNIX_FILES:

(policy=tails)
real    2m32.505s
sys     1m18.876s
df      3205900

(policy=smart)
real    2m22.251s
sys     1m1.100s
df      3292936

CRYPTCOMPRESS FILES
(64K compression):

NONE
real    2m27.448s
sys     0m46.702s
df      3214952

GZIP1
real    2m50.132s
sys     0m44.647s
df      1045660

LZO1
real    1m52.028s
sys     0m44.779s
df      1343188

LZRW1
real    1m50.048s
sys     0m44.644s
df      1504196


>Regards,
>Maciej
>
>  
>

Re: Re[2]: reiser4.1

[Valdis.Kletnieks]

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

On Thu, 03 Mar 2005 09:55:20 +0100, Pysiak Satriani said:

> I remember Hans saying that nowadays CPUs are so fast, they compress
> faster than HDDs move the heads around and do the writes. So compression,
> if done properly, can be with no negative impact to speed.
> 
> Can you say what level of compression with which processors would handle
> it without speedloss?

IBM's AIX 4.3 and later support LZ compression on their JFS file system.
I was able to measure a 10-15% speed-up by converting /usr to compressed
even on a 133MZ Power604e chip because even back then, it was faster to
read half as many blocks off a SCSI disk and decompress.

So it's been at least a potential win for a decade or so, assuming your
filesystem is able to deal well with fragments (you can't really win unless
you take a 4K or so logical block, compress it to some number of 512-byte
chunks, and then store the resulting chunks cheaply - JFS does the
blocks-and-frags efficiently, so it's easy to win.  On the other hand,
it would be dreadful for Reiser3 - imagine having to do tail packing
for *every block* (which is what you end up doing, sort of...)

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

Re[4]: reiser4.1

[Pysiak Satriani]

Hello Valdis,

Friday, March 4, 2005, 8:55:52 AM, you wrote:

> IBM's AIX 4.3 and later support LZ compression on their JFS file system.
> I was able to measure a 10-15% speed-up by converting /usr to compressed
> even on a 133MZ Power604e chip because even back then, it was faster to
> read half as many blocks off a SCSI disk and decompress.
Interesting.

> So it's been at least a potential win for a decade or so, assuming your
> filesystem is able to deal well with fragments (you can't really win unless
> you take a 4K or so logical block, compress it to some number of 512-byte
> chunks, and then store the resulting chunks cheaply - JFS does the
> blocks-and-frags efficiently, so it's easy to win.
I wonder if NTFS compression does it well... I was always scared of
compression on NTFS because of possible slowdowns and just the fact that
compression adds another level of complexity to all reads/write and
possible future recovery if something breaks down.

-- 
Best regards,
Maciej