On Feb 10 2008 10:34, David Greaves wrote:
Jan Engelhardt wrote:
On Jan 29 2008 18:08, Bill Davidsen wrote:
IIRC there was a discussion a while back on renaming mdadm options
(google Time to deprecate old RAID formats?) and the superblocks
to emphasise the location and data structure. Would
On Feb 10 2008 12:27, David Greaves wrote:
I do not see anything wrong by specifying the SB location as a metadata
version. Why should not location be an element of the raid type?
It's fine the way it is IMHO. (Just the default is not :)
There was quite a discussion about it.
For me the
On Jan 29 2008 18:08, Bill Davidsen wrote:
IIRC there was a discussion a while back on renaming mdadm options
(google Time to deprecate old RAID formats?) and the superblocks
to emphasise the location and data structure. Would it be good to
introduce the new names at the same time as
This makes 1.0 the default sb type for new arrays.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
Create.c |6 --
super0.c |4 +---
super1.c |2 +-
3 files changed, 2 insertions(+), 10 deletions(-)
Index: mdadm-2.6.4/Create.c
On Jan 28 2008 18:19, David Greaves wrote:
Jan Engelhardt wrote:
This makes 1.0 the default sb type for new arrays.
IIRC there was a discussion a while back on renaming mdadm options
(google Time to deprecate old RAID formats?) and the superblocks
to emphasise the location and data structure
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
drivers/md/md.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index cef9ebd..6295b90 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5033,7 +5033,7 @@ static int md_seq_show
On Dec 7 2007 07:30, Nix wrote:
On 6 Dec 2007, Jan Engelhardt verbalised:
On Dec 5 2007 19:29, Nix wrote:
On Dec 1 2007 06:19, Justin Piszcz wrote:
RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if
you use 1.x superblocks with LILO you can't boot)
Says who? (Don't use
On Dec 5 2007 19:29, Nix wrote:
On Dec 1 2007 06:19, Justin Piszcz wrote:
RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if
you use 1.x superblocks with LILO you can't boot)
Says who? (Don't use LILO ;-)
Well, your kernels must be on a 0.90-superblocked RAID-0 or RAID-1
On Dec 1 2007 06:19, Justin Piszcz wrote:
RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if
you use 1.x superblocks with LILO you can't boot)
Says who? (Don't use LILO ;-)
, and then:
/dev/sda1+sdb1 - /dev/md0 - swap
/dev/sda2+sdb2 - /dev/md1 - /boot (ext3)
On Dec 1 2007 07:12, Justin Piszcz wrote:
On Sat, 1 Dec 2007, Jan Engelhardt wrote:
On Dec 1 2007 06:19, Justin Piszcz wrote:
RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if
you use 1.x superblocks with LILO you can't boot)
Says who? (Don't use LILO ;-)
I like LILO
On Dec 1 2007 06:26, Justin Piszcz wrote:
I ran the following:
dd if=/dev/zero of=/dev/sdc
dd if=/dev/zero of=/dev/sdd
dd if=/dev/zero of=/dev/sde
(as it is always a very good idea to do this with any new disk)
Why would you care about what's on the disk? fdisk, mkfs and
the day-to-day
Hi,
a while back I reported a bug for 2.6.21 where creating an MD raid array
with internal bitmap on a sparc64 system does not work. I have not yet
heard back (or I forget); has this been addressed yet?
(mdadm -C /dev/md0 -l 1 -n 2 -e 1.0 -b internal /dev/ram[01])
thanks,
Jan
On Aug 28 2007 06:08, Michael Evans wrote:
Oh, I see. I forgot about the changelogs. I'd send out version 5
now, but I'm not sure what kernel version to make the patch against.
2.6.23-rc4 is on kernel.org and I don't see any git snapshots.
2.6.23-rc4 is a snapshot in itself, a tagged one at
On Aug 26 2007 04:51, Michael J. Evans wrote:
{
- if (dev_cnt = 0 dev_cnt 127)
- detected_devices[dev_cnt++] = dev;
+ struct detected_devices_node *node_detected_dev;
+ node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
What's the \ good for,
On Aug 12 2007 20:21, [EMAIL PROTECTED] wrote:
per the message below MD (or DM) would need to be modified to work
reasonably well with one of the disk components being over an
unreliable link (like a network link)
Does not dm-multipath do something like that?
are the MD/DM maintainers
On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote:
now, I am not an expert on either option, but three are a couple things that I
would question about the DRDB+MD option
1. when the remote machine is down, how does MD deal with it for reads and
writes?
I suppose it kicks the drive and you'd
On Jul 20 2007 07:35, Willy Tarreau wrote:
On Fri, Jul 20, 2007 at 08:13:03AM +0300, Al Boldi wrote:
As always, a good friend of mine managed to scratch my partion table by
cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but
at least the first 100MB are gone. I can
Hi,
RAID levels 0 and 4 do not seem to like the -b internal. Is this
intentional? Runs 2.6.20.2 on i586.
(BTW, do you already have a PAGE_SIZE=8K fix?)
14:47 ichi:/dev # mdadm -C /dev/md0 -l 4 -e 1.0 -b internal -n 2 /dev/ram[01]
mdadm: RUN_ARRAY failed: Input/output error
mdadm: stopped
On May 31 2007 09:00, Bill Davidsen wrote:
Hardly, with all the Fedora specific cruft. Anyway, there was a
simple patch posted in RH bugzilla, so I've gone with that.
I'm not sure what Fedora has to do with it,
I like highly modularized systems. And that requires an initramfs
to load
Hi,
the following command strangely gives -EIO ...
12:27 sun:~ # mdadm -C /dev/md4 -l 1 -n 2 -e 1.0 -b internal /dev/ram0
missing
md: md4: raid array is not clean -- starting background reconstruction
md4: failed to create bitmap (-5)
md: pers-run() failed ...
mdadm: RUN_ARRAY failed:
On May 30 2007 22:05, Neil Brown wrote:
the following command strangely gives -EIO ...
12:27 sun:~ # mdadm -C /dev/md4 -l 1 -n 2 -e 1.0 -b internal /dev/ram0
missing
md: md4: raid array is not clean -- starting background reconstruction
md4: failed to create bitmap (-5)
md: pers-run()
On May 30 2007 16:35, Bill Davidsen wrote:
On 29 May 2007, Jan Engelhardt uttered the following:
from your post at
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07384.html I
read that autodetecting arrays with a 1.x superblock is currently
impossible. Does it at least work
On May 31 2007 09:09, Neil Brown wrote:
the following command strangely gives -EIO ...
12:27 sun:~ # mdadm -C /dev/md4 -l 1 -n 2 -e 1.0 -b internal /dev/ram0
missing
Where could I start looking?
Linux sun 2.6.21-1.3149.al3.8smp #3 SMP Wed May 30 09:43:00 CEST 2007
sparc64 sparc64
Hi,
from your post at
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07384.html I
read that autodetecting arrays with a 1.x superblock is currently
impossible. Does it at least work to force the kernel to always assume a
1.x sb? There are some 'broken' distros out there that still
On May 10 2007 16:22, NeilBrown wrote:
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2007-05-10 15:51:54.0 +1000
+++ ./drivers/md/md.c 2007-05-10 16:05:10.0 +1000
@@ -5095,7 +5095,7 @@ static int is_mddev_idle(mddev_t *mddev)
*
On May 10 2007 20:04, Neil Brown wrote:
- if ((curr_events - rdev-last_events + 4096) 8192) {
+ if ((long)curr_events - (long)rdev-last_events 4096) {
rdev-last_events = curr_events;
idle = 0;
}
/* sync IO will cause
On May 9 2007 18:51, Linus Torvalds wrote:
(But Andrew never saw your email, I suspect: [EMAIL PROTECTED] is probably
some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
What do the letters kp stand for?
Jan
--
-
To unsubscribe from this list: send the line
On May 9 2007 15:38, Jens Axboe wrote:
I am a mdadm/disk/hard drive fanatic, I was curious:
On i386, we can at most fit 256 scatterlist elements into a page,
and on x86-64 we are stuck with 128. So that puts us somewhere
between 512kb and 1024kb for a single IO.
How come 32bit is 256 and
Change Kconfig objects from menu, config into menuconfig so
that the user can disable the whole feature without having to
enter the menu first.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
drivers/md/Kconfig | 15 +--
1 file changed, 5 insertions(+), 10 deletions
Hi list,
when a user does `mdadm -C /dev/md0 -l any -n whatever fits
devices`, the array gets rebuilt for at least RAID1 and RAID5, even if
the disk contents are most likely not of importance (otherwise we would
not be creating a raid array right now). Could not this needless resync
be
On Apr 30 2007 11:19, Dan Williams wrote:
when a user does `mdadm -C /dev/md0 -l any -n whatever fits
devices`, the array gets rebuilt for at least RAID1 and RAID5, even if
the disk contents are most likely not of importance (otherwise we would
not be creating a raid array right now). Could
On Apr 30 2007 13:54, [EMAIL PROTECTED] wrote:
But then the array needs to keep track of where data is so that it knows
what is good and what is bad.
I assume it knows that, because you can reboot while an array is still
syncing and it Does The Right Thing. Furthermore, there is also the
On Apr 12 2007 14:26, David Miller wrote:
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Mon, 2 Apr 2007 02:15:57 +0200 (MEST)
Kernel is kernel-smp-2.6.16-1.2128sp4.sparc64.rpm from Aurora Corona.
Perhaps it helps, otherwise hold your breath until I reproduce it.
Jan, if you can reproduce
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Index: linux-2.6.21-rc5/drivers/md/Kconfig
===
--- linux
Hello list,
normally, I'd think that combining drives into a raid1 array would give
me at least a little improvement in read speed. In my setup however,
this does not seem to be the case.
14:16 opteron:/var/log # hdparm -t /dev/sda
Timing buffered disk reads: 170 MB in 3.01 seconds =
Hi,
just when I did
# mdadm -C /dev/md2 -b internal -e 1.0 -l 10 -n 4 /dev/sd[cdef]4
(created)
# mdadm -D /dev/md2
Killed
dmesg filled up with a kernel oops. A few seconds later, the box
locked solid. Since I was only in by ssh and there is not (yet) any
possibility to reset it remotely, this
On Mar 10 2007 12:21, H. Peter Anvin wrote:
Neil Brown wrote:
If I wanted to reshape a raid0, I would just morph it into a raid4
with a missing parity drive, then use the raid5 code to restripe it.
Then morph it back to regular raid0.
Wow, that made my brain hurt.
Given the fact that
On Feb 22 2007 06:59, Neil Brown wrote:
On Wednesday February 21, [EMAIL PROTECTED] wrote:
are there any plans to support reshaping
on raid0 and raid10?
No concrete plans. It largely depends on time and motivation.
I expect that the various flavours of raid5/raid6 reshape will come
first.
On Feb 23 2007 06:41, Justin Piszcz wrote:
I was able to Alt-SysRQ+b but I could not access the console/X/etc, it
appeared
to be frozen.
No sysrq+t? (Ah, unblanking might hang.) Well, netconsole/serial to the rescue,
then ;-)
Jan
--
-
To unsubscribe from this list: send the line
Hello,
are there any plans to support reshaping
on raid0 and raid10?
Jan
--
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
this line in mdadm-2.5.4
Detail.c:
185: ioctl(fd, GET_BITMAP_FILE, bmf) == 0
causes a dmesg warning when running `mdadm -D /dev/md0`:
ioctl32(mdadm:2946): Unknown cmd fd(7) cmd(5915){10} arg(ff2905d0)
on /dev/md0
on Aurora Linux corona_2.90 with 2.6.18-1.2798.al3.1smp(sparc64).
+ ret = bdi_congested(q-backing_dev_info,
bits);
+ }
+ }
+ rcu_read_unlock();
+ return ret;
+}
+
+
/* Barriers
And one white line too much, but YMMV ;-)
Jan Engelhardt
--
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body
Why we're updating it BACKWARD in the first place?
To avoid writing to spares when it isn't needed - some people want
their spare drives to go to sleep.
That sounds a little dangerous. What if it decrements below 0?
Jan Engelhardt
--
-
To unsubscribe from this list: send the line unsubscribe
On Jul 11 2006 12:03, Justin Piszcz wrote:
Subject: Raid5 Reshape Status + xfs_growfs = Success! (2.6.17.3)
Now we just need shrink-reshaping and xfs_shrinkfs... :)
Jan Engelhardt
--
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL
, either
at the end (for 1.0), at the start (for 1.1) or 4K from
the start (for 1.2).
No 0.91 :(
(My mdadm is 2.2, but the problem remains in 2.5.2)
Jan Engelhardt
--
!
Hm, what's superblock 0.91? It is not mentioned in mdadm.8.
Jan Engelhardt
--
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
personally, I think this this useful functionality, but my personal
preference is that this would be in DM/LVM2 rather than MD. but given
Neil is the MD author/maintainer, I can see why he'd prefer to do it in
MD. :)
Why don't MD and DM merge some bits?
Jan Engelhardt
--
-
To unsubscribe
47 matches
Mail list logo