http://www.namesys.com/snapshots/2004.06.14-internal.testing/

http://www.namesys.com/snapshots/2004.06.14-internal.testing/

[Vitaly Fertman]

Hello All, 

This snapshot includes reiser4progs-0.5.5, libaal-0.5.2 and updated 
grub patch.

It supports object plugin sets, includes improved mount entry detection 
code and many other bugfixes.

stage1_5 reiser4 support in grub does not work (and probably will not 
anymore) because reiser4_stage1_5 code does not fit 23,5K size limit, 
even when all not nessesary plugins are disabled (disable-short-keys, 
disable-X-hash, disable-X_fibre, disable-symlinks, etc) on configuring.
Use stage2 instead.

When you run fsck.reiser4 on your old reiser4 filesystem it should report 
about missed plugin set members in the root directory. fsck should be able 
to fix it running with the --fix option.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.06.14-internal.testing/

[mjt]

On Tue, Jun 15, 2004 at 12:22:34AM +0400, Vitaly Fertman wrote:
>
>When you run fsck.reiser4 on your old reiser4 filesystem it should report 
>about missed plugin set members in the root directory. fsck should be able 
>to fix it running with the --fix option.

I tried this on the image I ran bonnie++ while fsck'ing on.
It suggested --rebuild-sb first, then I did --rebuild-sb --fix and
it worked.

Any ideas or caveats about how to handle my root partition with this?

Do I have to boot my emergency medevac partition and do --fix from there?

Thanks!

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.06.14-internal.testing/

[Vitaly Fertman]

On Tuesday 15 June 2004 01:05, Markus TЖrnqvist wrote:
> On Tue, Jun 15, 2004 at 12:22:34AM +0400, Vitaly Fertman wrote:
> >When you run fsck.reiser4 on your old reiser4 filesystem it should report
> >about missed plugin set members in the root directory. fsck should be able
> >to fix it running with the --fix option.
>
> I tried this on the image I ran bonnie++ while fsck'ing on.
> It suggested --rebuild-sb first, then I did --rebuild-sb --fix and
> it worked.
>
> Any ideas or caveats about how to handle my root partition with this?
>
> Do I have to boot my emergency medevac partition and do --fix from there?

or you can remount it ro, fsck, reboot. it should work also now.
-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.06.14-internal.testing/

[Vitaly Fertman]

On Tuesday 15 June 2004 00:22, Vitaly Fertman wrote:
> Hello All,
>
> This snapshot includes reiser4progs-0.5.5, libaal-0.5.2 and updated
> grub patch.
>
> It supports object plugin sets, includes improved mount entry detection
> code and many other bugfixes.
>
> stage1_5 reiser4 support in grub does not work (and probably will not
> anymore) because reiser4_stage1_5 code does not fit 23,5K size limit,
> even when all not nessesary plugins are disabled (disable-short-keys,
> disable-X-hash, disable-X_fibre, disable-symlinks, etc) on configuring.
> Use stage2 instead.
>
> When you run fsck.reiser4 on your old reiser4 filesystem it should report
> about missed plugin set members in the root directory. fsck should be able
> to fix it running with the --fix option.

remember that the latest 'stable' reiser4 snapshot (2004.03.26) does not 
support plugin sets, so use this internal progs snapshot with the last auto
reiser4 snapshots only.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.06.14-internal.testing/

[Sander Sweers]

<citaat van="Vitaly Fertman">
> On Tuesday 15 June 2004 00:22, Vitaly Fertman wrote:
>> Hello All,
>>
>> This snapshot includes reiser4progs-0.5.5, libaal-0.5.2 and updated
>> grub patch.
>>
>> stage1_5 reiser4 support in grub does not work (and probably will not
>> anymore) because reiser4_stage1_5 code does not fit 23,5K size limit,
>> even when all not nessesary plugins are disabled (disable-short-keys,
>> disable-X-hash, disable-X_fibre, disable-symlinks, etc) on configuring.
>> Use stage2 instead.
>
> remember that the latest 'stable' reiser4 snapshot (2004.03.26) does not
> support plugin sets, so use this internal progs snapshot with the last
> auto
> reiser4 snapshots only.
>
> --
> Thanks,
> Vitaly Fertman
>
>

