reiser4progs do not handle the reiser4 format changes

reiser4progs do not handle the reiser4 format changes

[E.Gryaznova]

Notification:

The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new 
reiser4 kernel code is able to handle the old format.

The reiser4progs-1.0.4 are not able to handle the format changes. The 
fix for reiser4progs will be ready next week.

Thanks,
Lena

Re: reiser4progs do not handle the reiser4 format changes

[David Masover]

E.Gryaznova wrote:
> Notification:
> 
> The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new 
> reiser4 kernel code is able to handle the old format.

Good, so I don't have to reformat _immediately_...

But, why isn't it for 2.6.12 yet?  We're already on at least 2.6.12.2, 
last I checked...

> The reiser4progs-1.0.4 are not able to handle the format changes. The 
> fix for reiser4progs will be ready next week.

Will there be a conversion tool?

Re: reiser4progs do not handle the reiser4 format changes

[Edward Shishkin]

David Masover wrote:

> E.Gryaznova wrote:
>
>> Notification:
>>
>> The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new 
>> reiser4 kernel code is able to handle the old format.
>
>
> Good, so I don't have to reformat _immediately_...
>
> But, why isn't it for 2.6.12 yet?  We're already on at least 2.6.12.2, 
> last I checked...
>
>> The reiser4progs-1.0.4 are not able to handle the format changes. The 
>> fix for reiser4progs will be ready next week.
>
>
> Will there be a conversion tool?
>
>

No. Reiser4progs just will support a set of new plugins which have been 
added to the kernel.
In particular, mkfs.reiser4 should allow user to specify the plugins 
like other existing
ones. This will be a way to create cryptcompress files per superblock. 
There is another
more flexible way (which is compatible with the previous one) to create 
it per file/directory,
but it uses deprecated metas interface..
Note: since cryptcompress plugin is unstable, the new options are 
supposed to be undocumented.

Thanks,
Edward.
 

Re: reiser4progs do not handle the reiser4 format changes

[Hans Reiser]

E.Gryaznova wrote:

> Notification:
>
> The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new
> reiser4 kernel code is able to handle the old format.
>
> The reiser4progs-1.0.4 are not able to handle the format changes. The
> fix for reiser4progs will be ready next week.
>
> Thanks,
> Lena
>
>
>
I would like to apologize to the users for this, it should not have been
done this way.

Re: reiser4progs do not handle the reiser4 format changes

[Hans Reiser]

Edward Shishkin wrote:

> David Masover wrote:
>
>> E.Gryaznova wrote:
>>
>>> Notification:
>>>
>>> The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new
>>> reiser4 kernel code is able to handle the old format.
>>
>>
>>
>> Good, so I don't have to reformat _immediately_...
>>
>> But, why isn't it for 2.6.12 yet?  We're already on at least
>> 2.6.12.2, last I checked...
>>
>>> The reiser4progs-1.0.4 are not able to handle the format changes.
>>> The fix for reiser4progs will be ready next week.
>>
>>
>>
>> Will there be a conversion tool?
>>
>>
>
> No. Reiser4progs just will support a set of new plugins which have
> been added to the kernel.
> In particular, mkfs.reiser4 should allow user to specify the plugins
> like other existing
> ones. This will be a way to create cryptcompress files per superblock.
> There is another
> more flexible way (which is compatible with the previous one) to
> create it per file/directory,
> but it uses deprecated metas interface..
> Note: since cryptcompress plugin is unstable, the new options are
> supposed to be undocumented.
>
> Thanks,
> Edward.
>
>
>
So why does this create a format change that breaks things?  I cannot
see why it should do so, please explain.

We cannot change disk formats.  We promised that we would not.  Why did
this happen?  Did it have a good technical motivation or was it an
accident of coding.

This should not be done to users.

Hans

Re: reiser4progs do not handle the reiser4 format changes

[Gregory Maxwell]

On 7/20/05, Edward Shishkin <edward@namesys.com> wrote:
> like other existing
> ones. This will be a way to create cryptcompress files per superblock.
> There is another
> more flexible way (which is compatible with the previous one) to create
> it per file/directory,
> but it uses deprecated metas interface..

Per ... superblock?
Excuse me?

Nonselective use of this feature will be nearly useless. There must be
an API to selectively control the feature.

This sounds like a silly tantrum about the interface changes.

Re: reiser4progs do not handle the reiser4 format changes

[Hans Reiser]

Gregory Maxwell wrote:

>Nonselective use of this feature will be nearly useless. 
>
No, that is not true.  Most users are not interested in specifying per
file whether we can compress it.  So our plugin tries to compress the
first 64k, and if it fails to it assumes the file is not compressable. 
This is not always the correct thing, so being able to specify would be
nice, but it solves 80% of the problem, and that means we can deal with
the other 20% next year.

Hans

Re: reiser4progs do not handle the reiser4 format changes

