headers
Alistair Riddell | 3 Nov 2002 17:33
Picon
Favicon

raidreconf success report

I am happy to report successfully using raidreconf to grow a 7 x 73GB
RAID5 to 10 x 73GB RAID5.

The operation took around 16 hours. Machine is a 4-way xeon with 6GB RAM;
though the kernel on the CD I booted from only supported UP/1GB RAM. I'm
not sure whether the extra CPUs/memory would have helped performance.
Disks are 10kRPM scsi disks.

The sequence of commands was:

boot from cd (raid is root filesystem)
reiserfsck /dev/md0
raidstop /dev/md0
raidreconf -o oldraidtab -n newraidtab -m /dev/md0
go home and sleep!
reiserfsck /dev/md0
resize_reiserfs /dev/md0
reiserfsck /dev/md0
then reboot, and machine carried on as before!

No errors were reported at any stage.

All very impressive. Thanks for the good work!

--

-- 
Alistair Riddell - BOFH
IT Manager, George Watson's College, Edinburgh
Tel: +44 131 446 6070    Fax: +44 131 452 8594
Microsoft - because god hates us
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vinnie | 5 Nov 2002 05:03

HELP - need more documentation on using partitioned (mdp-type) md devices

Hello all,

I am gradually getting through the process of setting up a partitioned 
RAID1 array, but having quite a time with it.

I applied Neil Brown's md-partitioning patches to my 2.4.18 kernel, and 
embarked on the journey.

I'm trying to get a pair of 40GB ATA100 IDE drives to work as a bootable
RAID1 array, as an mdp-type md device.

I'm actually getting pretty close now, I just can't get LILO (22.3.2) to 
write the boot sector to the array drives, pretty much any way I try to 
do it.

I'm not running /dev file system, since I've never been able to get that 
to work with my Red hat systems (though it seems like it would be really 
neat, if my systems wouldn't lock up after compiling a kernel with that 
feature enabled.  Are you supposed to delete all the entries in /dev, 
leaving just the /dev mount point, and let the kernel fill in the 
entries for you?).

So I had to manually create the devices.  I'll spare all the gruesome 
details of incorrect device names made along the way, experimenting with 
major and minor device numbers, etc.

Here's what I have under my /dev device tree for md-type entries:
(The first group, /dev/mdXX, were already there, I had to create the
rest by hand.  Well... by script... ;)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Neil Brown | 5 Nov 2002 05:33
X-Face
Picon
Picon
Favicon

Re: HELP - need more documentation on using partitioned (mdp-type) md devices

On Monday November 4, listacct1 <at> lvwnet.com wrote:
> 
> If anybody (Neil?) can offer some advice on how to get LILO to write a 
> boot sector to the RAID1 array pair, it would be greatly appreciated.  I 
> am so close to getting this working!!!
> 

First, lilo thinks it knows what "/dev/md*" means, and gets all
confused when it turns out to be different.
So create device names that *don't* start /dev/md.
e.g.
   /dev/MDa == 60,0
   /dev/MDa1 == 60,1
   etc

Second, you have to tell lilo about the geometry of /dev/MD*, because
it doesn't know:

   boot=/dev/MDa
   disk=/dev/MDa
     bios=0x80
     sectors=63
     heads=255
     cylinders=1024
     partitions=/dev/MDa1
      start=63

The "start" is very important.  check what the start sector of MDa1
is, and use that.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vinnie | 5 Nov 2002 06:59

Re: HELP - need more documentation on using partitioned (mdp-type) md devices

Neil Brown wrote:

 > On Monday November 4, listacct1 <at> lvwnet.com wrote:
 >
 >>If anybody (Neil?) can offer some advice on how to get LILO to write a
 >>boot sector to the RAID1 array pair, it would be greatly appreciated.  I
 >>am so close to getting this working!!!
 >>
 >>
 >
 > First, lilo thinks it knows what "/dev/md*" means, and gets all
 > confused when it turns out to be different.
 > So create device names that *don't* start /dev/md.
 > e.g.
 >    /dev/MDa == 60,0
 >    /dev/MDa1 == 60,1
 >    etc
 >
 > Second, you have to tell lilo about the geometry of /dev/MD*, because
 > it doesn't know:
 >
 >    boot=/dev/MDa
 >    disk=/dev/MDa
 >      bios=0x80
 >      sectors=63
 >      heads=255
 >      cylinders=1024
 >      partitions=/dev/MDa1
 >       start=63
 >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vinnie | 5 Nov 2002 07:07

Re: HELP - need more documentation on using partitioned (mdp-type) md devices

Hi Neil!

Thanks for your help.  That did the trick!

I did have to change the partitions= to partition=, I didn't know any 
better but LILO did! ;)

Also once I got a successful LILO install (I did a -t -v first), and 
booted up, I got an error from LILO stating "EBDA Too Big".

I looked up EBDA in the README's and it says it is a thing that happens
sometimes with MultiProcessor motherboards, and suggested building LILO
with the LARGE_EBDA option.  I thought I'd try out just using the
'compact' statement in lilo.conf first, and that was enough to do it, I
got booted up successfully!

My test case told the kernel that the root fs was on the original 
external RAID subsystem, so really all I was testing was that I could 
actually boot from the RAID1 pair of IDE disks created with the 
partitioned md device.  Should be able to proceed on now to copying all 
files over to the filesystems on the RAID1 pair, so I can pull this 
external RAID subsystem offline and reconfigure it.