I'm trying to build reiser4 support in grub but it ends with the following
error:

gcc -fno-pic -nopie -fno-stack-protector  -g   -o pre_stage2.exec
-nostdlib -Wl,-N -Wl,-Ttext -Wl,8200 pre_stage2_exec-asm.o
pre_stage2_exec-bios.o pre_stage2_exec-boot.o pre_stage2_exec-builtins.o
pre_stage2_exec-char_io.o pre_stage2_exec-cmdline.o
pre_stage2_exec-common.o pre_stage2_exec-console.o
pre_stage2_exec-disk_io.o pre_stage2_exec-fsys_ext2fs.o
pre_stage2_exec-fsys_fat.o pre_stage2_exec-fsys_ffs.o
pre_stage2_exec-fsys_jfs.o pre_stage2_exec-fsys_minix.o
pre_stage2_exec-fsys_reiserfs.o pre_stage2_exec-fsys_reiser4.o
pre_stage2_exec-fsys_vstafs.o pre_stage2_exec-fsys_xfs.o
pre_stage2_exec-gunzip.o pre_stage2_exec-hercules.o pre_stage2_exec-md5.o
pre_stage2_exec-serial.o pre_stage2_exec-smp-imps.o
pre_stage2_exec-stage2.o pre_stage2_exec-terminfo.o
pre_stage2_exec-tparm.o ../netboot/libdrivers.a -lreiser4-alone
-laal-alone
/lib/libaal-alone.a(libaal_alone_la-malloc.o)(.data+0x0): In function
`aal_mem_init':
/var/tmp/portage/libaal-0.5.2/work/libaal-0.5.2/src/malloc.c:189:
undefined reference to `free'
/lib/libaal-alone.a(libaal_alone_la-malloc.o)(.data+0x4): In function
`aal_mem_free':
/var/tmp/portage/libaal-0.5.2/work/libaal-0.5.2/src/malloc.c:196:
undefined reference to `malloc'
collect2: ld returned 1 exit status
make[2]: *** [pre_stage2.exec] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
`/var/tmp/portage/grub-0.94-r1/work/grub-0.94/stage2'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/grub-0.94-r1/work/grub-0.94'
make: *** [all] Error 2
----------
My system info:
Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.4.0, glibc-2.3.3.20040420-r0,
2.6.7-rc2-Redeeman1)
=================================================================
System uname: 2.6.7-rc2-Redeeman1 i686 AMD Athlon(tm) XP 1600+
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.58-r1
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-xp -mfpmath=sse -msse -mmmx -m3dnow -O3 -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="-march=athlon-xp -mfpmath=sse -msse -mmmx -m3dnow -O3 -pipe"

I have build reiser4progs and libaal with --enable-stand-alone.

Any ideas?
Thanks
Sander

Re: http://www.namesys.com/snapshots/2004.06.14-internal.testing/

[Vitaly Fertman]

> I'm trying to build reiser4 support in grub but it ends with the following
> error:
>
> /lib/libaal-alone.a(libaal_alone_la-malloc.o)(.data+0x0): In function
> `aal_mem_init':
> /var/tmp/portage/libaal-0.5.2/work/libaal-0.5.2/src/malloc.c:189:
> undefined reference to `free'
> /lib/libaal-alone.a(libaal_alone_la-malloc.o)(.data+0x4): In function
> `aal_mem_free':
> /var/tmp/portage/libaal-0.5.2/work/libaal-0.5.2/src/malloc.c:196:
> undefined reference to `malloc'
> collect2: ld returned 1 exit status
> make[2]: *** [pre_stage2.exec] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: Leaving directory
> `/var/tmp/portage/grub-0.94-r1/work/grub-0.94/stage2'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/var/tmp/portage/grub-0.94-r1/work/grub-0.94'
> make: *** [all] Error 2
> ----------
>
> I have build reiser4progs and libaal with --enable-stand-alone.

you should configure libaal with --enable-stand-alone --enable-memory-manager.
or you can implement your own memory methods and use them in stand-alone mode.