[Edward Shishkin]

Hans Reiser wrote:

>Edward Shishkin wrote:
>
>  
>
>>David Masover wrote:
>>
>>    
>>
>>>E.Gryaznova wrote:
>>>
>>>      
>>>
>>>>Notification:
>>>>
>>>>The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new
>>>>reiser4 kernel code is able to handle the old format.
>>>>        
>>>>
>>>
>>>Good, so I don't have to reformat _immediately_...
>>>
>>>But, why isn't it for 2.6.12 yet?  We're already on at least
>>>2.6.12.2, last I checked...
>>>
>>>      
>>>
>>>>The reiser4progs-1.0.4 are not able to handle the format changes.
>>>>The fix for reiser4progs will be ready next week.
>>>>        
>>>>
>>>
>>>Will there be a conversion tool?
>>>
>>>
>>>      
>>>
>>No. Reiser4progs just will support a set of new plugins which have
>>been added to the kernel.
>>In particular, mkfs.reiser4 should allow user to specify the plugins
>>like other existing
>>ones. This will be a way to create cryptcompress files per superblock.
>>There is another
>>more flexible way (which is compatible with the previous one) to
>>create it per file/directory,
>>but it uses deprecated metas interface..
>>Note: since cryptcompress plugin is unstable, the new options are
>>supposed to be undocumented.
>>
>>Thanks,
>>Edward.
>>
>>
>>
>>    
>>
>So why does this create a format change that breaks things?  I cannot
>see why it should do so, please explain.
>  
>

I have lost a track who first called upgrading plugin_set by the terrible
words "disk format change". Plugin set is not a disk format, it is supposed
to be upgraded..

>We cannot change disk formats.  We promised that we would not.  Why did
>this happen?  Did it have a good technical motivation or was it an
>accident of coding.
>
>This should not be done to users.
>
>Hans
>
>
>  
>

Re: reiser4progs do not handle the reiser4 format changes

[David Masover]

Edward Shishkin wrote:
> Hans Reiser wrote:
> 
>> Edward Shishkin wrote:
>>
>>  
>>
>>> David Masover wrote:
>>>
>>>   
>>>
>>>> E.Gryaznova wrote:
>>>>
>>>>     
>>>>
>>>>> Notification:
>>>>>
>>>>> The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new
>>>>> reiser4 kernel code is able to handle the old format.
>>>>>       
>>>>
>>>>
>>>> Good, so I don't have to reformat _immediately_...
>>>>
>>>> But, why isn't it for 2.6.12 yet?  We're already on at least
>>>> 2.6.12.2, last I checked...
>>>>
>>>>     
>>>>
>>>>> The reiser4progs-1.0.4 are not able to handle the format changes.
>>>>> The fix for reiser4progs will be ready next week.
>>>>>       
>>>>
>>>>
>>>> Will there be a conversion tool?
>>>>
>>>>
>>>>     
>>>
>>> No. Reiser4progs just will support a set of new plugins which have
>>> been added to the kernel.
>>> In particular, mkfs.reiser4 should allow user to specify the plugins
>>> like other existing
>>> ones. This will be a way to create cryptcompress files per superblock.
>>> There is another
>>> more flexible way (which is compatible with the previous one) to
>>> create it per file/directory,
>>> but it uses deprecated metas interface..
>>> Note: since cryptcompress plugin is unstable, the new options are
>>> supposed to be undocumented.
>>>
>>> Thanks,
>>> Edward.
>>>
>>>
>>>
>>>   
>>
>> So why does this create a format change that breaks things?  I cannot
>> see why it should do so, please explain.
>>  
>>
> 
> I have lost a track who first called upgrading plugin_set by the terrible
> words "disk format change". Plugin set is not a disk format, it is supposed
> to be upgraded..

Ok, please explain what this actually means for users.

How will an FS made by the current reiser4progs be different than that 
made by the new (patched) ones that will be coming out?  Is the new way 
better?  If so, how can one take an existing FS and convert/update/tweak 
it to the new way?



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.9.2/55 - Release Date: 7/21/2005

Re: reiser4progs do not handle the reiser4 format changes

[Edward Shishkin]

David Masover wrote:

