On Tue, 15 Aug 2006, andy liebman wrote:
-- If I were to create disk images of EACH drive (i.e., /dev/sda and
/dev/sdb), could I restore each of those images to NEW drives -- with
all of their respective partitions -- and have a working RAIDED OS? I
ask because my ultimate goal is to put a
Peter T. Breuer wrote:
1) I would like raid request retries to be done with exponential
delays, so that we get a chance to overcome network brownouts.
I presume the former will either not be objectionable
You want to hurt performance for every single MD user out there, just
because things
On Tue, 15 Aug 2006, andy liebman wrote:
-- If I were to create disk images of EACH drive (i.e., /dev/sda and
/dev/sdb), could I restore each of those images to NEW drives -- with
all of their respective partitions -- and have a working RAIDED OS? I
ask because my ultimate goal is to put a
I'm not sure I understand what you're saying about mounting /dev, /proc
and /sys.
just run:
mount --bind /dev /newroot/dev
mount -t proc /proc /newroot/proc
mount -t sysfs /sys /newroot/sys
before chrooting
L.
btw, be sure to add auto=yes to the ARRAY lines in /etc/mdadm.conf
or you might
Does that make sense? Has the format changed for initrd's. I also noticed
that the new initrds have a script called init instead of linuxrc.
see Documentation/filesystems/ramfs-rootfs-initramfs.txt
in the kernel sources.
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
Peter T. Breuer wrote:
You want to hurt performance for every single MD user out there, just
There's no performance drop! Exponentially staged retries on failure
are standard in all network protocols ... it is the appropriate
reaction in general, since stuffing the pipe full of immediate
Warning: I'm not certain this info is correct (I test on fake loopback
arrays before taking my own advice - be warned). More authoritative
folks are more than welcome to correct me or disagree.
create is safe on existing arrays in general, so long as you get the old
device order correct in the
Also sprach Molle Bestefich:
Peter T. Breuer wrote:
I would like raid request retries to be done with exponential
delays, so that we get a chance to overcome network brownouts.
Hmm, I don't think MD even does retries of requests.
I had a robust read patch in FR1, and I thought Neil
On Wed, 16 Aug 2006, Peter Greis wrote:
So, how do I change / and /boot to make the super
blocks persistent ? Is it safe to run mdadm --create
/dev/md0 --raid-devices=2 --level=1 /dev/sda1
/dev/sdb1 without loosing any data ?
boot a rescue disk
shrink the filesystems by a few MB to
For those who have been following my attempt to create IMAGES of a pair
of drives with mirrored OS partitions, and then restore the IMAGES to a
new set of drives...
This doesn't work directly. The imaging programs are FAST because they
do not perform block level copying. They replicated
The first method that comes to mind is to make a raw copy of each mirrored disk
to another disk attached to the same server. dd if=/dev/sda of=/dev/sdb will do
a raw dump from one drive to another. Assuming you copy to a drive of equal or
greater capacity, your partition structure, RAID
Sorry, I EOF'd too soon..
As to creating mirrored partitions over top of existing data, mdadm will write
a superblock at the beginning of each mirrored component, which will blow up
the first several bytes of the partition (probably the FS descriptor). I
believe there is an option to create a
Also sprach Molle Bestefich:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
Peter T. Breuer wrote:
You want to hurt performance for every single MD user out there, just
There's no performance drop! Exponentially staged retries on failure
are standard in all network protocols
On Wed, Aug 16, 2006 at 01:05:39PM -0400, andy liebman wrote:
if the imaging software is not too smart and creates the partitions and
filesystems with the exact same size as the original, yes.
(i mean that there should be some space between the end of the
filesystem and the end of the partition
Peter T. Breuer wrote:
We can't do a HOT_REMOVE while requests are outstanding,
as far as I know.
Actually, I'm not quite sure which kind of requests you are
talking about.
Only one kind. Kernel requests :). They come in read and write
flavours (let's forget about the third race for the
Also sprach Molle Bestefich:
See above. The problem is generic to fixed bandwidth transmission
channels, which, in the abstract, is everything. As soon as one
does retransmits one has a kind of obligation to keep retransmissions
down to a fixed maximum percentage of the potential
On Wed, Aug 16, 2006 at 01:05:39PM -0400, andy liebman wrote:
if the imaging software is not too smart and creates the partitions and
filesystems with the exact same size as the original, yes.
(i mean that there should be some space between the end of the
filesystem and the end of the partition
On 16 Aug 2006, Molle Bestefich murmured woefully:
Peter T. Breuer wrote:
The comm channel and hey, I'm OK message you propose doesn't seem
that different from just hot-adding the disks from a shell script
using 'mdadm'.
[snip speculations on possible blocking calls]
You could always
Hello,
I have been trying to get a raid5 array going on SuSE 10.1 Final
(2.6.16.21-0.13-default) but every time I create, resync, or rebuild a
spare it seems to have worked, but
# mdadm --examine /dev/sd[bcd]1
gives a report that the checksum is off:
/dev/sdb1:
Magic :
On Wednesday August 16, [EMAIL PROTECTED] wrote:
Hello,
I have been trying to get a raid5 array going on SuSE 10.1 Final
(2.6.16.21-0.13-default) but every time I create, resync, or rebuild a
spare it seems to have worked, but
# mdadm --examine /dev/sd[bcd]1
gives a report that the
On Wednesday August 16, [EMAIL PROTECTED] wrote:
So,
1) I would like raid request retries to be done with exponential
delays, so that we get a chance to overcome network brownouts.
2) I would like some channel of communication to be available
with raid that devices can use to say
hello all:
i installed adadm 2.5.2,and compiled the 2.6.17.6 kernel .when
i cmd to grom a raid5 array ,it don't work.how to do can make raid5
grow.thks for your help.
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More
22 matches
Mail list logo