-- 
Thanks,
Vitaly Fertman

http://www.namesys.com/snapshots/2004.07.13-internal.testing/

[Vitaly Fertman]

Hello All,

This snapshot contains updated reiser4progs-0.5.6 and libaal-0.5.3.
Grub patch is the same.

It includes many bug fixes against the previous snapshot, also 
improved gauges and user wanrnings and some speedups.

and again, it should be used with the last auto reiser4 snapshots 
only as the latest 'stable' reiser4 snapshot (2004.03.26) does not 
support plugin sets in StatDatas.

-- 
Thanks,
Vitaly Fertman

[PATCH] Re: http://www.namesys.com/snapshots/2004.07.13-internal.testing/

[Philippe Gramoullé]

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


Hello Vitally,

I needed the following patch in order to compile reiser4progs-0.5.6 correctly.

Thanks,

Philippe

On Tue, 13 Jul 2004 14:27:58 +0400
Vitaly Fertman <vitaly@namesys.com> wrote:

  | Hello All,
  | 
  | This snapshot contains updated reiser4progs-0.5.6 and libaal-0.5.3.
  | Grub patch is the same.
  | 
  | It includes many bug fixes against the previous snapshot, also 
  | improved gauges and user wanrnings and some speedups.
  | 
  | and again, it should be used with the last auto reiser4 snapshots 
  | only as the latest 'stable' reiser4 snapshot (2004.03.26) does not 
  | support plugin sets in StatDatas.
  | 
  | -- 
  | Thanks,
  | Vitaly Fertman
  | 
  | 

[-- Attachment #2: gauge.c.diff --]
[-- Type: text/plain, Size: 324 bytes --]

--- gauge.c.orig	2004-07-13 12:51:10.000000000 +0200
+++ gauge.c	2004-07-13 12:50:00.000000000 +0200
@@ -4,7 +4,7 @@
    gauge.c -- common for all progs gauge metods. */
 
 #ifndef ENABLE_STAND_ALONE
-#include <aal/aal.h>
+#include <aal/libaal.h>
 #include <aux/gauge.h>
 
 aal_gauge_handler_t aux_gauge_handlers[GT_LAST];

Re: [PATCH] Re: http://www.namesys.com/snapshots/2004.07.13-internal.testing/

[Vitaly Fertman]

On Tuesday 13 July 2004 14:54, Philippe Gramoullé wrote:
> Hello Vitally,
>
> I needed the following patch in order to compile reiser4progs-0.5.6
> correctly.
>
> Thanks,
>
> Philippe

ah, the patch for libaux/gauge.c, right. It found very old 
ocasionally not uninstalled aal.h in my tests.
-- 
Thanks,
Vitaly Fertman

http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Vitaly Fertman]

Hello All,

This snapshot contains updated reiser4progs-0.5.7 and the grub patch.

It includes several bug fixes against the previous snapshot, and has a disk 
format change -- the layout of blocks that contain backuped fs metadata 
are changed. 

No kernel patch is needed for the disk format change, however fsck may 
report about some corruptions on an existent fs if a block was allocated 
for some data and has become a backup one. Fsck.reiser4 --build-fs is 
able to fix it of course, although the data in these blocks are lost then.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Tue, Aug 03, 2004 at 05:50:00PM +0400, Vitaly Fertman wrote:
>No kernel patch is needed for the disk format change, however fsck may 
>report about some corruptions on an existent fs if a block was allocated 
>for some data and has become a backup one. Fsck.reiser4 --build-fs is 
>able to fix it of course, although the data in these blocks are lost then.

What kind of probabilities and amounts of data are we talking about?

Thanks!

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Vitaly Fertman]

On Tuesday 03 August 2004 17:58, Markus Törnqvist wrote:
> On Tue, Aug 03, 2004 at 05:50:00PM +0400, Vitaly Fertman wrote:
> >No kernel patch is needed for the disk format change, however fsck may
> >report about some corruptions on an existent fs if a block was allocated
> >for some data and has become a backup one. Fsck.reiser4 --build-fs is
> >able to fix it of course, although the data in these blocks are lost then.
>
> What kind of probabilities and amounts of data are we talking about?

