Re: reiser4 resize
> that was not a working program. > I never looked too far into that issue, because I didn't need it back then. > I think you should change to a filesystem which has resize. > I guess this means that I'll won't use reiser4 again until 2 TB drives come out and I upgrade. Maybe by then reiser4 will be included in the kernel and files-as-directory will work :)
reiser4 resize
Short summary: Will a resize program for reiser4 be available within the next six months? Long explanation: I use a 3ware SATA raid card for the main storage on my home network. I currently have 8 250 GB drives in a raid 5 + hot spare configuration. I chose this card because it allows for online capacity expansion. My plan was to wait until a few generations of hard drives emerged then upgrade them one at a time in cycles. This way my storage will periodically expand without any major downtime. When I first created the filesystem, there was a reiser4 resize program. This is no longer the case. I've began my next upgrade cycle with the purchase of two 750 GB drives. I plan to buy one each month until all eight are replaced. Now I need to make a decision. Do I backup my raid onto the new drives and reformat my raid with another filesystem (xfs, reiser3, jfs), or do I put these new drives into the array and assume that when the time comes to resize the filesystem that a working program will exist?
Re: can not compile reiser4
I don't understand how the patch could be the problem. It doesn't change
anything in the fs/reiser4 directory at all. The file that won't compile is
fs/reiser4/entd.c, which is the most recent version from
bk://bk.namesys.com/bk/reiser4
- Original Message -
From: "Marcelo Pacheco" <[EMAIL PROTECTED]>
To: "Jack Byer" <[EMAIL PROTECTED]>
Sent: Sunday, August 10, 2003 2:27 PM
Subject: Re: can not compile reiser4
> That patch is old and outdated.
> All you need is on the bk trees, except for the attached small compilation
patch that namesys hasn't took action yet.
>
> Marcelo
>
> On Sunday 10 August 2003 13:35, Jack Byer wrote:
> > I'm trying to compile a 2.6.0-test2 kernel with reiser4 on a spare
system.
> > I downloaded the latest reiser 4 sources from bitkeeper into the fs
> > directory of a vanilla 2.6.0-test2 tree using the instructions on your
web
> > site ( bk clone bk://bk.namesys.com/bk/reiser4)
> > Then I applied the 2.6.0-test2-reiser4-2.6.0-test2.diff patch from your
ftp
> > site.
> > When I try to compile, I get the following error:
> >
> > CC fs/reiser4/entd.o
> > In file included from include/asm/hardirq.h:6,
> > from fs/reiser4/debug.h:17,
> > from fs/reiser4/entd.c:5:
> > include/linux/irq.h:69: warning: size of `irq_desc' is 28672 bytes
> > fs/reiser4/entd.c: In function `wait_for_flush':
> > fs/reiser4/entd.c:387: structure has no member named `pressure'
> > make[2]: *** [fs/reiser4/entd.o] Error 1
> > make[1]: *** [fs/reiser4] Error 2
> > make: *** [fs] Error 2
> >
> > Also, the "size of `irq_desc' is 28672 bytes" warning was printed for
every
> > file in the reiser4 directory up to that point.
>
> linux 2.6.0 and reiser4 (patch/bugfix)
> Date: 2003-08-02 07:58
> From: "Pillars.NET" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> Figured out how to use bk to pull in the latest trees from
> linux.bkbits.net and bk.namesys.com and merge the two.
>
> Tried compiling a linux 2.6.0-test2 kernel with reiser4 built-in (not
> as a module)
>
> Ran into a compile-time error: "undefined reference to _udivdi3",
> which is described by one LKML author as "somebody is doing a 64-bit
> integer divide without pulling in the relevant gcc library."
>
> Poked around and found in "include/div64.h" a helper function called
> "div_long_long_rem" which appears to be custom-made for this type of
> problem.
>
> Here's what I changed to make the compiler happy:
>
> [EMAIL PROTECTED]:/usr/src/linux-2.6.0# diff -u
fs/reiser4/plugin/item/ctail.c.orig fs/reiser4/plugin/item/ctail.c
> --- ctail.c.orig2003-08-02 06:53:07.0 -0400
> +++ fs/reiser4/plugin/item/ctail.c 2003-08-02
06:41:15.0 -0400
> @@ -55,7 +55,8 @@
> cluster_index_by_coord(const coord_t * coord)
> {
> reiser4_key key;
> - return get_key_offset(item_key_by_coord(coord, &key)) /
cluster_size_by_coord(coord),&rem;
> + unsigned long rem;
> + return div_long_long_rem(get_key_offset(item_key_by_coord(coord,
&key)),cluster_size_by_coord(coord),&rem);
> }
>
> static char *
> @@ -764,13 +765,14 @@
> utmost_child_ctail(const coord_t * coord, sideof side, jnode ** child)
> {
> reiser4_key key;
> + long unsigned rem;
>
> assert("edward-257", coord != NULL);
> assert("edward-258", child != NULL);
> assert("edward-259", side == LEFT_SIDE);
> assert("edward-260", item_plugin_by_coord(coord) ==
item_plugin_by_id(CTAIL_ID));
>
> - if (get_key_offset(&key) != cluster_size_by_coord(coord) *
(get_key_offset(&key) / cluster_size_by_coord(coord)))
> + if (get_key_offset(&key) != cluster_size_by_coord(coord) *
div_long_long_rem(get_key_offset(&key),cluster_size_by_coord(coord),&rem))
> *child = NULL;
> else
> *child = jlook_lock(current_tree,
get_key_objectid(item_key_by_coord(coord, &key)),
cluster_index_by_coord(coord));
>
>
>
Re: can not compile reiser4
I figured out the problem; I forgot to use "bk -r get".
- Original Message -
From: "Marcelo Pacheco" <[EMAIL PROTECTED]>
To: "Jack Byer" <[EMAIL PROTECTED]>
Sent: Sunday, August 10, 2003 8:10 PM
Subject: Re: can not compile reiser4
> What I know is I installed bk on my machine, downloaded their 3 bk areas
and
> with that patch I have sucessfully compiled a reiser4 capable kernel
(haven't
> tested reiser4 funcionality yet).
>
> Marcelo
>
> On Sunday 10 August 2003 21:05, Jack Byer wrote:
> > I don't understand how the patch could be the problem. It doesn't change
> > anything in the fs/reiser4 directory at all. The file that won't compile
is
> > fs/reiser4/entd.c, which is the most recent version from
> > bk://bk.namesys.com/bk/reiser4
> >
> > - Original Message -
> > From: "Marcelo Pacheco" <[EMAIL PROTECTED]>
> > To: "Jack Byer" <[EMAIL PROTECTED]>
> > Sent: Sunday, August 10, 2003 2:27 PM
> > Subject: Re: can not compile reiser4
> >
> > > That patch is old and outdated.
> > > All you need is on the bk trees, except for the attached small
> > > compilation
> >
> > patch that namesys hasn't took action yet.
> >
> > > Marcelo
> > >
> > > On Sunday 10 August 2003 13:35, Jack Byer wrote:
> > > > I'm trying to compile a 2.6.0-test2 kernel with reiser4 on a spare
> >
> > system.
> >
> > > > I downloaded the latest reiser 4 sources from bitkeeper into the fs
> > > > directory of a vanilla 2.6.0-test2 tree using the instructions on
your
> >
> > web
> >
> > > > site ( bk clone bk://bk.namesys.com/bk/reiser4)
> > > > Then I applied the 2.6.0-test2-reiser4-2.6.0-test2.diff patch from
your
> >
> > ftp
> >
> > > > site.
> > > > When I try to compile, I get the following error:
> > > >
> > > > CC fs/reiser4/entd.o
> > > > In file included from include/asm/hardirq.h:6,
> > > > from fs/reiser4/debug.h:17,
> > > > from fs/reiser4/entd.c:5:
> > > > include/linux/irq.h:69: warning: size of `irq_desc' is 28672 bytes
> > > > fs/reiser4/entd.c: In function `wait_for_flush':
> > > > fs/reiser4/entd.c:387: structure has no member named `pressure'
> > > > make[2]: *** [fs/reiser4/entd.o] Error 1
> > > > make[1]: *** [fs/reiser4] Error 2
> > > > make: *** [fs] Error 2
> > > >
> > > > Also, the "size of `irq_desc' is 28672 bytes" warning was printed
for
> >
> > every
> >
> > > > file in the reiser4 directory up to that point.
> > >
> > > linux 2.6.0 and reiser4 (patch/bugfix)
> > > Date: 2003-08-02 07:58
> > > From: "Pillars.NET" <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > >
> > > Figured out how to use bk to pull in the latest trees from
> > > linux.bkbits.net and bk.namesys.com and merge the two.
> > >
> > > Tried compiling a linux 2.6.0-test2 kernel with reiser4 built-in (not
> > > as a module)
> > >
> > > Ran into a compile-time error: "undefined reference to _udivdi3",
> > > which is described by one LKML author as "somebody is doing a 64-bit
> > > integer divide without pulling in the relevant gcc library."
> > >
> > > Poked around and found in "include/div64.h" a helper function called
> > > "div_long_long_rem" which appears to be custom-made for this type of
> > > problem.
> > >
> > > Here's what I changed to make the compiler happy:
> > >
> > > [EMAIL PROTECTED]:/usr/src/linux-2.6.0# diff -u
> >
> > fs/reiser4/plugin/item/ctail.c.orig fs/reiser4/plugin/item/ctail.c
> >
> > > --- ctail.c.orig2003-08-02 06:53:07.0 -0400
> > > +++ fs/reiser4/plugin/item/ctail.c 2003-08-02
> >
> > 06:41:15.0 -0400
> >
> > > @@ -55,7 +55,8 @@
> > > cluster_index_by_coord(const coord_t * coord)
> > > {
> > > reiser4_key key;
> > > - return get_key_offset(item_key_by_coord(coord, &key)) /
> >
> > cluster_size_by_coord(coord),&rem;
> >
> > > + unsigned long rem;
> > > + return
div_long_long_rem(get_key_offset(item_key_by_coord(coord,
> >
> > &key)),cluster_size_by_coord(coord),&rem);
> >
> > > }
> > >
> > > static char *
> > > @@ -764,13 +765,14 @@
> > > utmost_child_ctail(const coord_t * coord, sideof side, jnode **
child)
> > > {
> > > reiser4_key key;
> > > + long unsigned rem;
> > >
> > > assert("edward-257", coord != NULL);
> > > assert("edward-258", child != NULL);
> > > assert("edward-259", side == LEFT_SIDE);
> > > assert("edward-260", item_plugin_by_coord(coord) ==
> >
> > item_plugin_by_id(CTAIL_ID));
> >
> > > - if (get_key_offset(&key) != cluster_size_by_coord(coord) *
> >
> > (get_key_offset(&key) / cluster_size_by_coord(coord)))
> >
> > > + if (get_key_offset(&key) != cluster_size_by_coord(coord) *
> >
> >
div_long_long_rem(get_key_offset(&key),cluster_size_by_coord(coord),&rem))
> >
> > > *child = NULL;
> > > else
> > > *child = jlook_lock(current_tree,
> >
> > get_key_objectid(item_key_by_coord(coord, &key)),
> > cluster_index_by_coord(coord));
>
>
>
