Re: raid and 2.4 kernels
On Wed, 26 Jul 2000, Anton wrote:
do the kernel developers responsible for RAID read this list? I would be
interested in seeing some constructive discussion about the reports of
degraded RAID performance in the 2.4 kernels. It is particularly
disappointing given that SMP appears to be a lot better in 2.4 vs 2.2
2.4 is having VM problems, therefore especially write performance can be
poor. This is not directly RAID related, although maybe RAID will amplify
the problem.
There's a lot of work going on in trying to make the VM perform more reasonably,
and I'm confident that RAID performance will be absolutely *smoking* once those
other issues are sorted out.
The block I/O layer has seen some optimizations and especially the buffer/cache
merger should improve throughput significantly (especially on low memory-bandwidth
machines).
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: OT: Kernel Management
On Wed, 26 Jul 2000, Bryan Batchelder wrote:
I've been wanting to mess around with the latest 2.4 kernels and RAID, but
one thing that I just don't understand/know about the whole compiling the
kernel is this: How do you manage the System.map file that resides in
/boot on RedHat systems?
I have no problems configuring/compiling/installing otherwise.
Anyone have a good technique they use when they get to the point where its
time to copy /usr/src/linux/arch/i386/boot/bzImage
/boot/vmlinux-versionnumber and copy /usr/src/linux/System.map /boot and
edit lilo.conf???
I am curious, and I know that people on this list must be doing it alot :-)
make dep make clean make install modules make modules_install
Builds the kernel, copies the files, runs lilo.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Is the raid1readbalance patch production ready?
On Fri, 21 Jul 2000, Malcolm Beattie wrote:
Is the raid1readbalance-2.2.15-B2 patch (when applied against a
2.2.16+linux-2.2.16-raid-B2 kernel) rock-solid and production
quality? Can I trust 750GB of users' email to it? Is it guaranteed
to behave the same during failure modes that the non-patched RAID
code does? Is anyone using it heavily in a production system?
(Not that I expect any other answer except maybe for a resounding
"probably" :-)
The patch only touches the read logic in the RAID code, and the patch
is fairly simple. I've used the patch myself on a few busy systems
and had no problems what so ever.
Besides, I spent quite some time trying to improve the patch and come
up with a better approach (I failed miserably though) so I'm very
confident that Mika's patch is correct. I've read it and understood
it, and I have no problem trusting it with my data.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID5
On Wed, 12 Jul 2000, [EMAIL PROTECTED] wrote:
Hallo liebe Linux- und RAID-Freunde,
nach mehrfachem Lesen von man-pages und einigen vergeblichen Versuchen ein
RAID5 auf der Basis von drei Festplatten aufzubauen, fühle ich mich durch
Ihren Vermerk ermuntert Sie doch anzusprechen.
Be sure to read the HOWTO as well.
http://ostenfeld.dtu.dk/~jakob/Software-RAID.HOWTO/
Etwas zu meiner Person: Seit mehreren Jahren befasse ich mich mit der
EDV-Technik. Zuerst war es die CAD-, dann die Netzwerktechnik. Schliesslich
kamen die Netzwerkprüfungen und der MCSE.
Da ich persönlich einen grossen Wert auf die heterogene Netzwerkumgebung
lege, ist auch der Gedanke nahe, Linux als ausgereiftes Betriebssystem zu
erforschen. Meine ersten Schritte habe ich mit einer Test-Version der
SUSE-Distribution von Linux 6.0 gemacht. Linux hat sofort meine Sympathie
gewonnen. Jetzt habe ich eine komplette SUSE-Distribution von Linux 6.4 und
versuche mich selbst weiterzubilden und meine Kenntnisse über Linux zu
vergrössern.
Für den Einsatz im Netzwerk ist RAID unumgänglich, also nichts wie RAID mit
Linux aufzubauen.
Meine Konfiguration ist folgende:
3 SCSI-Festplatten:
- 1. Festplatte: 3 primäre Partitionen, 1 erweiterte Partiton, wobei die
letzte logische Partition (sda7) mit der Grösse von 485 MB der erste Teil
des RAID-Satzes sein soll (der Mount-Point / liegt auf sda3)
Ok. Linux in general doesn't care much whether your partitions are primary
or extended though.
- 2. Festplatte: 3 primäre Partitionen, wobei die letzte Partition (sdb3)
mit der Grösse von 485 MB der zweite Teil des RAID-Satzes sein soll,
- 3. Festplatte: 3 primäre Partitionen, wobei die letzte Partition (sdc3)
mit der Grösse von 485 MB der dritte Teil des RAID-Satzes sein soll.
Um die Möglichkeit des RAID-Aufbaus überhaupt zu haben, habe ich neuen
Kernel kompiliert, und den Controller-Treiber eingebunden.
Unter /etc habe ich die "raidtab" aufgebaut. Einmal habe ich die
RAID-Partitionen mit FAT, einmal mit ext2 formatiert. Nichts ist gelungen.
What filesystem you put on your RAID device doesn't matter. If you have
a problem with RAID, no filesystem is going to solve it.
Die Reihenfolge, die ich mir vorstelle ist:
- mit "mkraid" den RAID anzulegen,
Does this succeed ?
- den Rechner neu zu starten,
No need.
- den RAID zu formatieren (mit ext2),
- mit "raidstart" den RAID zu starten.
Oh no, you must start the RAID _before_ you can format it. If the RAID
isn't running (eg. it is not present to the system, it doesn not *exist*)
then how could you put data on it ?
I would recommend that you use the autostart feature and persistent superblocks.
That way you won't have to care about starting the array on boot. It just
happens.
If you read the HOWTO, I'm sure these things are going to be more clear to you.
If not, let me know :)
Der Befehl "mkraid" lehnt es immer ab den RAID anzulegen. Auch das Erzwingen
mit "-f" bringt mich nicht weiter.
We need to see your raidtab _and_ the error message from mkraid in order to
help.
Hier meine grosse Bitte an Sie: Könnten Sie mir per E-Mail einen Hinweis
geben wie es richtig zu machen ist? Vielleicht ist es nur noch eine
Kleinigkeit ...
Auf jeden Fall schon ein "Danke schön"!
I hope things clear up after you read the HOWTO. If not, please write again
to the list or to me in person. But please, in english:) Your english
is better than my german, I promise you:)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.....: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Journaling FS and RAID
On Mon, 26 Jun 2000, Sean Millichamp wrote:
I am about to implement a ~100 GB RAID-5 array using Linux software
RAID-5 and I have two questions I was hoping I could find answers to here
:)
...
2) Resizing RAID volumes
I recall seeing once quite a while ago information regarding resizing of
RAID volumes (as in, adding additional active drives) that stated RAID 0
resizing was functional, but not RAID-5. Does anyone know if any progress
been made on this front or if anyone is working on it at all? I did some
searching with google, but didn't find anything that really answered my
question.
There's been no progress here yet, but there will be in some time.
You can get the tool from http://ostenfeld.dtu.dk/~jakob/Software-RAID.HOWTO/
and it support RAID-0 resizing, but not yet RAID-5. Feel free to add
RAID-5 functionality yourself:)If noone else does, I'll do that
myself, but I can't make promises as to when that will happen. It could
be weeks or it could be months from now.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: what you want from AMI tools
On Wed, 14 Jun 2000, Stephen O'Mohany wrote:
Hi All,
The company that I work for, American Megatrend has decided to
support a linux driver for one of its new products an IDE controller called
Hyperdisk. You can check it out at www.ami.com http://www.ami.com . We
have created the software raid driver and the next task is to create a set
of tools (rebuild, notification of raid status) .
The question is, does anyone have any strong opinions as to what these
tools should look like or do.
Most importantly, I think the driver should make all status information
available via. the proc filesystem. This allows everyone to hack up
their own monitoring tools if they want to, and it allows other commercial
software makers to easily support your device.
The tools should definitely be command-line at first. You could add
GUI / Curses interface, but command line tools are necessary for
scripting purposes (and easy step-by-step documentation in HOWTOs).
It's imperant that you can configure your device over non-X connections,
so a GUI alone won't cut it. And some of us use old terminals, so maybe
even Curses is setting the bar a little high.
Should you decide that a GUI would be worth the effort, _please_ don't
use Motif ;) I don't care about Qt vs. GTK+ (well I don't care enough
to argue about it), but Motif is the one choice that will not fit into
the desktops of _any_ GNU/Linux user.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: stability of software RAID under Linux
On Fri, 26 May 2000, Darren Evans wrote:
Having spent a considerable amount of time trying to
ascertain the stability of vinum under FreeBSD, i'm not
confident in using it on a production box.
When I looked at Vinum last, it required some proprietary stuff from Veritas to
provide RAID-5 functionality. I don't know if that has been ``fixed'' by now,
but that certainly put me of.
I don't know much (at the moment about Linux Software RAID),
but would like to hear people's experience.
It's a RAID 5 solution that interests me running with
a SMP kernel.
All RAID levels with Ingo's patch are considered stable. They have all seen a
lot of testing, and are in production a lot of places.
I have 7 systems with RAID-1 or RAID-5 running, 6 in production, and having
seen disk failures being handled gracefully too, I have no doubts about using
Linux Software RAID for critical systems. In fact I usually recommend it for
critical systems.
It's not a silver bullet though. It won't magically fix that your chipset can
lock up if enough hardware goes bad enough. But it will usually save you from
bad blocks and the likes... Those are the errors you are _certain_ to meet at
some point.
As far as I can ascertain there are 2 RAID packages.
LVM and the raidtools package and patches. Which is
better, which is more stable?
LVM can't do redundancy. If you need flexible storage, go for LVM, if you need
reliable storage go for RAID-1 or RAID-5. You can, I presume, build a LVM over
RAID-1/5 arrays, although I have *no* experience with LVM what so ever (yet).
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Mirroring Raid1 with 3 disks...???
On Thu, 25 May 2000, Thomas Scheuermann wrote:
Hi,
Am Don, 25 Mai 2000 schrieben Sie:
Hi,
I want to know if it's possible to do mirroring
Raid1 with 3 disks (all those 3 disks will always
have the same contents)?
If yes, how?
I've never tested it but I think the raidtab should look something like
raiddev /dev/md0
raid-level 1
nr-raid-disks 3
nr-spare-disks 0
chunk-size 4
persistent-superblock 1
device /dev/hda2
raid-disk 0
device /dev/hdb2
raid-disk 1
device /dev/hdc2
raid-disk 2
It will work, and with Mika's raid-1 read-balancing, it will even be a
performance gain if you array is mostly read from.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: change in raid in kernel 2.2.15
On Mon, 08 May 2000, Dylan wrote:
Hi I was just wondering whether anything drastic had changed between 2.2.14-5 and
2.2.15 as I can't run any raid devices under my 2.2.15 kernel but can run them all
under my 2.2.14-5 kernel.
Have tried all the obvious and have made sure that all the right options are
compiled in
Have you any other ideas
The -5 suggests that it's a RedHat kernel. RedHat puts the 0.90 RAID code in
their kernels, the stock kernels still have the old RAID code.
So if you try to run your 0.90 arrays under a plain 2.2.15 it won't work.
Get the patch from http://people.redhat.com/mingo
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID-0 - RAID-5
On Fri, 28 Apr 2000, Benno Senoner wrote:
...
Sorry , I am not very up to date:
do you plan both, an increase of the individual partitions,
and resizing by adding more disks ?
I mostly thought of just adding more disks. But resizing partitions
ought to be fairly straight forward. Of course, for RAID-0 you might
want to grow some partitions and shrink others, which will require
similar magick to what the tool does now when just adding disks.
That would be too cool, having for example a 4 disks soft-RAID5 array
and when you run out of space, add one more disk, and let the resize
tool
recalculare all parities etc, in order to take the fifth disk into
account.
Yes, it would be cool. Now I don't plan very much with this utility.
I'm going to continue work on it as time permits, or support anyone
who's willing to take to ball from here, again as time permits.
I really really hope that I'll be able to make this tool work with
the other levels sometime in the not too distant future. But right
now I'm just too bogged down with other work.
Is that possible form a pratical POV ?
Absolutely.
The real trick is to make it fairly efficient too. The first version
of the tool was very simple, and _very_ slow. The trick is to minimize
the number of seeks done on the drives when moving blocks around.
Ideally the system would have either 200G of memory, or a separate
``spool'' disk:)
Resizing raids is very simple, conceptually. But resizing them in
reasonable earth-time is harder.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID-0 - RAID-5
On Thu, 27 Apr 2000, Mika Kuoppala wrote:
[snip]
I think Jakob Østergaard has made raid-reconf utility
which you can use to grow raid0 arrays. But i think
i didn't support converting from raid0 to raid5. Or
perhaps it alraeady does =? :)
It doesn't (yet). And unfortunately, with examns coming
up, it's not likely that it will for the next month or
two.
I haven't abandoned the idea though. With the new raid in 2.4
the demand for such a utility will be even greater.
Cheers,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: stability of 0.90
On Tue, 25 Apr 2000, [EMAIL PROTECTED] wrote:
I've been running raid1 (kernel 2.0, then 2.2) on a fileserver for over a
year now. I have suddenly seen the need to upgrade to raid0.90 after having
a powerfailure+UPS failure; I _need_ hot recovery (12GB takes about 2hrs to
recover with the current code!). How stable is 0.90?
``very''.
It's more stable than the old code ever was. I'm surprised you even succeeded
running the old code with a raid level that has redundancy, I could never
make that work under heavy load.
The 0.90 code is in use a lot of places. I have 7-8 systems or so running with
various levels (all but RAID-4 actually), and it's rock solid.
Under
people.redhat.com/mingo, the file is labeled "dangerous". But I can't use
the 2.2.11 code under kernel.org 'cause 2.2.11 has that nasty little TCP
memory leak bug
Stay away from the ``dangerous'' code.
Use Ingo's patch for 2.2.14 at the URL you mentioned. It works with 2.2.14 and
2.2.15(pre-something).
2.2.15pre-X and the 2.2.14 RAID patch is a nice couple. Look out for
rejects when you patch. You will most likely have to fix one small reject
in raid1.c, but it shouldn't be much of a problem I guess.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: fsck'ing RAID's
On Mon, 24 Apr 2000, Cal Thixton - President - ThoughtPort Authority of Chicago wrote:
What is the advice on whether to enable auto-fsck'ing in fstab on RAID5's?
You should, of course, since you don't want to mount a non-checked filesystem.
Seems redundant to have both fsck and raidsync run both at the same time
Well, the resync will progress really slow until fsck completes (resync uses
idle I/O bandwith)
and fsck seems to always find something amiss before resync'ing is completed.
If fsck behaviour changes depending on whether the resync is completed or not,
then you really have a serious problem at your hands.
Resync shouldn't change what is read from the array, as it only rebuilds the
parity -- the redunant information -- and doesn't affect the ``real'' data.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: current RAID state-of-the-art?
On Tue, 11 Apr 2000, Darren Nickerson wrote:
[snip]
Either the pre-16 patch fails on an Ingo-patched raid1.c with:
Hunk #1 FAILED at 211.
Hunk #2 FAILED at 303.
Hunk #3 FAILED at 719.
3 out of 3 hunks FAILED -- saving rejects to drivers/block/raid1.c.rej
or Ingo's RAID patch fails after applying pre-16 with:
Hunk #7 FAILED at 143.
Hunk #8 succeeded at 207 (offset 4 lines).
Hunk #10 FAILED at 284.
Hunk #11 succeeded at 395 (offset 8 lines).
Hunk #13 FAILED at 864.
Hunk #14 succeeded at 1223 (offset 12 lines).
3 out of 15 hunks FAILED -- saving rejects to drivers/block/raid1.c.rej
No matter what, the diff is too damn big for me to hand crank. And I never got
it down to one chunk rejected.
Ok, I almost did it again today, this time with 2.2.15pre17 but without the IDE
patch.
2.2.14 + 2.2.14 RAID + 2.2.15pre17 ( + i2c + lmsensors + homebrew wdt patch)
in that exact order gives you a reject for raid1.c. Simply change the
raid1_kmalloc routine so that it reads:
static void * raid1_kmalloc (int size)
{
void * ptr;
/*
* now we are rather fault tolerant than nice, but
* there are a couple of places in the RAID code where we
* simply can not afford to fail an allocation because
* there is no failure return path (eg. make_request())
*/
while (!(ptr = kmalloc (sizeof (raid1_conf_t), GFP_KERNEL))) {
printk ("raid1: out of memory, retrying...\n");
current-policy |= SCHED_YIELD;
schedule();
}
memset(ptr, 0, size);
return ptr;
}
and that's it. You will see that the reject simply barfs on the change moving
the kmalloc calls to the generic raid1_kmalloc routine, which is changed in the
pre patches to behave nicer on OOM conditions.
Note, that if you apply the raid patch _after_ Alan's pre-patch, you will get
a very large reject which touches most of the raid1 code. You should make sure
that the reject touches only the kmalloc parts before counting on the above to
work.
Jakob I can recommend the 2.2.15pre patch, it solves instability problems in
Jakob 2.2.14 and was definitely worth the extra trouble for me.
Not sure how you managed it. I'm going to have to settle for 2.2.14, and see
if I can find out what "instability problems" you're talking about.
:)
2.2.14 worked just fine on several machines. I don't recall which had the problem,
or what triggered instability.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: current RAID state-of-the-art?
On Mon, 10 Apr 2000, Darren Nickerson wrote:
Folks,
I need RAID and Promise Ultra-66 support, I'm thinking of:
linux-2.2.14.tar.gz + pre-patch-2.2.15-17.gz + ide.2.2.15-17.2405.patch.gz
since Alan and Andre seem to be in sync these days. But I need RAID and Ingo's
raid patch (raid-2.2.14-B1) seems to be against 2.2.14 . . . so I'm thinking:
linux-2.2.14.tar.gz + ide.2.2.14.2124.patch.gz + raid-2.2.14-B1
Can anyone recommend a different combination for production use today?
I managed to get linux-2.2.14 + 2.2.15pre16 + ide patch + raid patch going.
You _have_ to apply the patches in the right order (which I forgot) to minimize
the reject. If you get it right, you will only see _one_ reject in raid1.c which
is easily fixable.
Experiment a little, and it will come to you.
I can recommend the 2.2.15pre patch, it solves instability problems in 2.2.14 and
was definitely worth the extra trouble for me.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Tired of Spam
On Sat, 08 Apr 2000, David Cooley wrote:
I'm tired of being spammed, and obviously the list admins are schmucks to
leave the list open to spammers.
I have unsubscribed.
There are ways to deal with spammers, other than crippling the lists
by closing them.
If you see a list spam from a company in your country, _call_ them, over
the _phone_. Tell them they're doing wrong. This will have quite an
impact on companies, as spamming is cheap but phones are costly to man.
Or send them a fax. After reading ten miles of fax messages, they might
think twice next time.
We're a lot of people on these lists, and I find it hard to belive that
we can't convince a few companies that _not_ spamming us is a lot better
bargin for all.
Besides, I think we get relatively little spam. You can usually tell
by the subject line, and the ``d'' key is not that far away.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: single vs raid soft
On Sat, 08 Apr 2000, octave klaba wrote:
Hi,
hdparm -v /dev/hd[ac]
See if using_dma is 0 or 1. If it's 0, either try a kernel where you can set
the ``Use DMA by default if available'' option to the IDE driver, or try setting
it manually with hdparm -d1 /dev/hd[ac]
using 2.2.14 I chose "Use DMA by default when available" and recompiled kernel.
it is still 0 for 32bitsDMA
Try .15pre16
If that doesn't help, mail the dmesg output along with a description of your
hardware (disks, cat /proc/pci etc.) to Andre Hedrick, the Linux IDE guy.
I added in /etc/rc.de/rc.local hdparm -c1 -d1 /dev/hd[ac]
but it is not a solution :/
Why isn't it a solution ? Because it doesn't work, or because
it isn't pretty ?
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid-0.90 behaviour at boot
On Sat, 08 Apr 2000, Achim Flammenkamp wrote:
Hi
Yesterday I tried to set up a Software-Raid following
The Software-RAID HOWTO by Jakob OEstergaard
In principle it seemed to work but a single problem aroses.
I 'm running a Linux-2.2.14 Kernel patched with the raid0145-19990824-2.2.11
from August 1999. Beside some non applied patches for ppc and sparc-architekture
only one hunk for raid0.c doesn't succeded. But this was no point, I could
patch it manual easily.
Further I first downloaded the corresponding raidtools-19990824-0.90 and later
after running the new kernel I fetched the raid-2.2.14-B1 file for the newest
raid-tools and compiled and installed these.
The creating of the partitions (id=fd), autodection of the kernel, and the
mkraid worked for all raid-devices /dev/md0, ..., /dev/md7 without problems.
Next also /proc/mdstat shows all devices as active. Then I made the corres-
ponding `mke2fs -b 4096 -R stride=8 /dev/md?' filessystems without any problems
and rebootet.
Since then there seems to be a problem in /dev/md5.
Inside /etc/raidtab the part for this device looks like:
[snip]
Try the patch for 2.2.14 from http://people.redhat.com/mingo
The problem you're seeing shouldn't occur, and my best guess is that it's
due to the mismatched patch.
---
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Power Supply for multiple disks?
On Thu, 06 Apr 2000, Sven Kirmess wrote:
Thursday, April 06, 2000, 6:36:39 PM, David wrote:
What about "IDE power down when idle"? Can this blow up the power
supply or crash the system when turning on 4 disks simultaneous?
You don't want to use "power down when idle" on drives in a RAID...
Why not? I think about power down after e.g. 30' idle time. Not after
a few seconds... What's the Problem with RAID? Does it mark all disks
as bad if they don't come up fast enough?
It definitely shouldn't. That would be a bug in the drive if you got
a read/write failure after power down.
On a home system where the disks can potentially be idle for a long
time, you could probably spin the disks down. On a production system
where users expect a prompt reply from the system, powering down the
disks is outright stupid.
But I fail to see how this relates to the size of the PSU ? All disks
must run when you use them, and if you need a 300W PSU to do that, you
can't use a 150W even if your disks are only in use 50% of the day.
(Obviously)
By the way, a lot of modern IDE drives have a jumper setting that
will delay their spin-up, so you could have your drives spinning up
only a few at a time to reduce the peak load, even with cheap disks.
At least some IBM disks has this feature (unsure about others)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Power Supply for multiple disks?
On Fri, 07 Apr 2000, Sven Kirmess wrote:
Thursday, April 06, 2000, 10:08:59 PM, Jakob wrote:
Sorry, but I have to say it. Very, very good HOWTO. Thanks.
*Blush*:)
Why not? I think about power down after e.g. 30' idle time. Not
after a few seconds... What's the Problem with RAID? Does it mark
all disks as bad if they don't come up fast enough?
It definitely shouldn't. That would be a bug in the drive if you got
a read/write failure after power down.
But Linux may have a timeout...?
You're right. It has none that I know of. I would be surprised if
there was a timeout (I'm really sure there isn't), as this would be
some experimental value that you could never really give a ``right''
value.
On a home system where the disks can potentially be idle for a long
time, you could probably spin the disks down. On a production system
where users expect a prompt reply from the system, powering down the
disks is outright stupid.
Of course it isn't a productive system.
But I fail to see how this relates to the size of the PSU ? All
disks must run when you use them, and if you need a 300W PSU to do
that, you can't use a 150W even if your disks are only in use 50% of
the day. (Obviously)
I know that of course. My question was more like "Is there a power
problem with a couple of IDE disks?" or "are you running special
supplys?".
We have six 6G old Quantum SCSI disks in a home-made RAID tower here.
The disks spin up all at the same time (they're to stupid/old to do
anything else), and they run of a cheap AT PSU. No problems, but
I have no idea what the load is on the PSU when they spin up.
I won't create a RAID system and loose more data because of a too weak
supply than I would loose during a disk failure.
I think that if you get past a synchronous spinup, you'll survive
anything that might happen during use. But this is all a ``may''
and ``might'' discussion...
By the way, a lot of modern IDE drives have a jumper setting that
will delay their spin-up, so you could have your drives spinning up
only a few at a time to reduce the peak load, even with cheap disks.
At least some IBM disks has this feature (unsure about others)
But this will slow down the wake process even more and maybe lead to
more misinterpretation of the disk status...?
It will slow the wakeup process if the disks also delay wakeups
after the initial power-on. I don't know what the disks would do,
it probably even depends on vendors too, just to make this whole
thing even more interesting:)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID-1 Non-destructive mirroring
On Wed, 05 Apr 2000, [EMAIL PROTECTED] wrote:
Is there any sign of RAID-1 that's non-destructive? This is making my
life living hell right now. :)
RAID-1 with persistent superblocks will require the last few KB of your
disk for the superblock.
But besides from that, it should be quite doable to:
setup RAID-1 with current disk as failed
copy current disk data to raid (now running degraded mode because of ``failure'')
raidhotadd current disk to raid
- now you have all data on RAID-1 with superblocks etc.
I haven't been keeping up, so if there is a 2.2 patch or perhaps
something in 2.3 that supports it, I would be most gracious (perhaps a method
that isn't described in the howto?)
You want 0.90 RAID for this.
Docs: http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
I would really like to be able to walk into a good portion of my
clients and offer this, but the tedium of backup/partition/bootdisk/raid
setup/restore is too much on a time-per-hour basis to offer them... I
unfortunately have been having to offer "new technology" to long-standing
UNIX clients who demand RAID-1 (which sickens me) to cover these needs since
the price of hardware RAID controllers is even worse (and slower).
Any help or kludges that can get me around this would be greatly
appreciated.
Well, we can't have everyone using neandertal technology just because
of RAID-1:)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid5 with two failed disks?
On Mon, 03 Apr 2000, Rainer Mager wrote:
Hi all,
I think my situation is the same as this "two failed disks" one but I
haven't been following the thread carefully and I just want to double check.
I have a mirrored RAID-1 setup between 2 disks with no spare disks.
Inadvertantly the machine got powered down without a proper shutdown
apparently causing the RAID to become unhappy. It would boot to the point
where it needed to mount root and then would fail saying that it couldn't
access /dev/md1 because the two RAID disks were out of sync.
Anyway, given this situation, how can I rebuild my array? Is all it takes
is doing another mkraid (given the raidtab is identical to the real setup,
etc)? If so, since I'm also booting off of raid, how do I do this for the
boot partition? I can boot up using one of the individual disks (e.g.
/dev/sda1) instead of the raid disk (/dev/md1), but if I do that will I be
able to do a mkraid on an in-use partition? If not, how do I resolve this
(boot from floppy?).
Finally, is there any way to automate this recovery process. That is, if
the machine is improperly powered down again, can I have it automatically
rebuild itself the next time it comes up?
As others already pointed out, this doesn't make sense. The boot sequence uses
the mount command to mount your fs, and mount doesn't know that your md device
is in any way different from other block devices.
Only if the md device doesn't start, the mount program will be unable to
request the kernel to mount the device.
We definitely need log output in order to tell what happened and why.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid5 with two failed disks?
On Sun, 02 Apr 2000, Marc Haber wrote:
On Sat, 1 Apr 2000 12:44:49 +0200, you wrote:
It _is_ in the docs.
Which docs do you refer to? I must have missed this.
Section 6.1 in http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
Didn't you actually mention it yourself ? :)
(don't remember - someone mentioned it at least...)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid5 with two failed disks?
On Sun, 02 Apr 2000, Marc Haber wrote:
[snip]
Yes, I did. However, I'd add a sentence mentioning that in this case
mkraid probably won't be destructive to the HOWTO. After the mkraid
warning, I aborted the procedure and started asking. I think this
should be avoided in the future.
I have added this to my FIX file for the next revision of the HOWTO.
Thanks,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid5 with two failed disks?
On Fri, 31 Mar 2000, Marc Haber wrote:
On Thu, 30 Mar 2000 09:20:57 +0200, you wrote:
At 02:16 30.03.00, you wrote:
Hi... I have a Raid5 Array, using 4 IDE HDs. A few days ago, the system
hung, no reaction, except ping from the host, nothing to see on the
monitor. I rebooted the system and it told me, 2 out of 4 disks were out
of sync. 2 Disks have an event counter of 0062, the two others
0064. I hope, that there is a way to fix this. I searched through the
mailing-list and found one thread, but it did not help me.
Yes I do. Check Jakobs Raid howto, section "recovering from multiple failures".
You can recreate the superblocks of the raid disks using mkraid;
I had that problem a week ago and chickened out after mkraid told me
it would destroy my array. If, in this situation, destruction doesn't
happen, this should be mentioned in the docs.
It _is_ in the docs. But the message from the mkraid tool is still sane,
because it actually _will_ destroy your data *if you do not know what you are
doing*. So, for the average Joe-user just playing with his tools as root
(*ouch!*), this message is a life saver. For people who actually need to
re-write the superblocks for good reasons, well they have read the docs so they
know the message doesn't apply to them - if they don't make mistakes.
mkraid'ing an existing array is inherently dangerous if you're not careful and
know what you're doing. It's perfectly safe otherwise. Having the tool tell
the user that ``here be dragons'' is perfectly sensible IMHO.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: ext2resize
On Wed, 29 Mar 2000, Seth Vidal wrote:
hi folks,
ext2resize claims to be able resize ext2 partitions w/o destroying data.
While there is evidence of this on normal drives and hw raid drives too.
I'd like to know if it will work on sw raid drives.
anyone know?
The filesystem resides on a block-device, and that's what the filesystem
resizer knows about. Whether the block-device is MD, single disk, loopback-
mounted file on another fs, or whatever, doesn't matter.
What does matter to the resizer however is, that your block device has
actually changed it's size. If you resize a block-device (partition or
array) the resizer can then expand the filesystem to span the entire
device. But the resizer cannot magically guess how you would have expanded
some block device by itself. The resizer simply _requires_ that the
block device is already resized.
However, with RAID you can resize linear devices (by putting in another
disk and mkraid'ing the array with the updated raidtab - causes no loss
of data if done right) and RAID-0 devices (using my raid reconfiguration
utility - found on http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/).
You cannot resize RAID-5 arrays (yet).
If resizing block-devices is somthing you do a lot, you might want to
consider using LVM instead of RAID. It's more flexible. But from what
I can understand LVM does not provide redundancy. If RAID-5 capability
was added to the RAID reconfiguration tool, this would be a real win.
Oh btw. I resized a 60G RAID-0 into 100+G using my reconfiguration tool
and the ext2 resizer. Works like a charm - as it should.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: resizing raid arrays
On Wed, 29 Mar 2000, Theo Van Dinter wrote:
Since this thread has popped up again, here's the URL I was referring to in
my previous email:
http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
You can resize RAID0 arrays, but so far not RAID5 arrays. 8(
Correct.
RAID-0 resizing, and conversion from single-disk to RAID-0.
I planned to do RAID-5 as well, and RAID-0 - RAID-5 conversion etc. The code
is laid out so you should be able to ``plug in'' new RAID level ``drivers'' -
so we wouldn't have to write 0-1 0-5 1-5 5-1 5-0 etc. conversion routines, but
could simply put in drivers for levels 0, 1 and 5. However, the structuring
is not really ideal, and I started working on making it better, as well as
putting in a RAID-5 routine.
Currently I don't have much spare time, so development just isn't progressing.
It's a little bit sad, because it would be a nice utility :) Anyway, I'll
let you know if^H^Hwhen I get some more work done.
The really *cool* thing would be to move this utility partly into kernel space,
or at least put hooks in the md code to allow for some communication between
the userspace tool and the kernelspace parts, to enable background resizing. I
heard that there was some ext2 resizer that could actually resize the fs while
mounted - with appropriate hooks into the kernel. This would be a really nice
addition to the kernel - being able to resize both arrays and filesystems on
the fly. But now I'm dreaming again ;) I should get the basic utility done,
and let someone in the know do the dangerous work :)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: single vs raid soft
On Tue, 28 Mar 2000, octave klaba wrote:
Hi,
a test between single ide - raid-1 soft ide - raid-1 soft scsi-2
1° PIII600/128RAM/1XIDE20.5
2° PIII600/128RAM/2XIDE20.5 raid-1 soft
3° PIII500/256/2940U2W/SCSI-2/RAID-1/IBM18Go7200
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1° 2000 9212 96.4 20354 13.9 4411 3.6 3822 35.4 22180 8.0 85.6 0.7
2° 2000 1727 22.4 2095 5.5 1381 34.9 3070 98.6 4320 97.8 74.8 7.3
3° 2000 7236 91.6 18321 15.5 8003 13.7 8347 96.7 18289 11.6 107.7 1.82
From the CPU load on the raid-1 soft IDE test, I think seems likely that you
didn't have DMA enabled. Could that be possible ?
It doesn't make sense to have 97% CPU load when reading with 4 MB/s unless
it's done with port I/O.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: single vs raid soft
On Tue, 28 Mar 2000, octave klaba wrote:
Hi,
From the CPU load on the raid-1 soft IDE test, I think seems likely that you
didn't have DMA enabled. Could that be possible ?
how can I verify it ?
hdparm -v /dev/hd[ac]
See if using_dma is 0 or 1. If it's 0, either try a kernel where you can set
the ``Use DMA by default if available'' option to the IDE driver, or try setting
it manually with hdparm -d1 /dev/hd[ac]
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid 1 mirror
On Tue, 28 Mar 2000, Andreas Martmann wrote:
Hello
I have to install a RAID 1 System in order to mirror all partitions (exept the
/boot partition, I think). The Problem is that I haven´t made this before, and I
haven´t found a documentation that gives me the answers I need.
There are three HowTos available the old (normal) RAID HowTo for RAID Systems
in Kernel 2.0.x and 2.2.x, the Boot-RAID-HowTO and the new Raid-HowTo.
The Old HowTos are from 1998 and I think they are not up-to-date, isn´t it?
The old HOWTOs are up to date with the old code. But the old code is _old_
(and buggy etc.)
My question is now: shall I take the normal kernel-buildin RAID System (with
the mdtools) or shall I patch my 2.2.13 kernel (SuSE-Linux Distribution)
and use the new one (with the raidtools)?
Patch 2.2.15pre15 instead. It's more stable than 2.2.13.
In the old Boot-HowTo there are lots of steps to make and I think that I will
have problems in comprehending them.
The new one is much easier I think.
Yep.
But is it really stable enough for a normal RAID 1 System with two
IDE-Disks? There is a /boot Partition (now RAID) and a / , /home and
/db-Partition on each Disk which I want to mirror.
RAID-1 is in my experience very stable with IDE disks. The system will
keep running if bad sectors appear on one disk, the RAID layer will simply
go into degraded mode and you can chose a convenient time to replace the
disk.
I've only seen this once in Real Life (TM) though, but in my experience the
IDE layer in Linux is far more stable and likely to survive device failures
than the SCSI layer is. (That will most likely get fixed in 2.5 I guess, but
let's take one step at a time :)
This Server will stay on a little airport and will keep an adabas database so
the solution must be stable.
Interesting !:)
When I shall use the new RAID-System: Which patch can I take? I have only
seen the patch from Alan C. at ftp.kernel.org/pub/linux/kernel/alan.
(I have the SuSE-kernel 2.2.13)
Patch for 2.2.14 at http://people.redhat.com/mingo applies fairly well to
2.2.15pre15 too, with one (easy) reject in raid1.c which you will have to fix by
hand.
At ftp.kernel.org/pub/linux/raid/alpha (I don´t know exactly the URL) there
are only patches for 2.2.11 and below.
I hope you can understand what I mean :-) and you can help me.
Ask again if you need to:)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Status of Raid-0.9
On Mon, 27 Mar 2000, Nikolaus Froehlich wrote:
Hello,
Sorry for taking a minute of your valuable time, but since all other
attempts to get information failed, I hope that someone from this list
will be able to answer 3 quick questions for me:
1) What is the status of the RAID development?
From the archives on ftp.kernel.org and the mailing list archives it
appears that all traffic conearning the deleopment
stopped end of Aug 99. Is that true? Why did the development get
abandoned? Are there major bugs in the code?
RAID 0.90 development has continued, and the most current patch is available
for 2.2.14 at http://people.redhat.com/mingo
2) Can the distributed raidset raidtools0.9 and raid0145-19992408-2.2.11
be considered stable for a RAID-1 application in a 2.2.x kernel?
Go with 2.2.14, or even better, 2.2.15pre15 (you'll have to fix a reject
in raid1.c if you need RAID-1 though - but it's an easy one)
3) Are there still efforts to include a 'new' Raid implementation in the
new stanard kernels (e.g. 2.5)?
It's currently being merged into 2.3.X and will be in 2.4 when it comes out.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: System Hangs -- Which Is Most Stable Kernel?
On Sat, 25 Mar 2000, Jeff Hill wrote:
Which is currently the most stable kernel that supports new-style RAID?
My system hangs for 30 seconds to 5 minutes several times a day using a
vanilla kernel 2.2.14 from ftp.kernel.org with a 2.2.14 RAID patch from
Redhat on my Debian (Potato version) server. When the system hangs, it
doesn't crash and it responds to a few basic requests ('ls' for example)
but nothing else (not even 'ls -l'). Then, it proceeds to fill the
request. I've looked through the dmesg, system and
kernel logs and have found nothing out of the ordinary. I've tried
kernel 2.2.10 with similar results.
Is it a SMP system ?
My mdstat reads:
Personalities : [linear] [raid0] [raid1] [translucent]
read_ahead 1024 sectors
md0 : active raid1 sdb2[1] sda2[0] 8739264 blocks [2/2] [UU]
unused devices: none
Disable translucent mode ! It's not intended to be used yet.
I wouldn't know if this can cause you any trouble, but translucent
mode is definitely not something you want to have turned on.
At the same time I updated the system to Debian Potato, the new kernel
and RAID-1, I also added an Adaptec 2940U2W SCSI controller and a
matching pair of Cheetah drives, but nothing in the new hardware seems
problematic. I've got the Redhat lilo installed so that I boot the RAID
from root, and /boot directories on both disks are on separate, non-raid
partitions.
I've been using Linux for several years, but I'm unable to determine
where the problem is -- I just suspect the kernel. Any suggestions on
the most stable kernel or on how to troubleshoot this appreciated.
Also, is there any searchable archive of the linux-raid list? Wish I
would have found this list _before_ I built my raid.
It sounds pretty strange what you're seeing. It would be very interesting
to see if you could reproduce your problems without RAID. You're running
RAID-1, so you should be able to just don't start the RAID devices, and
then mount one of the mirrors disregarding the /dev/mdX devices.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: a question or two
On Fri, 24 Mar 2000, Herbert Goodfellow wrote:
I got your message about the "really force" flag when trying to use the -f
option with the /sbin/mkraid Linux utility. I am running Slackware and have
gotten confused by the man pages and the errors I am getting. What is the
"really force" command line option?
Below you refer to the old-style RAID in the stock kernels which is considered
unstable or at least out-dated by many. Quite a few (most ?) people on this
list use the new-style RAID, referred to as 0.90 RAID, and that's where the
``really force'' stuff comes into the picture.
See http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/ for an explanation.
Also, simple steps to creating a raid1 cfg on an IDE bus:
1) identify the devices [hdc, hdd]
Yep
2) create file systems on them?
No why ? They're about to be combined into a new block device, they're
not in their final form yet.
3) run mdadd -ar after you have modilfied the /etc/mdtab?
this gives me an "I/O error on hdd" everytime I do this. . .
Nope. mdadd is old-style RAID.
4) configure the /etc/raidtab
Yes ! With 0.90 RAID there is one configuration file, /etc/raidtab, and even
this will be unneeded once the array is up running, because the new-style RAID
keeps the configuration in superblocks on the devices participating in the
array. (But you might want to keep the config file anyway - just in case :)
5) run "/sbin/mkraid -f -c /etc/raidtab /dev/md0" and get the "if you force
it you
might loose data" message. I know there's no data on the drives, but I am
missing the "really force it" option.
The option will be printed for you once you install both a kernel with new-style
RAID, and the proper raidtools for that kernel. Again, see the HOWTO.
I know I am confused. Could you provide me with any feedback and/or a
pointer in the right direction?
Hope this helps you more than it confuses you.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.....: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: failed disks
On Tue, 21 Mar 2000, Seth Vidal wrote:
Hi,
I'm doing a series of bonnie tests along with a fair amount of file
md5summing to determine speed and reliability of a raid5 configuration.
I have 5 drives on a TekRam 390U2W adapter. 3 of the drives are the same
seagate barracuda 9.1 gig drive. The other two are the 18 gig barracuda's.
Two of the nine gigs fail - consistently - when I run bonnie tests on
them. One will get flagged as bad in one run and die out. This one I can
confirm is bad b/c it fails on its own outside of the raid array (it
fails to be detected by linux at all - no partitions are found and it
can't be started) - the other passes a badblocks -w test and appears to
work. However it ALWAYS fails when its a part of the array and a bonnie
test is run.
Does this sound like a hardware fault? If so why is it only occurring when
raid is used?
You can most likely trigger it too if you run non-RAID I/O on all the disks
simultaneously.
It sounds like you have a SCSI bus problem, bad cabling / termination etc.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID0: Fast writes, Slow reads...
On Tue, 14 Mar 2000, Scott M. Ransom wrote:
Hello,
I have just set up RAID0 with two 30G DiamondMax (Maxtor) ATA-66 drives
connected to a Promise Ultra66 controller.
I am using raid 0.90 in kernel 2.3.51 on a dual PII-450 with 256M RAM.
Here are the results from bonnie:
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1200 6813 98.2 41157 42.0 10101 25.9 5205 78.9 14890 27.3 137.8 1.8
Seems like my sequential block writes are 3 times faster than the
reads. Any idea why that would be?
Someone (Probably Andre Hedrick, or perhaps Andrea Arcangali -- sorry guys, I
don't recall) explained this on LKML. Out of my memory it has something to do
with ATA modes and the kernel configuration. You haven't enabled ``Generic
busmaster support'', or perhaps one of the other IDE driver options, I don't
exactly remember which. But I was going to try it out myself as I see the same
odd numbers on a test system.
If you experiment a little and find the right option, please post here :)
Or search the LKML archives, the mail was posted last week (I think).
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID1 problems on raid-0.90
On Sun, 12 Mar 2000, Ed Byrne wrote:
I just set up a RAID on a machine with the following setup.
Linux 2.2.14 + raid-2.2.14-B1 patch, raidtools-19990824-0.90
sda1: boot partition (256mb)
sda2: raid-disk 0 (8.5gb)
sdb1: swap (256mb)
sdb2: raid-disk 1(8.5gb)
Setup was fine and it worked great, until I actually tested drive loss.
I pulled sdb2, and it detected the loss and said it was continuing in
degraded mode as I expected. Then I hard rebooted the machine. After
that, it refused to use the second drive in the mirror.
Yes, the kernel doesn't automagically snatch any new block-device it sees
and starts using it as a new mirror. That's on purpose.
The md recovery thread does not seem to see that it is there, after it
refuses to use it. I've tried dd'ing sda2 to sdb2, zero'ing sdb2,
changing the partition type to ext2 and then back, and still get the same
error. Manually stopping and restarting using raidstop/raidstart seems to
do the same thing, except it doesn't even see sdb2 at all. /etc/raidtab
and raid1.conf are both set up properly according to the documentation.
How about manually adding (with the hotadd command) the drive ?
[snip]
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: to swap or not to swap . . .
On Sat, 11 Mar 2000, Frank Joerdens wrote:
I found a discussion after all:
http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/Software-RAID.HOWTO-2.html#ss2.4
Jakob says it's OK to swap on RAID.
I'd just like to clarify that :)
From the 0.90.7 version I quote:
There has been a lot of discussion about whether swap was stable on RAID
devices. This is a continuing debate, because it depends highly on other
aspects of the kernel as well. As of this writing, it seems that swapping on
RAID should be perfectly stable, except for when the array is reconstructing
(eg. after a new disk is inserted into a degraded array). When 2.4 comes out
this is an issue that will most likely get addressed fairly quickly, but until
then, you should stress-test the system yourself until you are either satisfied
with the stability or conclude that you won't be swapping on RAID.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Benchmarking.. how can I get more out of my box?
On Wed, 08 Mar 2000, Brian Pomerantz wrote:
On Wed, Mar 08, 2000 at 09:14:02PM +0100, Holger Kiehl wrote:
Why don't you try SW raid?
The Mylex controllers I have don't do SCSI, it presents a block
device. I think I'm going to try these drives on my NCR controller
just to get a base-line on what kind of write performance they are
capable of. Maybe I'll try software RAID when I do that. What sort
A benchmark of the SW vs. HW results would be _very_ interesting to a
lot of us (hint, hint :)
of CPU usage does software RAID use? Also, does it work on the Alpha
There's next to no CPU overhead in SW RAID levels -linear and -0. Their
overhead is barely-measurable, as no extra data is copied and no extra requests
are ussued. (It's simply a re-mapping of an existing request)
Level 1 has some overhead in the write case, as the write request must
be duplicated and sent to all participating devices. This is mainly a
RAM bandwidth eater, but it will show up as extra CPU usage.
Levels 4 and 5 do parity calculation. A PII 350MHz is capable of parity
calculation of 922 MB/s (number taken from the boot output). This means that
on virtually any disk configuration one could think of, the XOR overhead
imposed on the CPU would be something like less than 10% of all available
cycles. In most cases more like 1-2%, and that's during continuous writing.
Another overhead in -4 and -5 (and probably by far the most significant) is
that in order to execute a write request to the array, this request must
be re-mapped into a number of read requests, a parity calculation, and then
two write requests (one for the parity). Even though this sounds expensive
in terms of CPU and maybe latency, I would be rather surprised if you could
build a setup where the RAID-5 layer would eat more than 10% of your cycles
on any decent PII.Now compare 10% of a PII to the price of the Mylex ;)
platform? Last time I tried to get it working (granted I didn't spend
a lot of time on it), I was unable to get very far.
Sorry I don't know.
In the end, I don't think software RAID is an option for HPC. It is
likely in a production system we will want to have a great deal of
space on each I/O server with many RAID chains on each of them. I
don't think I would see the best performance using software RAID. To
You don't _think_ you would see better performance ?
I'm pretty sure you will see better performance. But on the other hand, with a
large number of disks, sometimes the hot-swap capability comes in handy, and
sometimes it's just nice to have a red light flashing next to the disk that
died. Hardware RAID certainly still has it's niche :) - it's just usually
not the performance one.
add to the complexity, I'll be doing striping across nodes for our
cluster file system. Probably what will happen is I'll use Fibre
Channel with an external RAID "smart enclosure". This will allow for
more storage and more performance per I/O node than what I could
achieve by using host RAID adapters.
Ok, please try both SW and HW setup when you get the chance. This is a
situation that calls for real numbers.
However, when we're speculating wildly anyway, here's my guess: Software RAID
will wipe the floor with any hardware RAID solution for the striping (RAID-0)
setup, given the same or comparable PCI-something-disk busses. (And for
good reasons, hotswap on RAID-0 is not often an issue ;)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Benchmarking.. how can I get more out of my box?
On Wed, 08 Mar 2000, Brian Pomerantz wrote:
On Thu, Mar 09, 2000 at 12:44:32AM +0100, Jakob Østergaard wrote:
You don't _think_ you would see better performance ?
I'm pretty sure you will see better performance. But on the other
hand, with a large number of disks, sometimes the hot-swap
capability comes in handy, and sometimes it's just nice to have a
red light flashing next to the disk that died. Hardware RAID
certainly still has it's niche :) - it's just usually not the
performance one.
If there isn't hot-swap RAID 5 with auto rebuild, it will never
happen.
I meant; SW usually has really good performance, not HW is unsuitable for HPC.
Anyway I had the impression that you were looking for the hightes possible
performance from RAID-0 sets. I see from your reply that I misunderstood the
proportions of your storage needs.
Sure with external storage solutions, it may still be far the easiest to use a
simple interconnect and let the external disk solution take care of the RAID
logic. And given what one will have to pay for this anyway, going SW is
probably not the way to cut costs in half.
SW RAID is beautiful for a handfull or three of disks, but when you're working
with hundreds of disks the administrative costs of not-so-flexible-if-any
hotswap is a killer. I still maintain that it would be interesting to see
software RAID-0 on this size of systems though, as hotswap usually doesn't
matter so much on RAID-0 anyway. That will be a 2.4 task though, as the
SW RAID in 2.2 is not able to handle this number of disks.
It would be nice if a program such as ASCI could put the resources needed
into Linux to actually get decent hot swap capability... Let's see what
happens.
Cheers,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Newbie
On Sun, Feb 06, 2000 at 11:34:32PM +, Glenn McGrath wrote:
Second thought: It would be nice to have something like RAID-5 but with the
Hamming code instead of only parity. If that could be done with decent
performance, that would be interesting:)There probably already is
some semi-unofficial number assigned to that level.
If you have some time, I would suggest improving on the existing code. There
still are /* FIXME */ places in the 0.90 code (they aren't critical, but they're
there). Especially 0.90 support in 2.3 needs help - talk to Ingo about that
(he's probably _very_ busy, so don't be surprised if he can't answer immediately)
Ive been wanting to implement a raid-6 mode for a while, not quite
confident enough to take on the task.
Jakob : How large a task do you think it would be to implement raid6 ?
I don't know. From what I could read, RAID-6 is RAID-5 with two parity blocks
per stripe instead of one. I'm not sure about this, but I would guess that
changing the existing RAID-5 code to RAID-6 behaviour would be quite doable.
But look at the code, I'm guessing here... I just don't know the RAID-5 code
well enough.
There are some other people here on the list who have better insight into these
matters :)
From www.whatis.com "RAID-6. This type is similar to RAID-5 but includes
a second parity scheme that is distributed across different drives and
thus offers extremely high fault- and drive-failure tolerance"
By having two parity schemes and implementing a 2-dimensional parity it
would enable ultimate versitility in redundancy vs efficiency. It could
doing the normal hamming codes.
2 dimensional ?If it's RAID-5 of RAID-5 arrays, you can do it already.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid 0.90 for 2.3? (+ RFT!)
On Sun, Jan 23, 2000 at 01:43:38PM +0100, Holger Kiehl wrote:
...[snip]...
Here is my original post from 17th January:
On Sun, 16 Jan 2000, Ingo Molnar wrote:
here is the first alpha version of the '2.4 RAID merge' patch against
pre4-2.3.40:
http://www.redhat.com/~mingo/ibc-ext2-raid-2.3.40-N1
Doesn't work for me. When booting system locks up with the following output:
ll_rw_block: Trying to read nonexixtent block-device 09:01 (1)
EXT2-fs: unable to read superblock
Invalid session number or type of track
Invalid session number
ll_rw_block: Trying to read nonexixtent block-device 09:01 (32)
isofs_read_super: bread failed, dev=09:01, iso_blknum=16, block=32
Kernel panic: VFS: Unable to mount root fs on 09:01
[Note: I copied this by hand]
System is a dual PIII-450, 256MB ECC, 6 IBM DNES 9GB LDV, ASUS P2B-DS with
onboard Adaptec U2W controller, kernel 2.3.40-pre4, RH 6.1. /boot is RAID1,
/ is RAID5 and /home is RAID0.
Did I forget anything? What did I do wrong?
I tried 2.2.40pre4 with the RAID patch as well. Boot support doesn't compile
and neither does RAID5 support. With those disabled I was able to compile the
kernel and boot a system (IDE though).
But the kernel was shaky as h*ll :)
Swap partitions didn't work, swap-files did ``sort-of''. Processes was killed
with OOM etc. etc. All in all not a very pleasing experience.
I guess one should either just try out new kernel patches (.41pre etc.) or take
the time it takes to help development and bugfixing. I hadn't expected the .40
kernels to be that shaky (I ran late .3X kernels with a fair amount of success)
but somehow there's been a lot of changes lately needing testing a fixing. It's
probably all for the best, this way we won't get unoccupied and hang around the
street corners selling crack and stuff;)
Seriously though, there's a lot of interesting testing fixing to be done. I
underestimated that when I asked people to just give the RAID patch a lot of
testing. My bummer, I should have tested it myself before asking others.
Cheers all,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid 0.90 for 2.3? (+ RFT!)
On Sat, Jan 22, 2000 at 12:38:04AM -0500, Joseph Malicki wrote:
Is there a raid patch for 2.3 kernels? Or are they already in? I recently
tried to run 2.3.39 recently and it couldn't find my RAID array created
with RedHat 6.1..
http://people.redhat.com/mingo/
Try the ibc-ext2-raid-2.3.40-N12 patch.
To everyone on linux-raid:
It seems improbable that the 0.90 raid stuff will go into 2.4 currently. This
is catastrophic. We need to try Ingo's patch, and give it all the testing we
can. If enough people try the patch and we can give a reasonable argument that
it is stable - possibly after ironing out any errors there might be - it
_could_ go into 2.4. We want this to happen.
It is important that we get a decent RAID subsystem in the 2.4 kernel. But this
will not happen unless we give Ingo's new stuff a *lot* of testing.
I will test on two systems (at least), and I beg everyone out there who have a
spare system to try the patch too. Find the bugs, report performance
differences to linux-kernel and linux-raid, and let's get a decent RAID
subsystem in 2.4.
Thank you everyone,
(side note: I've been pulling 14hr working days currently so there hasn't been
much time for RAID'ing. I haven't been following the raid-list closely, so if
I've missed requests/comments please resend to me privately.)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Swapping in the HOWTO
On Sun, Dec 26, 1999 at 03:26:07PM -0500, Andy Poling wrote:
On Sun, 26 Dec 1999, Johan Ekenberg wrote:
As I see it, either the HOWTO is wrong, Mr Berra is wrong, or I'm not really
understanding what the HOWTO is saying. In the first case it would be good
to correct/expand the HOWTO, in the other cases I would be very happy for a
clarification from Mr. Ostergaard or any other authority on RAID. I'm
currently using a swapfile on a RAID-5 device since I assumed this would
offer the best protection from a disk crash.
Putting your swap on a RAID'd partition _should_ theoretically provide the
best protection, but unfortunately, the way that software RAID handles
re-synching (after loss of a disk, or simply after an unclean shutdown), it
is not safe. You could consider this a bug or a design fault, but either
way it rules out swapping on software RAID.
Am I correct in assuming that it is _ONLY_ under reconstruction that swapping
on RAID is not safe ?
I've been rather busy lately (still am) so I didn't read the bug report... Is this
reconstruction/swap bug present in all RAID levels (with redundancy of course) or
is it limited to RAID-5, -1, or -4 ?
This problem really only came to light recently. Therefore the FAQ was
written without knowledge of the problem...
Originally the HOWTO had a nice explanation as to why it was NOT safe to
swap on RAID, but then the bugs were corrected (the known ones at that time
at least) and the statement was corrected accordingly. I'll correct it once
again, as soon as I know exactly what to write:)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Swapping in the HOWTO
On Sun, Dec 26, 1999 at 08:32:13PM +0100, Johan Ekenberg wrote:
According to Mr. Luca Berra -- [EMAIL PROTECTED], swapping on RAID is not
safe. This is an excerpt of our discussion on the list just recently, I'm
the one starting, commenting on a regular swap setup with several non-RAID
swap partitions:
[snip]
As I see it, either the HOWTO is wrong, Mr Berra is wrong, or I'm not really
understanding what the HOWTO is saying. In the first case it would be good
to correct/expand the HOWTO, in the other cases I would be very happy for a
clarification from Mr. Ostergaard or any other authority on RAID. I'm
currently using a swapfile on a RAID-5 device since I assumed this would
offer the best protection from a disk crash.
The HOWTO is wrong. It's a long story, but swap on RAID has historically been
anything between ``safe'', ``unsafe'', ``somewhat safe'', ``it works for me - safe'',
``my machine blew up - safe''.
I'll try to keep the advise in the HOWTO updated to the current safeness-state
of the code ;)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: vanishing data under software raid
On Wed, Dec 22, 1999 at 12:59:22PM -0700, Jason R. Mastaler wrote:
We are having a peculiar problem with Linux software RAID on a new
fileserver. The server is running kernel 2.2.12 configured to support
both RAID-5 and RAID-0. We are using raidtools-0.90-5 which came with
this redhat-based installation. On this machine, we have two raid
devices configured: md0 is a 7 disk RAID-5 array, and md1 is a 3 disk
RAID-5 array (see attached /etc/raidtab below for configuration
details)
2.2.12 with RAID patch ? Did you apply the patch yourself ?
Try 2.2.13ac3 instead. Or 2.2.14ac1 as soon as it gets out. Those
kernels have RAID support (well, presumably 2.2.14ac1 will have too),
and some filesystem bugs have been corrected lately.
The problem is that the data on md0 just disappears for no apparent
reason and with no indications in the logfiles. This is terribly
repeatable. Once /dev/md0 is mounted, all files and directories
placed there will not last more than two hours. They just vanish
without a trace. Re-creating and re-formatting md0 doesn't help. We
have even tried a different raid level (zero) on md0 and have the same
problem.
This must be a filesystem problem, not a RAID problem. If the RAID
device was losing data, the filesystem would be lost too, and you would
be unable to mount the device.
Try e2fsck -f /dev/md0
If that one doesn't give you errors, the RAID works perfectly. Something
else is biting you.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Help:Raid-5 with 12 HDD now on degrade mode.
On Mon, Dec 20, 1999 at 08:49:42AM +0900, Makoto Kurokawa wrote:
Hello, All.
I have a trouble of HDD fail of raid-5,raid-0.90 on Redhat 6.0.
Raid-5 is now working on degrade mode.
Exactly, Iacan't repair or replace the failed HDD (to new HDD).
Woule you tell me how to do recovery it?
"/proc/mdstat" is as follows:
[root@oem /root]# cat /proc/mdstat
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 sdm1[11] sdl1[10] sdk1[9] sdj1[8] sdi1[7] sdh1[6] sdg1[5]
sdf1[4] sde1[3] sdd1[2] sdc1[1] 97192128 blocks level 5, 4k chunk, algorithm 2
[12/11] [_UUU]
unused devices: none
First, I restarted the PC and tryed "raidhotadd" and "raidhotremove" ,the
result is as fllows:
[root@oem /root]# raidhotadd /dev/md0 /dev/sdb1
/dev/md0: can not hot-add disk: disk busy!
[root@oem /root]# raidhotremove /dev/md0 /dev/sdb1
/dev/md0: can not hot-remove disk: disk not in array!
Ok, so it's /dev/sdb1 allright.
Next, I replaced HDD,/dev/sdb to new HDD, the result, system hung-up on boot
time.
Are you *SURE* that you assigned the same SCSI ID to the new disk ?
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Replacing disks in RAID
On Sun, Dec 19, 1999 at 02:05:24PM +0100, Marcin Zurakowski wrote:
Hi,
I've got Redhat 6.1 with kernel 2.2.12 and raidtools-0.90.
I've made a raid array (raid-5) from 3 disks (/dev/hda1, /dev/hdb1,
/dev/hdc1)-no spare disks. If the one disk (for expample /dev/hdb1)
fail everything will be ok. Then I want to replace this bad disk
with new one. What should I do to make this new disk work with
array (without erasing data)... I mean, attach this disk to array, to have
raid in state like in begining.
From the HOWTO:
8-8
6. Reconstruction
If you've read the rest of this HOWTO, you should already have a pretty good
idea about what reconstruction of a degraded RAID involves. I'll summarize:
Power down the system
Replace the failed disk
Power up the system once again.
Use raidhotadd /dev/mdX /dev/sdX to re-insert the disk in the array
Have coffee while you watch the automatic reconstruction running
And that's it.
8-8
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: FW: Ugh . . .
On Sat, Dec 18, 1999 at 09:13:39AM -0700, Eric Jorgensen wrote:
That would be a correct assesment. I've gotten the new howto, and new
raidtools - which kernel should i be using, or who's patch should i apply to standard
kernel source?
Problem is, if your current array was built with the old raidtools/kernel, you should
not upgrade the raidtools/kernel before the recovery, but instead get old raidtools to
go with your current kernel and array. Problem is that the failed-disk patch is for
the newer raidtools. Apply the new patch to the old raidtools (manually if required).
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Ugh . . .
On Fri, Dec 17, 1999 at 10:37:30AM -0700, Eric Jorgensen wrote:
OK, here's the lowdown.
I have, well, had, 4 drives in a raid 5 array. drive 4 went south, drive 3
is desynced.
What ? How ? You lost two drives in your RAID-5 ?
I've replaced drive 4 with a fresh drive. (Seagate Medalist drives are the
bane of my existance).
So, at this point, I've seen the messages regarding --really-force, and,
well, i'm sufficently nervous.
Is there any way i can realisticly recover a signifigant portion of the
data?
If I'm right in the following, I have a suggestion:
1) Drive 4 died, physically
2) Because of intergalactic interference or whatever, drive 3 has an event count
lower than drives 1 and 2, and therefore the array won't start in degraded mode.
Right ?
If so:
I would guess that you could change drive 4 in the raidtab to be a ``failed-disk'',
and then use --fuckallqueries (you know the right flag ;) to force the array back
online. I *THINK* that would work.
Afterwards, you would raidhotadd the fresh drive 4 to the array, to get redundancy
back up.
This should bring back all your data.
PleasePlease: Before you actually do this, wait for a little while to allow someone
on this list to jump in and say "DON'T!", if appropriate.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid-1 mirror...
On Fri, Dec 17, 1999 at 10:23:54AM -0800, Jeff Behl wrote:
If anyone wants to point me to the mailing list
archive or faq, that'd be great cuz I'm sure this has
been asked before. But I'll ask anyways..
Have two drives in which all partitions are mirrored
except for / partition. My game plan is: If a drive
dies, I want to
a) have the machine keep on chugging along without any
notice. or, if this is not possible,
b) swap one drive with the other (they're in caddies)
and have everything working on reboot.
(b) would occur if my hda drive, which has / mounted
on it, dies. I'm assuming in such a situation the
machine would lock up (I realize that if drive hdb,
the second in array, dies, everything should keep
going no prob...)
Any tips/ideas? Would mirroring the / partition (I
don't know how stable/good-of-an-idea this is at this
time) be the way to go? Sorry if this question has
been asked a hundred and one times...
With 0.90 RAID (included in the -ac series of the kernels) this
is absolutely possible. Make all the partitions RAID-1 devices,
and put your filesystems there. It's no problem (any longer) making
both root and swap reside on RAID.
With IDE your system will most likely keep on running if a disk
fails with bad sectors. Other failures, especially failures on
SCSI (due to the state of the SCSI layer in the kernel) may require
a reboot/powercycle to get the machine up and running again.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: FW: Ugh . . .
On Fri, Dec 17, 1999 at 04:32:14PM -0700, Eric Jorgensen wrote:
My last mail to you bounced, so I'm trying again. Sorry if anyone
gets this twice...
On Fri, Dec 17, 1999 at 03:41:37PM -0700, Eric Jorgensen wrote:
Well, I tried, something seems to be wrong. I had to update raidtools to
include the failed-disk directive. that took a while to figure out. someone
needs to tap linuxdoc.org on the shoulder and inform them their
software-raid-howto is painfully out of date. I'd do it myself but there are
too many blunt objects handy.
http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/ is the place for the current
0.90 software RAID howto.
ANYway, here's what happens. Sensitive argument replaced per request.
[root@charlotte /root]# ./mkraid --truly-foolish /dev/md0
DESTROYING the contents of /dev/md0 in 5 seconds, Ctrl-C if unsure!
handling MD device /dev/md0
analyzing super-block
disk 0: /dev/sdd1, 8883913kB, raid superblock at 8883840kB
disk 1: /dev/sde1, 8964238kB, raid superblock at 8964160kB
disk 2: /dev/sdb1, failed
disk 3: /dev/sdc1, 8883913kB, raid superblock at 8883840kB
mkraid: aborted, see the syslog and /proc/mdstat for potential clues.
---
And here's what dmesg reveals:
---
bindsdd1,1
bindsde1,2
blkdev_open() failed: -19
md: [dev 00:00] has zero size, marking faulty!
md: error, md_import_device() returned -22
---
And here's my raidtab. Sorry for the confusion, sdb is visually marked "4"
on the front of the case. Longer story.
Gosh, something is just coming to my mind here... I was convinced that you
were running 0.90 RAID, since most people posting on the list are (stupid
assumptions come easy). But I guess you aren't... Right ?
You're running a kernel with standard RAID, not an -ac or raid-patched kernel I
guess... That means the new raidtools (which understand "failed-disk") will
not talk to your kernel.
I see one way out: Patch your old raidtools (version 0.42 or so ?) to
understand the failed-disk directive. This may involve manual inclusion of
some patch rejects. Maybe not. Don't know.
If I'm really right that you're running the old code, you probably want to
upgrade to 0.90 once your data are back :) The new code is stable, and the
old code isn't (you can usually crash a RAID-5 box by stressing the RAID with
the old code).
Another way out would involve upgrading your old array to the new format, using
the --upgrade switch, but I doubt that it is a very clever thing to do with the
current state of your array...
The failed-disk patch is fairly small. I guess you can apply it pretty quickly
even if it doesn't apply cleanly to the older raidtools.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: CDrom
On Wed, Dec 01, 1999 at 04:30:45PM -0800, Terry Ewing wrote:
Okay, my understanding of the Linux software RAID is minimal so this may be
extremely naive. Is is possible to burn say, 3 CD's, and use the Linux
RAID to work across the ROMs? ItI'm thinking of an application where a
read-only filesystem of 1gig+ is needed. It doesn't need to be extremely
fast and it won't be reconfigured often. Is this possible?
Well, anything's possible if you have the time.
But 3 CDs 2 GB. You will see _much_ better performance (especially with
multiple users) from a single harddrive.
I can't think of a good reason to use CDs for permanent storage anymore.
Back in the days where 600Megs was a lot, sure, the hottest thing was a
CD tower. But today with 27G disks flying around at the same cost as my
(now fairly old) dual-spin CD drive, it really is cheaper, faster and
easier to just copy the CD contents to the harddrive.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: strange messages from raid5
On Thu, Dec 02, 1999 at 12:11:33PM +0800, Deanne O'Connell wrote:
Hi all,
I am running redhat 6.0, with kernel 2.2.13 all patched up to run raid, on a
dual celeron 400 system.
I have 3x 18.2 gig atlas 4 lvd drives all on one cable, configured as
follows;
[snip]
Ok, RAID usually works, so start by looking elsewhere:
*) Which compiler do you use ? (gcc -v)
*) What kernel exactly ? 2.2.13+raid_patches or 2.2.13acX or ?
Of course you system isn't overclocked, right ? :)
What about the memory ? You don't receive sig-11 messages from gcc
when compiling the kernel or something ?
RAID _should_ work, these errors are almost always caused by hardware or
not-directly-raid-related software.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID and Ultra66
On Sun, Nov 28, 1999 at 06:37:46PM -0500, [EMAIL PROTECTED] wrote:
On 28 Nov, [EMAIL PROTECTED] wrote:
[clip]
If the controller is built right, there is some potential for a performance
increase. The idea is to have more than one drive simultaneously reading
into it's buffer (they run about .5M these days). Assuming each drive stays
busy, ie, as would be the case in large sequential transfers, it is possible
to produce a rate at the host that approaches the combined rate of the
drives. Same theory holds for SCSI, or Fibre Channel, for that matter.
[snip]
The problem with UDMA or any other IDE derivative is that only one
device can communicate on the bus at a time. In the case of a
SCSI is the same. There is only one message running on the bus at any
given time.
SCSI just has a way better way of letting devices share the bus. That's
where IDE fails tremendously. But with the current cost of IDE drives
versus SCSI drives, I'd say it's quite reasonable to use IDE drives for
arrays with up to say 6-8 disks. You can buy enough controllers to
still just have one drive on each bus.
master/slave situation, you're looking at no better than single-drive
performance (caps at about 20MB/s for really good drives). For a
controller with two channels, primary/secondary, you can get double
performance, in theory. So in theory you're looking at no better than
40MB/s with RAID-0. With UDMA somewhat more realistic numbers are
Except that someone just posted 50+ MB/s on RAID-5 with IDE ;)
That was with enough controller though. That's the secret.
probably half that, as I understand it. Someone on here who has more
experience (I only use SCSI so I'm not an authority by any stretch of
the imagination), and I know there are plenty, can probably give you
better figures. I'm just regurgitating what I've seen time and time
again on this list in the past.
You're absolutely right, that given you only have one bus, SCSI is
superior. But that's not a valid point for a lot of small arrays. You
can easily afford enough controllers with the price advantage on IDE
disks today.
The problems start when you need more disks. SCSI is still the way
to go for 10+ disks. Oh, and the cable length restrictions with IDE
are also terrible. But when you run out of space in your cabinet,
you'll most likely also have run out of PCI slots for more controllers,
so there's a nice balance there ;)
I use both SCSI and IDE RAID systems, and I get a very nice performance
from all of them. The performance matches what I could expect.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID and Ultra66
On Sun, Nov 28, 1999 at 05:55:24PM +, Darren Nickerson wrote:
...
Thanks for the reply Jakob. :-P I used to be the same . . . now I'm bitter and
twisted. Well, mebbe just twisted.
;)
...
How ``bad'' is the performance ?
It was at one point about 4MB/s . . . I nuked that kernel ages ago though, and
am back on 2.2.13ac2, which reports itself as 2.2.13ac1, and things are OK
again . . .
4MB/s is low. hdparm -t /dev/mdX should give you pretty much the speed you can
get from one single drive, probably more like 10-12 MB/s.
And yes, -ac2 identifies itself as -ac1, it's a feature:)
...
Some marketing guys did one hell of a job, promoting ATA66. There's a lot
of people out there, believing that it makes a difference...
Yup, sorry to have been so naive.
Don't be, I had to test it out myself too. There's just nothing like good
old marketing hype;)
Oh well, in three years any decent IDE drive will do 50 MB/s from the platter,
and all those ATA66 cards will come in handy.:)
I live in hope. Disk I/O is such an annoying bottleneck . . . raid makes it
more bearable of course. Benching my raid5 array now . . .
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
2000 7818 98.9 31010 28.0 13601 28.3 8328 97.5 36487 26.3 113.4 1.5
I have a feeling this is not bad at all ;-) Time to play witch chunk size and
mke2fs options.
Nice !
Use 4k blocksize on the ext2. The chunksize doesn't matter much on bonnie tests,
but you might see a difference in real-world usage. I'm afraid I can't contribute
with many tips there... We could use another benchmark than bonnie...
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid-1 and raid-5 performance: odd
On Mon, Nov 29, 1999 at 02:58:42AM -0500, Remo Strotkamp wrote:
Hi there,
first of all thanx for all the replies concerning my previous mail.
second: hi jakob and here are the single mode bonnie results...
Thanks :)
I have done some basic benchmarking in single user mode, and got strange
results:
First of all the setup:
I have a raid-1 partition of 64MB over all 8 disks, as well as a raid-5
over 5 disks a 19GB each.
Now as I have 128MB of RAM, I used the mem=16m for reducing the amount
of memory to get
reasonable results for my raid-1.
If you use a filesize large enough, (like 200-500 megs) you can safely run
with the 128 megs enabled. I'm not sure how mem=16m will affect the
performance.
Here they are:
...
Then I ran bonnie two times with the full amount of memory:
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
2047 7184 90.2 28856 23.2 17191 32.5 8301 97.5 60630 43.0 201.1 3.7
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
2047 7183 90.2 29521 24.1 17086 31.7 8305 97.5 60009 43.3 201.6 2.8
That's more like it!:)
I also used hdparm -t and the raid1 achieves 32MB/s while raid5 achieves
55MB!!!
I am really confused by those results, especially by the reading
performance.
There are 8 disks in the raid1 and only 5 in the raid5, so I would
expect the raid1 beeing lots faster,
as reads are spread in parallel over lots more of disks!! But it
seems to be alot slower
Contrary to what the HOWTO says (ouch!) RAID-1 doesn't (yet) distribute
reads over the disks. RAID-5 does (has to).
Mika Kuoppala is working on a patch that makes RAID-1 distribute reads over the
disks. Hopefully in the not-too-distant future, you will see better
performance from RAID-1 in many cases.
It's pretty hard to make RAID-1 run faster in a bonnie test, as bonnie works
with one file only. But in a production environment, many files are usually
accessed simultaneously, and it should be possible for RAID-1 to scale there.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Best partition scheme on HW RAID-5 ?
On Sun, Nov 28, 1999 at 01:27:21AM -0500, [EMAIL PROTECTED] wrote:
On Sat, 27 Nov 1999, [iso-8859-1] Jakob Østergaard wrote:
Actually, nothing should stop you from putting the OS on software RAID either.
Doesn't at least /boot need to be on at most a RAID1 when using software
RAID...since boot loaders (like lilo) generally don't know how to read
from RAID5?
You're right.
So that's 10 megs you have to spend on each drive to make a raid-1.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Best partition scheme on HW RAID-5 ?
On Fri, Nov 26, 1999 at 11:06:49PM -0500, [EMAIL PROTECTED] wrote:
On Fri, 26 Nov 1999 [EMAIL PROTECTED] wrote:
...
Where did you read that putting the OS on RAID was a no-no? I think you
got some bad info, or maybe remember it incorrectly. If you're using
hardware RAID, there's nothing stopping you from booting from (and having
the OS on) RAID volumes.
Actually, nothing should stop you from putting the OS on software RAID either.
Back in the old days, putting the OS on RAID was difficult. With the 0.90 RAID,
this is quite doable. The only major hazzle is that most installation programs
doesn't allow installation on RAID. I think RedHat 6.1 somewhat fixes this (I
haven't been successfull with it myself though, but only tried once).
See the HOWTO (http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/) for a
step-by-step guide.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID and Ultra66
On Sun, Nov 28, 1999 at 03:14:15AM +, Darren Nickerson wrote:
...
It appears to me that of four identical Maxtor 27GB drives, two will do 66 and
two will only do 33:
I've seen others report this as well. But I don't know IDE stuff (I just use it
and smile when it works ;)
ATA66 is going to buy you between 0 and 1% performance over ATA33 with any
current disks. Don't wory, be happy.
...
Even more disappointingly, a raid1 array of hde and hdg shows identical
performance to a raid1 array of hdi and hdk.
As stated above, ATA33 and -66 doesn't make a difference with disks that
couldn't saturate an ATA20 if that one existed.
How ``bad'' is the performance ?
After about 30 hours of work on the Promise setup, I can conclude that raid
works fine, but the Ultra66 driver (or my Maxtor disks implementation of
Ata-66) is just not ready for prime-time. It was just never any faster than my
onboard (33MHz) ide.
What did you expect ? You drive can transfer something like 15MB/s (give and
take). Putting it on a bus that can do 66MB/s isn't going to make your drive
spin faster.
Some marketing guys did one hell of a job, promoting ATA66. There's a lot
of people out there, believing that it makes a difference...
Oh well, in three years any decent IDE drive will do 50 MB/s from the platter,
and all those ATA66 cards will come in handy.:)
Cheers,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: RAID and Ultra66
On Fri, Nov 26, 1999 at 04:04:03PM +, Darren Nickerson wrote:
Folks,
I'm looking for the recommended way to cobble together a kernel which will
support both RAID and the new Ultra66 66MHz ide interface cards (a nice cheap
way to run a decently zippy RAID array, if I do say so musself ;-) ). As I
see it, I have the following options:
1. linux-2.3.x branch
- Ultra66 support works
- RAID support absent
2.3 is intentionally unstable. Don't do this unless you want to help kernel
development with reports of a badly messed up array :)
2. linux-2.2.13 + ide.2.2.13.1999.patch + raid0145-19990824-2.2.11
- ide patch SEEMS to apply on top of raid0145, rejects appear minor,
but not yet tested
Use -ac, it has working RAID.
3. linux-2.2.13 + patch-2.2.13ac3 + ide.2.2.13.1999.patch
- simply a mess of rejects
-ac2 will work with the IDE patch you mention. I'd say that's the way to go.
AFAIK there are no major issues with -ac2 compared to -ac3 for most systems. (You could
check out Alan's changelogs)
4. linux-2.2.14-pre
- no idea.
Me neither. Wait for 2.2.14-acX, which will (most likely) also have the 0.90
RAID code in it. There'll probably be an IDE patch for 2.2.14 shortly after it's
release.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid development status
On Sun, Nov 21, 1999 at 02:43:27PM -0500, Alex H. Vandenham wrote:
It would be VERY HELPFUL if someone involved in this project could update some
of the information on the linux raid tools and patches. It's not a big task
and it would make it much easier for users to figure out what to use for
serious production systems.
Use the 2.2.X-ac kernels. Alan Cox keeps the 0.90 RAID code in his kernels, and
for what I know they're stable enough for production systems. They are 2.2
kernels, and they are intended to be as stable as the main 2.2 branch, except
the -ac variants have a few of those extra features that won't go into 2.2.
If we should be using "the latest tools and patches" then let's drop this
Alpha/Beta stuff - I think it's keeping serious production systems from even
trying it.
Agreed, calling 0.90 alpha and the old-stuff beta is somewhat misleading.
It seems that the 0.90 RAID code will be in 2.4 when it comes out, so all this
mess with the alpha confusion and running -ac kernels etc. will soon be over.
(I'll probably keep on running -ac kernels anyway ;)
Also, not everyone wants to upgrade to the latest kernel and it would be
helpful to know which combination of patches and tools should be used with the
various kernel versions since the "Beta" tools and patches (ie 2.0.30).
This is stated in the HOWTO. Use the patch that matches your kernel best,
apply the patch and look out for rejects.
There should be no reason not to run 2.2.X-acY kernels if you're on 2.2
kernels. For 2.0.X you'll have to go find the patch that fits.
This is a very good project technically but it appears to need some better
project management - emphasis on "appears". It would help if information on
the different versions of the tools and patches, and the use of the Alpha/Beta
labels, was more clearly spelled out in the Website and HOWTO.
What website ?
You're right, it could be explained better. People should be moving away from
beta and trying out alpha instead (even though it sounds wrong, I know). The
alpha RAID is _far_ more stable and has some very nice features which is
missing in the beta stuff.
When 2.4 comes out, this confusion should hopefully be over.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: SCSI - RAID - data loss? Adding disks to RAID - data balancing?
On Tue, Nov 16, 1999 at 03:09:38PM -0500, Otis Gospodnetic wrote:
Hi,
I have 2 questions here...
1.
I'm getting some SCSI disks that I may decide/need to put them in a RAID
later on.
I am wondering whether I will be able to preserve all the data on the SCSI
disks when I convert them to RAID, or will conversion to RAID mean that I'll
have to lose data on those disks and put it back on the RAID after the
conversion?
I'm developing a raidreconf utility to allow this. Currently it can ``convert''
a single data disk and a number of empty disks into a RAID-0 while preserving
data.
HOWEVER(!) This has not been tested on large disks (!) I guess it works, and
it's tested on 60-90 MB disks (loopback devices).
When I get a little more spare time I'll add RAID-5 capability.
2.
If I get 2 disks and put them into RAID-0 (striping) what happens when I
decide to add another (3rd) disk to the setup?
Does the data automatically migrate from disks 1 and 2 onto 3 so that it is
evenly spread accross all 3 disks, or would I have to do that manually
somehow, or is this a bad thing to do and I should just buy all disks that I
think I will need right away?
Any advice?
The raidreconf utility can do this with RAID-0 arrays. I've tested it on
a 50+GB RAID, and succesfully expanded it to 100+GB. After expanding the
RAID, I used ext2resize to resize the filesystem. Everything went just
fine.
raidreconf is slow as molasses, but it works - at least for me. Until it has
seen some more testing, I'm reluctant to say that it really works. It does
perform quite a few paranoia checks before actually moving the data, so it
_should_ catch most internal errors, if there are any.
The current algorithm is very clean, eg. it moves data in a way that is simple
and therefore likely to be correct. Therefore it is also very slow. The
expansion of the large array mentioned above took almost 24 hours (!). I'll
optimize this when I get some spare time.
You can get the raidreconf utility as a patch to the raidtools package from
http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Monitoring?
On Fri, Nov 12, 1999 at 12:18:44PM +0100, Danilo Godec wrote:
Hi!
Ok, found an archive, but haven't found the questions/answers I was hoping
to find.
I have a RAID1 setup with kernel 2.2.13 and appropriate patches for 2.2.11
(only two files didn't patch correctly, as they were already patched in
2.2.13) and raidtools-0.90. Everything works nice, even hot-swapping disks
(with hot-pluggable SCSI backplane and some caution, of course) didn't
cause a problem.
However, are there any tools already available to monitor the md device
and notify the administrator via mail, modem, pager etc.?
It should be fairly simple to grep for underscores in /proc/mdstat using
cron+{perl,grep,whatever} and send a mail if one is found.
When a disk dies it is marked in /proc/mdstat like [UU_U].
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Tuning readahead
On Fri, Nov 12, 1999 at 10:15:40AM -0700, D. Lance Robinson wrote:
Attached is a program that will let you get or set the read ahead value
for any major device. You can easily change the value and then do a
performance test.
Fantastic ! Thanks a lot !
I just tried it out, but I haven't done any measuring yet...
Is this program available anywhere via. FTP or so ? If I want to
refer to it in the HOWTO, how should I go about doing that ?
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: adding/removing linear raid drives
On Thu, Nov 11, 1999 at 01:40:07PM +1000, Glenn McGrath wrote:
Well, thanks for the hints, it didnt work, this is what i did.
Backed up some of the array. (this became boring so i decided to run the
gauntlet)
A tip for beginners, when creating linear arrays make the biggest array the
first one, not the last one.
Tried to defragment the md array, defrag doesnt work on md arrays :-[ (why?)
There should be no reason why defrag can't use md arrays. Write the defrag
maintainer if it's really a problem.
Edited /etc/raidtab to remove any mention of the last drive
Ran mkraid, had to do the scary mkraid --really-force, so at this stage i
was loosing confidence.
Halted, removed the last drive, restarted
If you had a filesystem on your md device, the md device is now smaller,
but your filesystem still thinks it sits on a larger device.
This was shy I mentioned ext2resize, and why I mentioned that ext2resize
cannot shrink filesystems, only grow them. If it sounded like you didn't
need to shrink the filesystem before shrinking the device it resides on,
them I'm very sorry about that. But filesystems _must_ be resized when
the devices they reside on are resized, for the changes to work on all
layers (fs+block).
When shrinking: shrink filesystem (currently impossible AFAIK)
shrink device
When growing:grow device (using your method for linear arrays and
raidreconf for raid-0 arrays)
grow filesystem
By the way, I managed to grow a raid-0 from around 50G to around the
double, using raidreconf and ext2resize. raidreconf is slow as molasses
but it all went well, even though it took something like 24 hours.
This is where the shit started to hit the fan.
I probably should have changed the partition types back from fd to 83 as
when i rebooted it tried to autodetect the array and check it.
So it dropped me into maintanace mode
It dropped you into maintenance mode because your filesystem couldn't be
mounted, because the last N megabytes/gigabytes of your ``disk'' (md device)
was suddenly missing.
Tried doing e2fsck /dev/md1 and naturally got a heap of errors regarding
access beyond end of device
Sounds reasonable, considering the situation.
This went on forever, so i just stoped and tried to mount it, just locked up
the term.
I actually got a segmentation fault in here somewhere.
I'm sure the ext2fs tools maintainer would like to hear about that.
Tried shuting down but all device couldnt be unmounted (because the mount
command hung i guess)
Hard reboot.
Removing the md device from the fstab should give you a clean boot.
I should have tried using fsresize to shrink the array, maybe this would
have prevented the above problems. (do you think?)
Anyway ill remeber that for next time.
You can't shrink/grow md devices using a filesystem resizing tool. Just like
you filesystem is not magically resized when you use a md device resizing
tool (or do it manually).
Remember, there is no connection between an md device and a filesystem other
than that a md device is a block device which _can_ contain a filesystem (any
filesystem) and that filesystems usually reside on block devices.
I'm very sorry that this wasn't clearer before.
My thoughts on doing a defrag was that defrag would move all the data to the
start of the array, and thus the drive that i removed should contain no
data.
Did i have the right idea here?
Definitely. The problem was that the ext2 filesystem still thinks that it
has all the space available from your old array.
Anyway its all a learning process for me, so the data loss is no big deal.
I'm glad to hear that.
Maybe this info is usefull for someone
Once I get some more work done on raidreconf, maybe a section should be
added to the HOWTO about resizing arrays.
Thanks for the feedback,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Abort
On Thu, Nov 11, 1999 at 01:49:51AM +0100, Zsiga Robert wrote:
I have a problem.
I would like to create a "raid arrays".I have two SCSI disks.I would like
to use the RAID0 mode.When i mkraid /dev/md0 , mkraid aborted.
Why?
The /etc/raidtab file is the sample file for RAID0.The -f --really-force
don't help.Neither if i recreate the partitions.The second problem the
mkraid write that the partitions consist ext2.
What can i do???
Help me!
What kernel ? One with raid patches or not ? Which raidtools version ?
We need to see the raidtab to help you.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: adding/removing linear raid drives
On Thu, Nov 11, 1999 at 03:31:48AM +1000, Glenn McGrath wrote:
Is it possible to add or remove drives with linear-raid non-distructively ?
I thought i read something about this a while back, but cant track it down.
If you only add/remove drives in the ``end'' of the array, you _should_ be
able to add/remove drives only loosing/gaining what you remove/add.
After a change you can mkraid the array again, and if you have an ext2
filesystem on it, you can probably use ext2resize to resize that to fit
the new size of the array. Note however, that ext2resize only supports
*growing* filesystems. You're out of luck for shrinking.
NOTE!! The above is something I *assume* is correct. I've never tried it.
It is a hack, and it is likely to go wrong if everything isn't done exactly
right.
Practice this with a number of loopback-devices or spare disks before trying
the stunt on an array with real data on it. And keep backups of course ;)
Cheers,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: [new release] raidreconf utility
On Tue, Nov 02, 1999 at 01:56:06PM +0100, Egon Eckert wrote:
There's a new version of the raidreconf utility out. I call it 0.0.2.
Isn't this what supposed 'LVM' to be about? (BTW there seem to be 2
different implementations of LVM on the web -- one included in 0.90 raid
patch and one on http://linux.msede.com/lvm/)
Well, yes and no. LVM gives you pretty much the same features, the ability
to add disks to a device to grow it.
The only reason I started the raidreconf utility was, because I needed to be
able to add/remove disks from RAID arrays *today*. LVM is, from what I can
understand, still not implemented to a state where you can use it and rely
on it. I know I can rely on the RAID code in the kernel, so all I was missing
was a utility to add/remove disks from RAID sets. Now I have one, at least
for RAID-0 :)
While I'm at it, I hope to build in some conversion features too, so that you
can convert between RAID levels. The utility can already convert a single
block device into a RAID-0, but being able to convert a five disk RAID-0 into
eg. a seven disk RAID-5 would be pretty sweet I guess. Remember, this is all
functionality that, once raidreconf works, is perfectly stable and well tested,
because all the ``real'' support for the RAID levels has been in the kernels or
at least the patches for a long time now.
Can someone clarify this?
A few months ago I asked what's the 'translucent' feature as well, but no
reply.. :(
I would actually like to know about the state of LVM, HSM, and all the other
nice storage features being worked on in Linux. I wouldn't want to spend time
on this utility if it was entirely redundant. But then again, I don't think it
is, at this time. Hopefully, in a year or so, nobody will care about
raidreconf, because we have LVM working and providing even more features. Or
maybe some raidreconf code could be used for the LVM for providing the
conversion features.
Time will show:)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: [new release] raidreconf utility
On Tue, Nov 02, 1999 at 02:16:57PM -0600, Mark Ferrell wrote:
You also have to remember that in most LVM implementations adding a device to the
LVM does not add it to the raid.
[snip]
"Oh look .. the 90G raid5 array is getting pretty full .. I guess we should add
more drives to it .. oh .. hold it .. it's a raid5 .. we can't just add more space
to it .. we have to LVM attach another raid5 array to the array in order to keep
redundancy"
My only experience with LVM is from HPUX. I could create the equivalent of RAID-0
there using LVM only, and it is my understanding that LVM for Linux can do the same.
It should indeed be possible to create the equivalent of RAID-5 as well, using only
LVM. But still the LVM would have to support extending the parity-VG.
raidreconf will hopefully be useful for people to do these tricks, until the LVM
gets the needed features (which may be years ahead).
The ability to add/remove/resize the lower level raid enviroment would be in my
opinion alot more beneficial in the long run if it is possible.
IMHO the support for redundancy should be in the LVM layer. This would eliminate
the need for RAID support as we know it today, because LVM could provide the same
functionality, only even more flexible. But it will take time.
Today, and the day after, we're still going to use the RAID as we know it now. LVM
is inherently cooler, but that doesn't do everyone much good right now as it doesn't
provide the equivalent of a resizable RAID-5. It's my belief that people need that.
Cheers,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
[new release] raidreconf utility
Hi all !
There's a new version of the raidreconf utility out. I call it 0.0.2.
You can download a patch against the current raidtools at
http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
New features:
*) Bugfix in RAID-0 growth. It now seems to work in all cases with
strange disk orderings, different disk sizes etc.
*) Added shrinking of RAID-0 arrays. This also seems to work in all
cases I have tested.
*) Added ``importing'' of devices. You can convert a single block
device in to a RAID (hopefully) without loosing your data on the
block device.
If anyone out there has a way to test this utility on large arrays I would very
much like to hear any results from that. I test this utility extensively on a
setup with a number of loop-back devices that point to files of varying size.
But I cannot test this utility on multi-GB arrays currently. This is a very
important test nonetheless, since a common bug is the 2/4 GB wraparound of
integers. I've been careful with this, but without testing
PLEASE! Don't use this on data you can't restore ! I'm very careful when I'm
coding this, but I'm still human. There _are_ bugs left. I just haven't found
them yet. If you find any, please let me know.
Features planned: More RAID levels supported, and a checkpoint file to allow
graceful resuming of operations after eg. a power surge.
Best regards,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Booting RAID5
On Sun, Oct 31, 1999 at 03:03:23PM +0100, Martin Bene wrote:
...
Update to this howto:
-
4.11 Booting on RAID
...
Thanks Martin !
I'm putting this in the HOWTO now. I hope to have a new version out in some
hours, along with an update to the raidreconf utility. I'll post it here when
it happens.
Cheers,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: help about sofeware-RAID!
On Mon, Nov 01, 1999 at 01:39:14PM +0800, Next Liu wrote:
Dear Sir:
This Email come from Taiwan. We have used the Mandrake 6.1 OS to
install
software-RAID. As before, we used three 8.4G HD as RAID-0 was OK. But
now
we supportted larger HD - 13.0G x 3 as RAID-0. While we use "mkraid" to
generate
RAID diskes. Do the software-RAID have HD size limitting ?
Mandrake 6.1 has the 0.90 raidtools and the 0.4X RAID in kernel. RAID
doesn't work in Mandrake because of that.
Get the latest 2.2.13-ac kernel (ftp.fi.kernel.org/pub/linux/kernel/alan/...)
The AC kernels (the ones released by Alan Cox) has some extra features over
the standard kernels, like 0.90 RAID.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Root RAID and unmounting /boot
On Sun, Oct 31, 1999 at 11:50:26PM -0200, Christian Robottom Reis wrote:
On Wed, 27 Oct 1999, Jakob Østergaard wrote:
Because LILO doesn't understand RAID, and thus cannot (yet) load the kernel
of it.
Doesn't the lilo.raid1 patch included in RH6.1 permit booting off a raid1
array?
You're right.
I didn't check that because I expected it not to. Stupid me. Of course people
fix stuff that doesn't work :)
See the latest version of the HOWTO. Martin Benes added a note about the
LILO patch that comes with RH6.1
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid performance? good?
...
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid performance? good?
On Fri, Oct 29, 1999 at 02:36:10PM +0300, Mika Kuoppala wrote:
...
bonnie bonnie
Two threads :)
What i don't understand is that how it can then drop
to half what it was on normal partition ? Shouldn't
it be just a little less.
Oh, sorry, I missed that...
Yes that's pretty weird. I'd say it's a SCSI problem.
What does running a bonnie on both SCSI disks from the RAID
give you ?
I'm pretty sure you'll see the same results. The combined
thrughput from bonnie on the two disks, will be the same as
you get from the RAID.
Could you try that out ?
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Root RAID and unmounting /boot
On Tue, Oct 26, 1999 at 09:07:34AM -0600, Marcos Lopez wrote:
Egon Eckert wrote:
syslogd 378 root5w REG9,18548 192396
/var/log/boot.log
klogd 389 root2r REG8,1 191102 12
/boot/System.map-2.2.12-20
Is it safe to kill these?
These are loggers, so I guess nothing terrible would happen. But I
wouldn't kill them anyway.. I would fix the problem, not make it worse.
Also i would be quite grateful if someone could explain to me why I must
unmount /boot inorder for the lilo -r /mnt/newroot to work?
I don't unmount anything before running lilo.
Okay tired performing that function without doing the umount. I tried
doing it without coping the files in /boot over to /mnt/newroot/boot but
it couldn't find /boot/boot.b. So i copied over all the files in /boot
to /mnt/newroot/boot. Then after running "lilo -r /mnt/newroot" I get
the following error:
"Sorry, don't know how to handle device 0x0900"
What does the above mean and how to i fix it?
It's because /mnt/newroot/boot is not mounted on your boot partition, but
is a regular subdirectory on your /mnt/newroot RAID.
umount /boot, mount /mnt/newroot/boot. Then run LILO.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid0 crash
On Sun, Oct 24, 1999 at 03:11:53PM +0200, Kelina wrote:
Loose my head next time... really...
Deal :)Ok, you had me wondering there...
offcourse i meant with raid0
No, if you have a bad block that the disk can't read, no software in the
world is going to make the data come back.
(if it's sound data you could extrapolate in the Fourier domain of course,
or if it's sales material add some ``enterprise'' ``internet'' etc. to
fill in the blanks ;)
Hard drives crash, that's why you take frequent backups and run raid1/5
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
raidreconf progress
Hi all !
After a night of hacking (and quite some surprises) I have a new
version of raidreconf out.
It's at the usual place (http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/)
and this time it's a patch against the current raidtools package.
Added since last:
Growing of raid-0 now seems to work, even if the disks are of varying size.
Lots of code re-organization
Before next release:
Shrinking of raid-0, and eventually grow/shrink of raid-5
This utility shouldn't go into the raidtools package just yet. But I'll keep
returning to the list (until someone tells me to bugger off ;) when I have new
releases out that add functionality.
Cheers,
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid howto
On Thu, Oct 21, 1999 at 04:09:14PM -0400, Admin Mailing Lists wrote:
Is there any chance of getting the software raid and/or root raid howto
updated for whatever the current features of the MD device driver is?
I'm thinking of using raid1 on a bootable drive (/, /usr, /var, /home
partitions) and the documents mention some pitfalls, which may have been
fixed in the MD driver but not documented in the HOWTO
Perhaps we could add a
``read the howto at http://ostenfeld.dk/~jakob/Software-RAID.HOWTO''
to the bottom of all mails on this list ? AFAIR the linux-smp list
does that (with the SMP FAQ).
Could the list maintainer give an oppinion on this ?
Thanks,
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raidreconf utility
On Tue, Oct 19, 1999 at 09:47:13PM -0700, Tom Livingston wrote:
[snip]
A fair thing to note is that this is a "riskier" endeavor than anything else
in the raidtools package. That being so, it makes sense to have a good
amount of checks along the way. I see you do check the raidtab against the
superblocks, which is most of it. I can't remember, though, if you do ext2
checking mounted file system checking like mkraid does
A little checking. But I'll start by putting in algorithms that don't destroy
your data if you use differently sized disks :)
Also, some thought needs to go into how this could handle a power fail in
the middle. Certainly you don't want the old raid set to auto start when
Yes, checkpointing would be good. It should be fairly simple, if one could
accept to still loose one (or N = # of disks) chunks.
the machine is rebooted, doing so could cause all sorts of problems.
Instead of requiring users to disable the raid by removing the fd partition
labels, maybe the reconf utility should erase the superblocks on the md
device it's working on, placing instead a marker that shows it's in the
middle of being reworked. If status information about the reconstruction
Good point:)
was kept in the superblocks (or just one) the reconf utility could use this
data to pick up where it left off...
Also, when allowing a user to reduce the raidset size ( can't remember if
you already allow this... I read the code sunday and already I've forgotten
everything ;), you probably want to do a sanity check to see if the ext2
partition on that device has already been sized down.
I'm trying to use the existing code that mkraid uses (from raid_io.c) to do
the superblock updating, so some of the clever checks are only maintained
in one place. But the raidreconf utility will need some checks added to
it, in time.
I'll do basic features first, checks later.
Might also benefit in considering what happens if there's a hardware error
on one of the old or new disks during the process... perhaps an area of bad
sectors on one of the new disks? I think all of the information is still
there at this point to do an about face, and start un-reconf'ing the
drive... walking backwards to put it back in it's original state.
This quickly gets hairy. I think, once it handles a number of basic features
(like shrink+grow of raid[01]) it'll be easier to see what can be done.
One could do a write test on the new disks and a read test on the old ones
before actually moving data. I guess that would be a pretty good start (?)
I believe in put-up or shut-up, so I'm happy to lend my time to the process.
I'm in between consulting gigs right now and could probably add something.
I'll write back to the list as soon as I've re-done the basic algorithm. The
code available for download now is _really_ basic, and wrong. I've already
changed quite a lot of it. Wait a day or so for an update :)
Cheers,
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
raidreconf utility
Hi people !
I started hacking together a utility to allow resizing and eventually
reconfiguration of RAID sets.
The utility is called ``raidreconf'', and I intend to make it read two raidtab
files (eg. raidtab and raidtab.new), and then (if possible) convert the given
MD device from the layout in the old raidtab file to the layout in the new one.
I just got it working, at least a little, so now I can resize a RAID0 array
successfully.
Now, the code is *not* production quality, in fact, it's not even alpha
quality, or any quality for that matter. I know there is a large number of
bugs in the code, and I'll throw in another day or so to get the code prettier,
less unstable, and more functional.
I tested it on a three-disk RAID0, and successfully expanded it to a four-disk
RAID0. But that's it. The code can currently _only_ expand a RAID0 set.
And mind you, that's not even stable in all cases, just the case where you have
equally sized disks in a simple ordering.
The reason I'm writing about it now is, that I'd like to hear comments on the
idea. Is it reasonable to use two raidtab files and a raid-device on the
command-line, then try the conversion ? And what features would people like to
see ?
I guess resizing is the most urgently needed feature. But conversion from
raid0 to raid5 etc. might be something worth hacking on too ?
Anyway, if you have too much free time on your hands, you can take a look at
the code at http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
Cheers,
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Bugreport - missing check on hotadd
I just learned (the hard way!) that you can raidhotadd /dev/md0 /dev/whatever
By accident I added /dev/hdc instead of /dev/hdc3 to a degraded RAID-1. And
it worked ! Well, it worked until the swap-partition on /dev/hdc2 got written
to which caused the ext2fs on /dev/md0 (which was then partly /dev/hda3 and partly
/dev/hdc - including /dev/hdc2) to get corrupted.
Shouldn't the raidhotadd command check that the supplied disk name to be added
is actually a valid device in the raidtab file ?
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Bugreport - missing check on hotadd
On Sat, Oct 16, 1999 at 10:24:31PM -0700, Tom Livingston wrote:
Jakob Østergaard wrote:
Shouldn't the raidhotadd command check that the supplied disk
name to be added is actually a valid device in the raidtab file ?
I'm not so sure...
I never saw raidhotadd as being an application that required the drive to
already be known. In fact, I always presumed it might be used in a case
where you hotswap a new drive into an empty swap cabinet, hotadd it to the
array, and then pull the old failed drive.
Thats a good point.
Obviously you could edit the raidtab before hand to add this drive to the
raid set.. but as it wouldn't be (ye), you'd be enforcing some pretty
strange behavior.
Nah, that would be weird and not The Way We Want To Do Things (TM).
What about a -f flag ?
I wonder if a more straightforward test would be to refuse to use /dev/sdX
if any of the partition on sdX are mounted... this would be akin to refusing
to use /dev/sda1 if sda1 is already mounted.
Yes. But my problem was that nothing was being used on /dev/hdc when I added
it. Later on I enabled swap on the /dev/hdc2 partition, and swapon didn't have
any trouble doing that, despite the fact that /dev/hdc2 was non-existing
because the partition table just got nuked. I know that the partition table
still lived in the kernel of course, and we don't want raidhotadd to call the
ioctl to re-read partition tables after adding drives ;)
I think that checking consistency is a pretty hard problem. You need all the
RAID, FS, swap, ... utilities to check for RAID, FS, swap etc. This is n^2.
But checking up against the existing configuration when adding drives will
catch these stupid mistakes. A -f flag to allow adding anything would - for
the reasons you mention - of course be a good idea.
Ok, I'm a little excited about this right now. It's not every day I nuke
people's e-mail (including my own) because of a typing error. If I still feel
bad about this tomorrow, I may just submit a patch to raidstart.c :)
---
As a side note: Is anyone working on a resize utility for the RAID sets ? We
have the resize2fs utility for the filesystems, but it seems that such a
utility for RAID is still missing... Yes I know about LVM, and yes I still
want to resize the RAID sets :) If noone is working on it, I just might
want to look into that, no promises though.
Cheers,
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid problem
On Fri, Oct 15, 1999 at 10:04:06AM +0200, Luca Berra wrote:
[snip]
P.S.
it seems to me (from this kind of messages) that not having
the latest raid patches in th 2.3 kernel, is causing more
problems that having these, could this be a suggestion to
Linus
AFAIK Ingo is hard working at getting RAID ready for 2.3
It needs some porting to the new unified buffer-cache architecture
and there is the 12+ disks issue too (which causes superblock restructuring).
It would, however, be really nice to have an ETA on it, so we can
plan to back up important stuff and get ready for some 2.3+RAID testing
in time:)(Ingo, are you reading this? ;)
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: FW: Dream RAID System (fwd)
On Tue, Oct 12, 1999 at 08:50:26PM -0700, Marc Merlin wrote:
On mar, oct 12, 1999 at 11:44:23 -0400, [EMAIL PROTECTED] wrote:
Though, how does the PC handle things booting up if the drive on
controller 0, ID 0 has gone bad? I expect this is another case where
I don't think it will boot, unless you have a boot floppy as a backup that
will boot on the second hard drive if the first one fails, and the boot
process falls back to floppy.
With IDE drives, you can (at least on a few newer BIOSes where I've tried it)
set your drives to ``autodetect'' so that the BIOS won't complain if one drive
is missing.
Then, with identical /boot partitions on both drives, and the system booting
on RAID-1, you system will boot no matter which drive you pull out of it.
No need to reconfigure the BIOS or anything else.
Of course, if a drive is ``sick'' in a way so that the BIOS will find it nicely
and attempt to boot on it, but the boot/kernel data area has bad blocks, then
you'll have to physically pull out the drive before you can boot the system again.
But I dont' think this is much of an issue, at least with IDE, since the system
will usually stay perfectly stable with a bad disk and RAID in degraded mode. The
system will not have to boot, before you take it down to pull the bad disk out
anyway.
This is at least my experience. I've had a few bad IDE drives lately, on systems
booting on RAID-1, and I have been able to wait for some convenient time to take
the system down, pull out the bad drive, boot up again, end of story.
Again, it can be made to work, but it'd be a hack.
It's been some time since I had SCSI drive failures. Mostly because all new systems
I work with are IDE ones :)
So I can't really comment much on that. Last time I had an SCSI drive failing,
the system went down with it, because of the SCSI driver/layer.
There's nothing (that I know of) stopping anyone from buying Intel
Astor/AstorII/Cabrillo-C server chassis and making use of their hot-swap
bays without hardware RAID. The Astor chassis are surprising cheap too.
True, but a real disk shelf with dual power supply, diagnostic LEDs, and
some SCSI logic to handle drives that go bad and possibly send crap over the
SCSI bus, is still better :-)
Definitely. If you're not on a budget :)
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: Raid0
On Fri, Oct 08, 1999 at 08:28:39AM -0700, Pat Heath wrote:
I was working on doing the autostart for raid0 and the part where it says:
3. The partition-types of the devices used in the RAID must be set to
0xFD (use fdisk and set the type to ``fd'')
is confusing because I don't have a choice of fd for partition type. If I
put it in it lets me do it but labels it unknown. Is this correct or am I
doing something wrong?
It's correct. fdisk doesn't know about type 0xFD yet.
The HOWTO should probably state this. I'll fix it :)
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: redhat 6.1 RAID: what's different
On Tue, Oct 05, 1999 at 10:30:23PM +0200, Daniel Roesen wrote:
Creating raid partitions is not available if you are using the text mode
installer.
You're kidding, aren't you? Seems like RedHat is really trying to go the SuSE
way and become Windows...
If you ever looked at the source for the text-mode installer, I guess you'd
known why they haven't extended it further. To call it an ugly hack would be
much too nice:)
Besides, they still don't require you to have a working DOS before you install,
I think that's something ;)
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: redhat 6.1 RAID: what's different
On Tue, Oct 05, 1999 at 04:15:14PM -0700, Lawrence Dickson wrote:
I am solidly with Daniel on this. Why does no one ever use the fact that
a graphical interface can be put on top of a text mode interface (we have
multitasking don't we?) and thus kept equivalent instead of divergent?
It is self-documenting too at the developer level.
GUI means "Grossly Unpredictable Interface."
RH had to redo their installer. It was _bad_. I mean, the functionality
was good, but the code made it virtually impossible to extend in any sane
way.
Of course, it would have been nice, if they wrote a common ``core'', and
then slapped a GUI or curses front-end on it by user's choice. But I'm
sure they had reasons for doing whatever they did.
Oh, I'm sensing a slight vibration from the way-off-topic alert system
here:)
On other topics, does 6.1 make any steps forward in hot-swapping
robustness?
That would mean that they (which in turn probably means Ingo) did a kernel
patch that has not been released to us (the raid crash test dummies) for
wide testing. To me that sounds as inappropriate as it sounds unlikely.
The hot-swapping robustness has two points of failure as I see it:
1) With IDE disks, the hardware isn't usually well suited for it, although
it is absolutely possible. The Linux IDE subsystem is _rock_ solid.
2) With SCSI disks, the Linux SCSI layer is too fragile to properly handle
the errors that occur on the bus when you pull a device away (or a device
fails). This is unfortunate, because hot-swapping with SCSI would be
obvious and people expect it to work. But it seems as though a re-write
of the SCSI layer will have to wait for 2.5.X.
If anyone else has more insight into this, I'd be delighted to hear about
it.
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: networked RAID-1
On Mon, Oct 04, 1999 at 04:55:04PM -0600, Brian Grossman wrote:
Has anyone tried running sw-raid1 over linux's network block device? I've
been tempted, but not quite tempted enough yet.
I think I saw that on the lkml. There were some problems (mainly performance
under heavy load, IIRC). But it should be doable. Especially if anyone needs
the feature;)
Does sw-raid1 require synchronous data xfer for the block devices involved?
If so, can sw-raid1 be told to not require synchronous data xfer? Does it
make any sense to do so?
When a block device says it's done, the RAID layer can assume nothing else.
Whether the NBD code says it's done when the data reached their destination,
or when they reached some cache (or the wire), I don't know.
Could sw-raid1 do reads only from one device, but do writes to both (for
performance on nwb)?
That would require tweaking in the RAID code.
But if you plug in a FE card in each machine dedicated to the NBD (or one
card for each NBD) you have performance similar to that of normal disks.
Around 12 MB/s read/write (simultaneously - that's even better than most
disks - but I'm not sure that matters a lot).
Something else I've been thinking about, but haven't had time to
investigate properly, is intercepting filesystem calls and shipping them
off to another machine, where they are duplicated. Anybody here have an
idea how difficult that would be? Could it be done in a fs-independent way?
Ouch. That could get really really nasty. RPC in the kernel is nasty already.
Doing RAID over NBDs is pretty close to you approach, as I see it, and it's
fairly clean.
There are still implications though... You must assure that only one machine
at a time will have the filesystem mounted, or you'll see some strange stuff
happening to your data :)
Besides, if the machine that had the filesystem mounted crashes, the filesystem
will need a (argh, don't say it!) fsck! I guess this is the real showstopper.
Something like PVFS (http://ece.clemson.edu/parl/pvfs/index.html) seems like
the right thing to use. Unfortunately however, it seems as though they do
not implement redundancy :(
It should be doable to write a user-space daemon that could monitor other hosts,
and when one decides to stop responding, the NBD imported from that host will
be marked as ``failed'' in the RAID, and our new host will fsck and mount the
filesystem.
It would probably be wise to look into ReiserFS or ext3fs, or any other filesystem
with journalling support. The fsck is a bad one, unless I've overlooked something.
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: raid 0/1 question
On Mon, Oct 04, 1999 at 07:39:21PM -0400, [EMAIL PROTECTED] wrote:
I just need some help to make sure I'm doing this properly. All I ask is
for quick help on getting this proper.
I have 6 9 gig disks. I want to create a 0/1 level configuration. This
is what I have in my raidtab:
...
From where I sit it looks just fine.
You might want to use the same chunk size on all RAIDs though, I'm not
sure what impact it might have on performance though (anyone?)
# Sample raid-1 configuration
raiddev /dev/md2
raid-level 1
Oups! You forgot persistent-superblock here !
nr-raid-disks 2
nr-spare-disks 0
chunk-size 4
device /dev/md0
raid-disk 0
device /dev/md1
raid-disk 1
Go ahead, tell us if it works, let's see a benchmark (otherwise we won't
believe you ;)
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: PATCH: / on RAID1
On Thu, Sep 09, 1999 at 11:51:23AM +0200, Jakob Østergaard wrote:
On Thu, Sep 09, 1999 at 11:40:49AM +0200, [EMAIL PROTECTED] wrote:
On Wed, 8 Sep 1999, Paul Jimenez wrote:
This patch is based on the md.c that shipped with the 2.2.11 kernel; it
calls md_stop() on all RAID partitions still around at shutdown/reboot
time, which allows one to have a small (non-RAID) /boot partition with
a kernel on it and a larger (RAID1) partition that's /.
auto-stop has been in the newest driver for a long time. The RAID1 code in
stock 2.2.11 is considered old and buggy (eg. in the case of disk failure)
- it's recommended to upgrade to the newest RAID driver and do an mkraid
--upgrade.
Ingo, could you elaborate on this ?
Oh, sorry. I was tired when I wrote that mail. I thought it said ``the
RAID1 code for 2.2.11'' not ``the RAID1 code _in_stock_ 2.2.11''...
Never mind, forget these mails :)
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: PATCH: / on RAID1
On Thu, Sep 09, 1999 at 12:15:09PM +0001, Thomas Seidel wrote:
On Thu, Sep 09, 1999, [EMAIL PROTECTED] wrote:
...
I'm sort of wondering, because I've had a lot of luck with older versions,
and would hate to upgrade all the boxes if it's not necessary :)
I agree with you. I posted a similar patch few month ago to this list
(ftp://ftp.ddb.de/pub/linux/root_raid1_support/). This patch is installed on
two production servers running without any problems (kernel 2.2.9, old mdtools
0.42, ...). The only thing I (not really) miss is an automatic reconstruction
running in background in case of a disk failure.
Just to clear up the mess I left... :)
I certainly did _not_ have a lot of luck with the old versions (eg. 0.42 or
stock linux kernel versions) of RAID-[15]. Any RAID level with redundancy
I tried blew up horribly once the array was stressed.
What I meant to say was, I've had a lot of luck with older versions of Ingo's
patches, the ones for 2.2.3, 2.0.36, etc. etc.
I would recommend that anyone who runs stock-kernel-RAID with redundancy (1,4,5)
upgrade to Ingo's patches. The pain of backing up the data, upgrading and
restoring is nothing compared to the pains one will experience if a disk dies,
if the array is stressed, or if someone farts near any of the disks:)
Old-style (stock-linux) RAID is just broken. We'll have to live with the patching
circus until 2.4.
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: superblock Q/clarification
On Thu, Nov 04, 1999 at 08:09:31AM -0500, James Manning wrote:
My impression was that the s/w raid code only wrote to the ends (last 4k)
of each device, so I'm trying to clarify the following paragraph from
http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/Software-RAID.HOWTO-4.html#ss4.7
The persistent superblocks solve these problems. When an
array is initialized with the persistent-superblock option in
the /etc/raidtab file, a special superblock is written in the
*beginning* of all disks participating in the array. This allows the
It's a bug !
The superblocks are written in the end of all disks. I'll fix this in
the HOWTO ASAP.
kernel to read the configuration of RAID devices directly from
the disks involved, instead of reading from some configuration
file that may not be available at all times.
Is the paragraph wrong or am I misunderstanding persistent superblocks?
I can't believe I actually wrote *beginning* in the HOWTO... I should
know where the superblocks are... :)
Thanks,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
Re: superblock Q/clarification
On Thu, Nov 04, 1999 at 10:01:41AM -0500, David Cooley wrote:
...
Does this mean we no longer have to start raid partitions at block 1
instead of block zero?
I'm sorry, but I have no idea of what you're referring to...
When accessing the RAID device you can't see that there is a superblock
at all. You can't access the superblock via valid accesses to the MD
device.
I might be misunderstanding your question... When did you ever have to
start anything at block 1 instead of block 0 ?
(Gee, I hope this isn't in the HOWTO as well ;)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