The first gig has 22 backup blocks and they are distributed expotentially.
The first backup copy was probably almost always used for other needs.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Thomas Graham]

how long does it take to build-fs for 200GB data HD ? and how many data am
I going to lost ?

I am just freak out, you guys are promised that disk format wouldn't be
change anymore, but it still changing actually, pretty upset for that
statement.

> Hello All,
>
> This snapshot contains updated reiser4progs-0.5.7 and the grub patch.
>
> It includes several bug fixes against the previous snapshot, and has a
> disk
> format change -- the layout of blocks that contain backuped fs metadata
> are changed.
>
> No kernel patch is needed for the disk format change, however fsck may
> report about some corruptions on an existent fs if a block was allocated
> for some data and has become a backup one. Fsck.reiser4 --build-fs is
> able to fix it of course, although the data in these blocks are lost then.
>
> --
> Thanks,
> Vitaly Fertman
>
>


-- 
HK Celtic Orchestra leader and coordanator: Thomas Graham Lau
Phone number: 852-93239670    (24hours a day, 7days a week non-stop phone)
Web site: http://sml.dyndns.org
Email: lkthomas@sml.dyndns.org

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Hans Reiser]

Thomas Graham wrote:

>how long does it take to build-fs for 200GB data HD ? and how many data am
>I going to lost ?
>
>I am just freak out, you guys are promised that disk format wouldn't be
>change anymore, but it still changing actually, pretty upset for that
>statement.
>
>  
>
>>Hello All,
>>
>>This snapshot contains updated reiser4progs-0.5.7 and the grub patch.
>>
>>It includes several bug fixes against the previous snapshot, and has a
>>disk
>>format change -- the layout of blocks that contain backuped fs metadata
>>are changed.
>>
>>No kernel patch is needed for the disk format change, however fsck may
>>report about some corruptions on an existent fs if a block was allocated
>>for some data and has become a backup one. Fsck.reiser4 --build-fs is
>>able to fix it of course, although the data in these blocks are lost then.
>>
>>--
>>Thanks,
>>Vitaly Fertman
>>
>>
>>    
>>
>
>
>  
>
Vitaly, your email is a marvel of unclarity that vaguely threatens of 
losing data in ways that cannot be understood by the reader.  Please 
revise and resend, and don't make disk format changes in the future 
without discussing them with the rest of the team first.  Perhaps you 
should start that discussion of this disk format change now....

Hans

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Hans Reiser]

Vitaly Fertman wrote:

>On Tuesday 03 August 2004 17:58, Markus Törnqvist wrote:
>  
>
>>On Tue, Aug 03, 2004 at 05:50:00PM +0400, Vitaly Fertman wrote:
>>    
>>
>>>No kernel patch is needed for the disk format change, however fsck may
>>>report about some corruptions on an existent fs if a block was allocated
>>>for some data and has become a backup one. Fsck.reiser4 --build-fs is
>>>able to fix it of course, although the data in these blocks are lost then.
>>>      
>>>
These blocks refers to blocks that were used by files and are now backup 
super blocks?  These blocks could be critical database files, etc.?

If yes, then please pull this off our website until you come up with a 
scheme that I am sure will not create more user problems than it solves, 
on average.

>>What kind of probabilities and amounts of data are we talking about?
>>    
>>
>
>The first gig has 22 backup blocks and they are distributed expotentially.
>The first backup copy was probably almost always used for other needs.
>
>  
>

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Wed, Aug 04, 2004 at 01:51:22AM -0700, Hans Reiser wrote:

>These blocks refers to blocks that were used by files and are now backup 
>super blocks?  These blocks could be critical database files, etc.?

Seems to me like yes, but Reiser4 hasn't launched yet officially, so
I somehow doubt people will have anything too critical on Reiser4.

I'm at least preparing myself to take backups of everything.

>If yes, then please pull this off our website until you come up with a 
>scheme that I am sure will not create more user problems than it solves, 
>on average.

Yeah, there is the other hand that said that the online format is
now set in stone...