Thanks again Neil!  Couldn't have done it without your help!  Well, not 
in the next week or so, probably... ;)

vince

Vinnie wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Brueggeman | 5 Nov 2002 18:14
Picon
Favicon

Re: raidreconf success report

This is the first I've heard of raidreconf.  

Where is it, and can it be used to reduce a RAID-5 configuration???

Steve Brueggeman

On Sun, 3 Nov 2002 16:33:09 +0000 (GMT), you wrote:

>I am happy to report successfully using raidreconf to grow a 7 x 73GB
>RAID5 to 10 x 73GB RAID5.
>
>The operation took around 16 hours. Machine is a 4-way xeon with 6GB RAM;
>though the kernel on the CD I booted from only supported UP/1GB RAM. I'm
>not sure whether the extra CPUs/memory would have helped performance.
>Disks are 10kRPM scsi disks.
>
>The sequence of commands was:
>
>boot from cd (raid is root filesystem)
>reiserfsck /dev/md0
>raidstop /dev/md0
>raidreconf -o oldraidtab -n newraidtab -m /dev/md0
>go home and sleep!
>reiserfsck /dev/md0
>resize_reiserfs /dev/md0
>reiserfsck /dev/md0
>then reboot, and machine carried on as before!
>
>No errors were reported at any stage.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam Luter | 5 Nov 2002 18:51

Re: raidreconf success report

Even if it can, I haven't heard of any filesystem resizers that could
reduce.  (But I could be easily wrong).

-Adam

On Tue, Nov 05, 2002 at 11:14:51AM -0600, Steve Brueggeman wrote:
> This is the first I've heard of raidreconf.  
> 
> Where is it, and can it be used to reduce a RAID-5 configuration???
> 
> Steve Brueggeman
> 
> On Sun, 3 Nov 2002 16:33:09 +0000 (GMT), you wrote:
> 
> >I am happy to report successfully using raidreconf to grow a 7 x 73GB
> >RAID5 to 10 x 73GB RAID5.
> >
> >The operation took around 16 hours. Machine is a 4-way xeon with 6GB RAM;
> >though the kernel on the CD I booted from only supported UP/1GB RAM. I'm
> >not sure whether the extra CPUs/memory would have helped performance.
> >Disks are 10kRPM scsi disks.
> >
> >The sequence of commands was:
> >
> >boot from cd (raid is root filesystem)
> >reiserfsck /dev/md0
> >raidstop /dev/md0
> >raidreconf -o oldraidtab -n newraidtab -m /dev/md0
> >go home and sleep!
> >reiserfsck /dev/md0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Brown | 6 Nov 2002 00:43
X-Face
Picon
Picon
Favicon

Re: [BUG] raw over raid5: BUG at drivers/block/ll_rw_blk.c:1967

On Tuesday October 15, neilb <at> cse.unsw.edu.au wrote:
> On Monday October 14, lkml <at> dm.cobite.com wrote:
> > 
> > Hi everyone,
> > 
> > I haven't been able to run raw over raid5 since 2.5.30 or so, but every
> > time I'm about to report it, a new kernel comes out and the problem
> > changes completely :-( Now I'm finally going to start getting out the info
> > it the hopes someone can fix it.  The oops was triggered by attempting to 
> > read from /dev/raw/raw1 (bound to /dev/md0) using dd.  System info 
> > follows oops:
> > 
> > ------------[ cut here ]------------
> > kernel BUG at drivers/block/ll_rw_blk.c:1967!
> > invalid operand: 0000
> >  
> 
> You are not alone in reporting this BUG...
> 
> I blame the Scsi/bio  layer.
> Jens Axboe blames raid5.
> :-)
> 

Just for the record, Jens was right. :-)
Here is the patch which will be winging it's way to Linus shortly.

NeilBrown
-----------------------------
Fix bug in raid5
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rikard Morssing | 6 Nov 2002 13:12
Picon

raidreconf feedback help

I just decided to risk it and expand my raid5-set with raidreconf. It
failed miserably (but that might be due to hw).

But it made me think. How should we create meaningful, extensive and
informative debug reports which is crucial for the developers to debug
the program? What i think should be on the raidreconf webpage is a list
of steps to perform BEFORE and AFTER running the raidreconf, and where
to send the report.

good idea?

regards
Rikard M
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
MShetty | 6 Nov 2002 14:59

Removable Hard Disk Drive

Hi,

With respect to a "removable hard disk drive" what would B128, B96,
B64 and B32 stand for ??

The piece of code I am reading doing a convertion between A and B
where
A =
     unsigned long   num_Major;
     unsigned long   num_Minor;
     unsigned int    num_Disk;
     unsigned int    num_Dkc;  // Disk Controller
     unsigned int    num_Dport;
     unsigned int    num_Hba;
     unsigned int    num_Hport; // Host Port
     unsigned int    num_Bus;
     unsigned int    num_TId;
     unsigned int    num_Hlu;  // Host Logical Unit

B =
struct B
{
    unsigned int B128;
    unsigned int B96;
    unsigned int B64;
    unsigned int B32;
};

Would help if I could get some clue on what they stand for.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane