Keld Jørn Simonsen wrote:
Make each of the disks bootable by grub
(to be described)
It would probably be good to show how to use grub shell's install
command. It's the most flexible way and give the most (or rather total)
control. I could write some examples.
-
To unsubscribe from this
Originally I've thought, that delayed uevents regarding raid partitions were
not related to md. To recap: if we assemble some md array as partitionable
array, add/change uevents regarding its partitions will not happen right
after assembly, only after next array related operation (mdadm -D,
Janek Kozicki wrote:
And because LVM is putting its own metadata on /dev/md1, the ext3
partition is shifted by some (unknown for me) amount of bytes from
the beginning of /dev/md1.
It seems to be multiply of 64KiB. You can specify it during pvcreate, with
--metadatasize option. It will be
Doug Ledford wrote:
course, this comes at the expense of peak throughput on the device.
Let's say you were building a mondo movie server, where you were
streaming out digital movie files. In that case, you very well may care
more about throughput than seek performance since I suspect you
BERTRAND Joël wrote:
Well, /dev/mdp0 is created. But what's about /dev/mdp0p1 ? I believe
that mdadm has to create required devices. I don't understand where is
my mistake. Any idea ?
Two things come to my mind:
- udev messing up with what mdadm is doing (but this isn't the moment
Wolfgang Denk wrote:
Dear Bill,
in message [EMAIL PROTECTED] you wrote:
Be aware that rsync is useful for making a *copy* of your files, which
isn't always the best backup. If the goal is to preserve data and be
able to recover in time of disaster, it's probably not optimal, while if
you
Goswin von Brederlow wrote:
Thanks, should have looked at --link-dest before replying. I wonder
how long rsync had that option. I wrote my own rsync script years
ago. Maybe it predates this.
According to news file, since ~ 2002-9, so quite a bit of time.
-
To unsubscribe from this list: send
Goswin von Brederlow wrote:
I was thinking Michal Soltys ment it this way. You can probably
replace the cp invocation with an rsync one but that hardly changes
things.
I don't think you can do this in a single rsync call. Please correct
me if I'm wrong.
something along this way:
rsync
Dean S. Messing wrote:
I don't see how one would do incrementals. My backup system uses
currently does a monthly full backup, a weekly level 3 (which
saves everything that has changed since the last level 3 a week ago) and
daily level 5's (which save everything that changed today).
Nix wrote:
On 19 Sep 2007, maximilian attems said:
i presume it may also be /sys/block/mdNN ?
That's it, e.g. /sys/block/md0. Notable subdirectories include holders/
(block devices within the array, more than one if e.g. LVM is in use),
Also, if you mount the raid as a partitionable one,
Dean S. Messing wrote:
Also (as I asked) what is the downside? From what I have read, random
access reads will take a hit. Is this correct?
Thanks very much for your help!
Dean
Besides bonnie++ you should probably check iozone. It will allow you to test
very specific settings quite
Just a tiny detail, but it looks like -auto=mdp won't create additional
device nodes for raid's partitions (unless explicitely specified by number),
when used with non-standard name, i.e.
mdadm -C /dev/md/abc -l0 -n2 /dev/sda2 /dev/sdb2 --auto=mdp
will only create /dev/md/abc node. Remaining
During doing some tests, I've found a slight delay of partition related
uevents, when raid devices are assembled/stopped.
For example - consider md/d0 with 1 partition created. The array is unassembled.
1) mdadm -A /dev/md/d0
will generate change even properly for md/d0, but add' uevent for
I've noticed, that whenever I use 1.1 or 1.2 superblock format, mdadm
will always report version 1, when i.e. mdadm -E --scan is issued.
Also, in these two cases, mdadm -A --scan won't work, unless proper
ARRAY line is present in mdadm.conf (and if metadata is part of the
description, it must
Cry Regarder wrote:
Thanks! A couple questions:
1. Are you sharing that spare with an other array? If not, why not do a raid-6
instead of a raid-5?
No, the spare is not shared. Now that I think about it and you reminded
about raid-6...
I can think of one small plus of my setup - that
Cry Regarder wrote:
Partitions on RAID:
Back to when I constructed the array, I placed an ext3 partition directly on
/dev/md0. Since construction, I have expanded the array by two disks, but have
not at this time resized the ext3 partition.
What I would like to do is put a swap partition
Michal Soltys wrote:
Cry Regarder wrote:
one hot spare. Each disk is partitioned in the same way - 64mb boot
partition identical on each disk, and each disk is bootable (sdX1), swap
(sdX2), partitionable (sdX3). sd[abcde]3 raid has GPT partition - 1st
one is used by LVM2 for the usual
I'm making raid 5 consisting of 4 disks, 500 GB each, with one spare
standby. In future to be expanded with extra disks. Server will be running
with ups, and with extra machine doing daily rsync backup of the system and
stuff deemed important. On top of the raid, there will probably be simple
18 matches
Mail list logo