Still the important question is, what's the net gain of this new format?

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Vitaly Fertman]

On Wednesday 04 August 2004 12:44, Hans Reiser wrote:
> Thomas Graham wrote:
> >how long does it take to build-fs for 200GB data HD ? and how many data am
> >I going to lost ?
> >
> >I am just freak out, you guys are promised that disk format wouldn't be
> >change anymore, but it still changing actually, pretty upset for that
> >statement.
> >
> >>Hello All,
> >>
> >>This snapshot contains updated reiser4progs-0.5.7 and the grub patch.
> >>
> >>It includes several bug fixes against the previous snapshot, and has a
> >>disk
> >>format change -- the layout of blocks that contain backuped fs metadata
> >>are changed.
> >>
> >>No kernel patch is needed for the disk format change, however fsck may
> >>report about some corruptions on an existent fs if a block was allocated
> >>for some data and has become a backup one. Fsck.reiser4 --build-fs is
> >>able to fix it of course, although the data in these blocks are lost
> >> then.
> >>
> >>--
> >>Thanks,
> >>Vitaly Fertman
>
> Vitaly, your email is a marvel of unclarity that vaguely threatens of
> losing data in ways that cannot be understood by the reader.  Please
> revise and resend, 

these blocks could be allocated for the reiser4 storage tree or user data. 
now they are backup super blocks. if run fsck --build-fs, it recovers the 
backup data in these blocks currently, so the previousely stored tree data 
will be lost.

> and don't make disk format changes in the future
> without discussing them with the rest of the team first.  Perhaps you
> should start that discussion of this disk format change now....

it was discussed many times already, and I mentioned about it in dev 
list many times also, e.g. the last email about it was 'format change in 
the backup layout' from 28/07/04. Btw, You agreed with this backup
layout scheem in the 'Reiser4 on-disk format' discussion more then a 
month ago.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Wed, Aug 04, 2004 at 02:16:17PM +0400, Vitaly Fertman wrote:

>these blocks could be allocated for the reiser4 storage tree or user data. 
>now they are backup super blocks. if run fsck --build-fs, it recovers the 
>backup data in these blocks currently, so the previousely stored tree data 
>will be lost.

Would it not be possible to backup the content of these blocks and
attach them (or the content) somewhere else without data loss?

>it was discussed many times already, and I mentioned about it in dev 
>list many times also, e.g. the last email about it was 'format change in 
>the backup layout' from 28/07/04. Btw, You agreed with this backup
>layout scheem in the 'Reiser4 on-disk format' discussion more then a 
>month ago.

Were it possible to have the reiserfs-dev list archived on the web, or
read-only subscription access or something?

It'd be nice to have an early warning about these things....

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Vitaly Fertman]

On Wednesday 04 August 2004 13:55, Markus Törnqvist wrote:
> On Wed, Aug 04, 2004 at 01:51:22AM -0700, Hans Reiser wrote:
> >These blocks refers to blocks that were used by files and are now backup
> >super blocks?  These blocks could be critical database files, etc.?
>
> Seems to me like yes, but Reiser4 hasn't launched yet officially, so
> I somehow doubt people will have anything too critical on Reiser4.
>
> I'm at least preparing myself to take backups of everything.
>
> >If yes, then please pull this off our website until you come up with a
> >scheme that I am sure will not create more user problems than it solves,
> >on average.
>
> Yeah, there is the other hand that said that the online format is
> now set in stone...
>
> Still the important question is, what's the net gain of this new format?

the previous bakup layout had backup block locations depending on the fs 
size, in other words every resize operation may need to relocate some nodes 
in the tree to other blocks if the current ones are needed for the backup -- 
even on expanding. there are no such problems with the current backup layout.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Wed, Aug 04, 2004 at 02:34:41PM +0400, Vitaly Fertman wrote:

>the previous bakup layout had backup block locations depending on the fs 
>size, in other words every resize operation may need to relocate some nodes 
>in the tree to other blocks if the current ones are needed for the backup -- 
>even on expanding. there are no such problems with the current backup layout.

OK, this is a good enough motivation.

But does it have to be done here with fsck with data loss, is there no
other way around?

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Philippe Gramoullé]