> Edward Shishkin wrote:
>
>> Hans Reiser wrote:
>>
>>> Edward Shishkin wrote:
>>>
>>>  
>>>
>>>> David Masover wrote:
>>>>
>>>>  
>>>>
>>>>> E.Gryaznova wrote:
>>>>>
>>>>>    
>>>>>
>>>>>> Notification:
>>>>>>
>>>>>> The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new
>>>>>> reiser4 kernel code is able to handle the old format.
>>>>>>       
>>>>>
>>>>>
>>>>>
>>>>> Good, so I don't have to reformat _immediately_...
>>>>>
>>>>> But, why isn't it for 2.6.12 yet?  We're already on at least
>>>>> 2.6.12.2, last I checked...
>>>>>
>>>>>    
>>>>>
>>>>>> The reiser4progs-1.0.4 are not able to handle the format changes.
>>>>>> The fix for reiser4progs will be ready next week.
>>>>>>       
>>>>>
>>>>>
>>>>>
>>>>> Will there be a conversion tool?
>>>>>
>>>>>
>>>>>     
>>>>
>>>>
>>>> No. Reiser4progs just will support a set of new plugins which have
>>>> been added to the kernel.
>>>> In particular, mkfs.reiser4 should allow user to specify the plugins
>>>> like other existing
>>>> ones. This will be a way to create cryptcompress files per superblock.
>>>> There is another
>>>> more flexible way (which is compatible with the previous one) to
>>>> create it per file/directory,
>>>> but it uses deprecated metas interface..
>>>> Note: since cryptcompress plugin is unstable, the new options are
>>>> supposed to be undocumented.
>>>>
>>>> Thanks,
>>>> Edward.
>>>>
>>>>
>>>>
>>>>   
>>>
>>>
>>> So why does this create a format change that breaks things?  I cannot
>>> see why it should do so, please explain.
>>>  
>>>
>>
>> I have lost a track who first called upgrading plugin_set by the 
>> terrible
>> words "disk format change". Plugin set is not a disk format, it is 
>> supposed
>> to be upgraded..
>
>
> Ok, please explain what this actually means for users.
>
> How will an FS made by the current reiser4progs be different than that 
> made by the new (patched) ones that will be coming out?  Is the new 
> way better?  If so, how can one take an existing FS and 
> convert/update/tweak it to the new way?
>

This is a common scenario:

Each disk reiser4 is supposed to be supported by all kernel/reiser4.
Both kernel and reiser4progs have a plugin table which should be 
upgraded in sync.
For each point A of upgrading the plugin table all reiser4progs of 
versions < A
become invalid for disk reiser4 being once mounted in the kernel/reiser4 
of version >= A.

Is it okay?
Perhaps introducing a special sub-versions of reiser4/reiser4progs for 
upgrading
the plugin table will improve the situation..


Edward.

>
>

Re: reiser4progs do not handle the reiser4 format changes

[Edward Shishkin]

Edward Shishkin wrote:

> David Masover wrote:
>
>>
>>
>> Ok, please explain what this actually means for users.
>>
>> How will an FS made by the current reiser4progs be different than 
>> that made by the new (patched) ones that will be coming out?  Is the 
>> new way better?  If so, how can one take an existing FS and 
>> convert/update/tweak it to the new way?
>>
>
> This is a common scenario:
>
> Each disk reiser4 is supposed to be supported by all kernel/reiser4.


I was wrong here: the only last version of kernel/reiser4 is able
to support _all_ disk file systems. Old kernels will refuse to mount
file systems of new versions with the warning about wrong plugin set
of root inode.

Edward.

>
> Both kernel and reiser4progs have a plugin table which should be 
> upgraded in sync.
> For each point A of upgrading the plugin table all reiser4progs of 
> versions < A
> become invalid for disk reiser4 being once mounted in the 
> kernel/reiser4 of version >= A.
>
> Is it okay?
> Perhaps introducing a special sub-versions of reiser4/reiser4progs for 
> upgrading
> the plugin table will improve the situation..
>
>
> Edward.
>
>>
>>
>
>
>

Re: reiser4progs do not handle the reiser4 format changes

[Vitaly Fertman]

On Sunday 24 July 2005 03:44, Edward Shishkin wrote:
> Edward Shishkin wrote:
> 
> > David Masover wrote:
> >
> >>
> >>
> >> Ok, please explain what this actually means for users.
> >>
> >> How will an FS made by the current reiser4progs be different than 
> >> that made by the new (patched) ones that will be coming out?  Is the 
> >> new way better?  If so, how can one take an existing FS and 
> >> convert/update/tweak it to the new way?
> >>
> >
> > This is a common scenario:
> >
> > Each disk reiser4 is supposed to be supported by all kernel/reiser4.
> 
> 
> I was wrong here: the only last version of kernel/reiser4 is able
> to support _all_ disk file systems. Old kernels will refuse to mount
> file systems of new versions with the warning about wrong plugin set
> of root inode.
> 
> Edward.
> 
> >
> > Both kernel and reiser4progs have a plugin table which should be 
> > upgraded in sync.
> > For each point A of upgrading the plugin table all reiser4progs of 
> > versions < A
> > become invalid for disk reiser4 being once mounted in the 
> > kernel/reiser4 of version >= A.
> >
> > Is it okay?
> > Perhaps introducing a special sub-versions of reiser4/reiser4progs for 
> > upgrading
> > the plugin table will improve the situation..

the reiser4progs obtained from 
ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.4-1.tar.gz
contain the fix to handle the extended plugin table correctly.

-- 
Thanks,
Vitaly Fertman