Hello!
Attached is the patch that reserves space for volume label and UUID in reiserfs v3.6 superblock.
It also generates random UUID for volumes converted from 3.5 to 3.6 format by the kernel.
Original patch author is Andreas Dilger <[email protected]>.
Please apply.
Bye,
Oleg
On Wednesday, January 09, 2002 03:55:04 PM +0300 Oleg Drokin
<[email protected]> wrote:
> Hello!
>
> Attached is the patch that reserves space for volume label and UUID
> in reiserfs v3.6 superblock. It also generates random UUID for
> volumes converted from 3.5 to 3.6 format by the kernel. Original
> patch author is Andreas Dilger <[email protected]>. Please apply.
This should not be applied until an updated (non beta) reiserfsprogs
package that supports these features has been released.
-chris
Hello!
On Wed, Jan 09, 2002 at 10:47:59AM -0500, Chris Mason wrote:
> > Attached is the patch that reserves space for volume label and UUID
> > in reiserfs v3.6 superblock. It also generates random UUID for
> > volumes converted from 3.5 to 3.6 format by the kernel. Original
> > patch author is Andreas Dilger <[email protected]>. Please apply.
> This should not be applied until an updated (non beta) reiserfsprogs
> package that supports these features has been released.
Hey, reserving some space in superblock won't hurt.
And when actual reiserfsprogs and util-linux support will appear, people will just start to use these features.
On the other side, if tools supporting this stuff will get out earlier than kernel support, bad things may happen.
And Hans is thinking that time for this patch is right, too.
Bye,
Oleg
On Wednesday, January 09, 2002 06:58:26 PM +0300 Oleg Drokin
<[email protected]> wrote:
> Hello!
>
> On Wed, Jan 09, 2002 at 10:47:59AM -0500, Chris Mason wrote:
>
>> > Attached is the patch that reserves space for volume label and UUID
>> > in reiserfs v3.6 superblock. It also generates random UUID for
>> > volumes converted from 3.5 to 3.6 format by the kernel. Original
>> > patch author is Andreas Dilger <[email protected]>. Please
>> > apply.
>> This should not be applied until an updated (non beta) reiserfsprogs
>> package that supports these features has been released.
> Hey, reserving some space in superblock won't hurt.
Reserving it is fine ;-) Using it isn't a good idea until the progs
understand it. Our policy should be to never require a progs update in a
stable kernel series (just like most stable parts of the kernel).
But, the progs are improving so quickly that we should bend this rule a
little bit. Another example is the unlink truncate patch never should have
been sent to Marcelo without a non-beta reiserfsprogs that understood it.
Neither should this patch (even though it is a much smaller problem).
-chris
Hello!
On Wed, Jan 09, 2002 at 11:07:29AM -0500, Chris Mason wrote:
> >> This should not be applied until an updated (non beta) reiserfsprogs
> >> package that supports these features has been released.
> > Hey, reserving some space in superblock won't hurt.
> Reserving it is fine ;-) Using it isn't a good idea until the progs
So we did it (reserved) ;)
We do not use it. (generating of UUID does not count)
> understand it. Our policy should be to never require a progs update in a
> stable kernel series (just like most stable parts of the kernel).
We do not require progs upadte. But if someone will update their progs voluntarily,
we cannot forbit them to! ;))
> Neither should this patch (even though it is a much smaller problem).
You just said that reserving is ok.
Bye,
Oleg
On Wednesday, January 09, 2002 07:25:26 PM +0300 Oleg Drokin
<[email protected]> wrote:
> Hello!
>
> On Wed, Jan 09, 2002 at 11:07:29AM -0500, Chris Mason wrote:
>
>> >> This should not be applied until an updated (non beta) reiserfsprogs
>> >> package that supports these features has been released.
>> > Hey, reserving some space in superblock won't hurt.
>> Reserving it is fine ;-) Using it isn't a good idea until the progs
> So we did it (reserved) ;)
> We do not use it. (generating of UUID does not count)
Yes, generating a uuid and storing in the super block counts as using the
field ;-)
>
>> understand it. Our policy should be to never require a progs update in a
>> stable kernel series (just like most stable parts of the kernel).
> We do not require progs upadte. But if someone will update their progs
> voluntarily, we cannot forbit them to! ;))
>
The point is that we should never add something to the kernel until our
utils package understands it. Yes, this is a simple case, but if we want
to call reiserfs stable, there are some basic rules we need to start
following.
-chris
Hello!
On Wed, Jan 09, 2002 at 11:38:32AM -0500, Chris Mason wrote:
> >> >> This should not be applied until an updated (non beta) reiserfsprogs
> >> >> package that supports these features has been released.
> >> > Hey, reserving some space in superblock won't hurt.
> >> Reserving it is fine ;-) Using it isn't a good idea until the progs
> > So we did it (reserved) ;)
> > We do not use it. (generating of UUID does not count)
> Yes, generating a uuid and storing in the super block counts as using the
> field ;-)
Does filling something with zeroes counts as "using the field"? ;)
> The point is that we should never add something to the kernel until our
> utils package understands it. Yes, this is a simple case, but if we want
In fact, current reiserfsprogs understands these fields (look into the the struct super_block definition in
reiserfsprogs). It just cannot change content of the fields.
> to call reiserfs stable, there are some basic rules we need to start
> following.
Sure.
Bye,
Oleg
On Wednesday, January 09, 2002 07:44:30 PM +0300 Oleg Drokin
<[email protected]> wrote:
> Does filling something with zeroes counts as "using the field"? ;)
We must be reading different versions of generate_random_uuid ;-)
>
>> The point is that we should never add something to the kernel until our
>> utils package understands it. Yes, this is a simple case, but if we want
> In fact, current reiserfsprogs understands these fields (look into the
> the struct super_block definition in reiserfsprogs). It just cannot
> change content of the fields.
/* Structure of super block on disk */
struct reiserfs_super_block
{
/* 0 */ struct reiserfs_super_block_v1 s_v1;
/* 76 */ char sb_mnt_version[16];
/* 92 */ char sb_mkfs_version[16];
/*108 */ char sb_fsck_version[16];
/*124 */ char sb_unused[204-16-16-16-SB_SIZE_V1] ;
/* zero filled by mkreiserfs */ };
Show me the part where it knows what a uuid is. It should at least be able
to show the uuid set by the kernel.
Please don't take this the wrong way, this is a good (and simple) patch
that adds a cool feature. We just need to do a better job of having the
utils support the features before sending the patch it. It does a better
job of proving we've tested the feature and that kernel patch fully meets
our needs.
-chris
Hello!
On Wed, Jan 09, 2002 at 12:14:28PM -0500, Chris Mason wrote:
> > In fact, current reiserfsprogs understands these fields (look into the
> > the struct super_block definition in reiserfsprogs). It just cannot
> > change content of the fields.
> /* Structure of super block on disk */
> struct reiserfs_super_block
> {
> /* 0 */ struct reiserfs_super_block_v1 s_v1;
> /* 76 */ char sb_mnt_version[16];
> /* 92 */ char sb_mkfs_version[16];
> /*108 */ char sb_fsck_version[16];
> /*124 */ char sb_unused[204-16-16-16-SB_SIZE_V1] ;
> /* zero filled by mkreiserfs */ };
> Show me the part where it knows what a uuid is. It should at least be able
> to show the uuid set by the kernel.
It does not know about uuid per se, but it know in that area some text data is stored.
(BTW, we are started to fix reiserfsprogs, so that struct superblock will be the same in kernel and in reiserfsprogs.
It is already almost close in cvs ;) )
I see MArcello have not applied this patch to 2.4.18-pre3, so we have some more time to prepare reiserfsprogs ;)
Bye,
Oleg