Hello,

On Wed, 4 Aug 2004 12:55:13 +0300
mjt@nysv.org (Markus Törnqvist) wrote:

  | >These blocks refers to blocks that were used by files and are now backup 
  | >super blocks?  These blocks could be critical database files, etc.?
  | 
  | Seems to me like yes, but Reiser4 hasn't launched yet officially, so
  | I somehow doubt people will have anything too critical on Reiser4.
  | 
  | I'm at least preparing myself to take backups of everything.


I completely agree. I really don't mind having another tens of format disk change, if it make things better
faster, or cleaner. If people currently use reiser4 in production for mission critical applications, without any backups,
well..., let's say that they had a bet and they lost :)

As Markus said, Reiser4 hasn't been officially released, so i'm all for format disk change if it improves things in the end
and even if few people might get burnt with that.

Thanks,

Philippe

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Vitaly Fertman]

On Wednesday 04 August 2004 14:52, Markus Törnqvist wrote:
> On Wed, Aug 04, 2004 at 02:34:41PM +0400, Vitaly Fertman wrote:
> >the previous bakup layout had backup block locations depending on the fs
> >size, in other words every resize operation may need to relocate some
> > nodes in the tree to other blocks if the current ones are needed for the
> > backup -- even on expanding. there are no such problems with the current
> > backup layout.
>
> OK, this is a good enough motivation.
>
> But does it have to be done here with fsck with data loss, is there no
> other way around?

1) copy data off, mkfs or fsck, copy data back ;
2) a convertion program. The one I have been writing is not finished yet.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Wed, Aug 04, 2004 at 02:41:44PM +0200, Philippe Gramoull? wrote:
>As Markus said, Reiser4 hasn't been officially released, so i'm all for format disk change if it improves things in the end
>and even if few people might get burnt with that.

For now, I just hope no one jumps the gun and fscks with the new
tools, unless they REALLY have to.

Point is, maybe the block could be relocated without data loss?
Is that not much more elegant a solution?

I'm at least waiting for Vitaly to comment on this issue, if it really
is too difficult or impossible, then we all risk data loss.
C'est la software beta.

But even if there was some misunderstanding between Vitaly and Hans
about data loss (Hans did say that there will be no inelegant format
changes), the new backup layout sounds like a reasonable and good idea.

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Wed, Aug 04, 2004 at 04:49:38PM +0400, Vitaly Fertman wrote:
>1) copy data off, mkfs or fsck, copy data back ;
>2) a convertion program. The one I have been writing is not finished yet.

Then all I can say is, please, please, please remove the disk format
change from the fsck as soon as you can, because people will want
to fsck their disks without data loss.

Hans asked to take the programs away, I agree, if a convertion program
is coming. Also there are bugfixes, which should be released, so maybe
re-release the progs without fsck converting backup blocks...

You could then release the convertion program separately or include
it in the next reiser4progs package.

Do you think this is possible for the common good?

Thanks!

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Chris Mason]

On Wed, 2004-08-04 at 08:41, Philippe Gramoullé wrote:
> Hello,
> 
> On Wed, 4 Aug 2004 12:55:13 +0300
> mjt@nysv.org (Markus Törnqvist) wrote:
> 
>   | >These blocks refers to blocks that were used by files and are now backup 
>   | >super blocks?  These blocks could be critical database files, etc.?
>   | 
>   | Seems to me like yes, but Reiser4 hasn't launched yet officially, so
>   | I somehow doubt people will have anything too critical on Reiser4.
>   | 
>   | I'm at least preparing myself to take backups of everything.
> 
> 
> I completely agree. I really don't mind having another tens of format disk change, if it make things better
> faster, or cleaner. If people currently use reiser4 in production for mission critical applications, without any backups,
> well..., let's say that they had a bet and they lost :)
> 
> As Markus said, Reiser4 hasn't been officially released, so i'm all for format disk change if it improves things in the end
> and even if few people might get burnt with that.

If it provides some significant benefit, make the format change now. 
Whatever gets into the kernel you'll be stuck with ;-)

-chris

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Thomas Graham]

if a convertor are not done yet, I think we could wait until it's bundle
into the .tar.gz and we could use it, actually, do we HAVE TO do that
format changes ? or normal user could just ignore that except for some of
them who reach problem with that ?

> On Wed, 2004-08-04 at 08:41, Philippe Gramoullé wrote:
>> Hello,
>>
>> On Wed, 4 Aug 2004 12:55:13 +0300
>> mjt@nysv.org (Markus Törnqvist) wrote:
>>
>>   | >These blocks refers to blocks that were used by files and are now
>> backup
>>   | >super blocks?  These blocks could be critical database files, etc.?
>>   |
>>   | Seems to me like yes, but Reiser4 hasn't launched yet officially, so
>>   | I somehow doubt people will have anything too critical on Reiser4.
>>   |
>>   | I'm at least preparing myself to take backups of everything.
>>
>>
>> I completely agree. I really don't mind having another tens of format
>> disk change, if it make things better
>> faster, or cleaner. If people currently use reiser4 in production for
>> mission critical applications, without any backups,
>> well..., let's say that they had a bet and they lost :)
>>
>> As Markus said, Reiser4 hasn't been officially released, so i'm all for
>> format disk change if it improves things in the end
>> and even if few people might get burnt with that.
>
> If it provides some significant benefit, make the format change now.
> Whatever gets into the kernel you'll be stuck with ;-)
>
> -chris
>
>
>


-- 
HK Celtic Orchestra leader and coordanator: Thomas Graham Lau
Phone number: 852-93239670    (24hours a day, 7days a week non-stop phone)
Web site: http://sml.dyndns.org
Email: lkthomas@sml.dyndns.org

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Wed, Aug 04, 2004 at 10:16:26PM +0800, Thomas Graham wrote:
>if a convertor are not done yet, I think we could wait until it's bundle
>into the .tar.gz and we could use it, actually, do we HAVE TO do that
>format changes ? or normal user could just ignore that except for some of
>them who reach problem with that ?

I don't think you HAVE to do it, if you would, there would be a compensation
in the kernel, and Vitaly said there is not.

So just avoid the reiser4progs like the plague, call the Namesys helpdesk,
whatever and ask Vitaly to remove the file from the web, remove the
code that changes the format, whatever.

I just hope I won't hit a corruptive bug on my machine, it would be pretty
anticlimactic if I did and I would lose data because it decides to
change the format.

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Hans Reiser]

Markus Törnqvist wrote:

>On Wed, Aug 04, 2004 at 10:16:26PM +0800, Thomas Graham wrote:
>  
>
>>if a convertor are not done yet, I think we could wait until it's bundle
>>into the .tar.gz and we could use it, actually, do we HAVE TO do that
>>format changes ? or normal user could just ignore that except for some of
>>them who reach problem with that ?
>>    
>>
>
>I don't think you HAVE to do it, if you would, there would be a compensation
>in the kernel, and Vitaly said there is not.
>
>So just avoid the reiser4progs like the plague, call the Namesys helpdesk,
>whatever and ask Vitaly to remove the file from the web, remove the
>code that changes the format, whatever.
>
>I just hope I won't hit a corruptive bug on my machine, it would be pretty
>anticlimactic if I did and I would lose data because it decides to
>change the format.
>
>  
>
I don't understand why Vitaly cannot do one of the things suggested on 
this thread: create an fsck option for people like Markus to use.

If Vitaly does that, problem solved, yes?

Chris is right that any disk format changes need to be made now.  
Vitaly, send an email defining what you propose to do, and cc the list.  
Do that now please.

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[mjt]

On Wed, Aug 04, 2004 at 10:47:35AM -0700, Hans Reiser wrote:
>I don't understand why Vitaly cannot do one of the things suggested on 
>this thread: create an fsck option for people like Markus to use.
>If Vitaly does that, problem solved, yes?

Yes.

It's my opinion that if it can be done silently by fsck, it's the best
thing.

But I think we're beating a dead horse (if you say that in English as
well) here. Let's just make this filesystem rock :)

-- 
mjt

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Vitaly Fertman]

On Wednesday 04 August 2004 21:47, Hans Reiser wrote:
> Markus Törnqvist wrote:
> >On Wed, Aug 04, 2004 at 10:16:26PM +0800, Thomas Graham wrote:
> >>if a convertor are not done yet, I think we could wait until it's bundle
> >>into the .tar.gz and we could use it, actually, do we HAVE TO do that
> >>format changes ? or normal user could just ignore that except for some of
> >>them who reach problem with that ?
> >
> >I don't think you HAVE to do it, if you would, there would be a
> > compensation in the kernel, and Vitaly said there is not.
> >
> >So just avoid the reiser4progs like the plague, call the Namesys helpdesk,
> >whatever and ask Vitaly to remove the file from the web, remove the
> >code that changes the format, whatever.
> >
> >I just hope I won't hit a corruptive bug on my machine, it would be pretty
> >anticlimactic if I did and I would lose data because it decides to
> >change the format.
>
> I don't understand why Vitaly cannot do one of the things suggested on
> this thread: create an fsck option for people like Markus to use.
>
> If Vitaly does that, problem solved, yes?
>
> Chris is right that any disk format changes need to be made now.
> Vitaly, send an email defining what you propose to do, and cc the list.
> Do that now please.

I have written a converter (an option to debugfs), testing it, 
it does well for the last half an hout already. 

I am going to release another internal snapshot with the explanation 
in README how to use it.

-- 
Thanks,
Vitaly Fertman

Re: http://www.namesys.com/snapshots/2004.08.03-internal.testing/

[Hans Reiser]

Vitaly Fertman wrote:

>On Wednesday 04 August 2004 21:47, Hans Reiser wrote:
>  
>
>>Markus TЖrnqvist wrote:
>>    
>>
>>>On Wed, Aug 04, 2004 at 10:16:26PM +0800, Thomas Graham wrote:
>>>      
>>>
>>>>if a convertor are not done yet, I think we could wait until it's bundle
>>>>into the .tar.gz and we could use it, actually, do we HAVE TO do that
>>>>format changes ? or normal user could just ignore that except for some of
>>>>them who reach problem with that ?
>>>>        
>>>>
>>>I don't think you HAVE to do it, if you would, there would be a
>>>compensation in the kernel, and Vitaly said there is not.
>>>
>>>So just avoid the reiser4progs like the plague, call the Namesys helpdesk,
>>>whatever and ask Vitaly to remove the file from the web, remove the
>>>code that changes the format, whatever.
>>>
>>>I just hope I won't hit a corruptive bug on my machine, it would be pretty
>>>anticlimactic if I did and I would lose data because it decides to
>>>change the format.
>>>      
>>>
>>I don't understand why Vitaly cannot do one of the things suggested on
>>this thread: create an fsck option for people like Markus to use.
>>
>>If Vitaly does that, problem solved, yes?
>>
>>Chris is right that any disk format changes need to be made now.
>>Vitaly, send an email defining what you propose to do, and cc the list.
>>Do that now please.
>>    
>>
>
>I have written a converter (an option to debugfs), testing it, 
>it does well for the last half an hout already. 
>
>I am going to release another internal snapshot with the explanation 
>in README how to use it.
>
>  
>
good answer.

http://www.namesys.com/snapshots/2004.08.09-internal.testing/

[Vitaly Fertman]

Hello All,

This snapshot contains what was included into 2004.08.03-internal.testing 
snapshot:

> updated reiser4progs-0.5.7 and the grub patch.
> 
> It includes several bug fixes against the previous snapshot, and has a disk 
> format change -- the layout of blocks that contain backuped fs metadata 
> are changed. 
> 
> No kernel patch is needed for the disk format change, however fsck may 
> report about some corruptions on an existent fs if a block was allocated 
> for some data and has become a backup one. Fsck.reiser4 --build-fs is 
> able to fix it of course, although the data in these blocks are lost then.

and it has a converter from the previous format to the new one -- if you 
already created a reiser4 fs with the mkfs from some previous version 
of reiser4progs, first of all run 
    $ debugfs.reiser4 -C device

-- 
Thanks,
Vitaly Fertman