Re: Convert RAID1 to standard ext2
Timothy Weaver wrote: Hi, I had 2x750GB drives in a RAID1 configuration in a D-Link NAS (DNS-323) device with embedded Linux as an ext2 volume. The configuration was corrupted and the NAS no longer saw the RAID. I put the drives in another Linux box and was able to use mdadm to scan the drives. It recognized the RAID1 configuration and created the RAID device at /dev/md0. Unfortunately, it says it is corrupt and cannot be mounted. I tried using e2fsck / fsck but it says the superblock is corrupt. Trying to use copies of the superblock were unsuccessful. I am confident the data is still there and want to get to it. Is there a way to take one of the drives and convert it from being in the RAID1 set to just a standard ext2 partition in a non-destructive way? I figured this should be possible with the second drive just to be sure not to destroy both copies of the data. Try a read-only loopback mount of the partition (either). However, I think you're missing something else, although I don't have a clue what. Unless the O/S started writing bad data or the hardware got sick, you should be able to recover. In any case this allows you to do something non-destructive and use offset= depending on the superblock location. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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
Cannot sync RAID5 anymore - MCE problem?
Hello everybody. I have a strange and severe problem with my Raid-Array and I have to contact "experts" before I can continue with a clear conscience. I wanted to exchange 2 disks in my Raid5 array by two newer ones. So I connected the new to my machine partitioned the correct layout added one of them as a Spare and "--faild" the partition of the disk I wanted to remove first. Rebulding of the array started immediately and finished fine. Now I took the two old disks out and put the new ones in. By removing the other disk from my array I degraded it. After booting I added the correct partition of my new drive to the Raid5 and waited for the syncing to finish ... but it didn't. Is crashed my whole machine with an MCE: CPU 0: Machine check exception: 4 bank 4 b200070f0f ... Kernel Panic - not synching: machine check The reason why I write an MCE problem to the Software-Raid list is that this problem is very reproducible and always happens when resyncing of my array has finished 24.9%. I tried it about ten times so I am really sure that there is some connection to resyncing since this problem does not seem to appear under different conditions anymore. I tried to do an rsync-backup of my raid-array which lead the the same crash. After that I observed that this crash has occured when copying a not so important Backup of something else. I deleted that old Backup and since that my problem seems to ONLY occur if I try to resync my array. I am running Gentoo on an AMD64 3200+ and K8N Neo4 Platinum and my problem seems to be similar to the problems of these guys: http://kerneltrap.org/node/4993 but somehow related to resyncing. I have reiserfs on my array and successfully completed a "reiserfsck --rebuild-tree". I think it is not important but it might be good to mention that I use LVM, too. I have also tried to resync the array to my old disk (with the second new one removed), but that leads to the same problem. I have tried several things like removing one RAM module or using different RAM-Banks I checked for leaking caps I tried without DMA, tried different kernels and played with some kernel options. Is there a way to figure out what hardware seems to be the problem? My hardware worked flawlessly for over 1.5 years if I did not break something while physically mounting the disks or cleaning dust out of the case it can only be a problem of the first new harddrive (which is unfortunately part of my degraded raid-array already). Is it possible that an SATA1 Cable on a SATA2 capable controller connected to a SATA2 capable disk leads to such errors? Since I was able to copy my data I think it is in perfect condition, but there seems to be a problem on the array in the "empty"-part. Does anybody know a way how to over- or rewrite the empty blocks of a reiserfs-partition? Or some tool to find/correct disk-problems. (I tried reiserfsck but that does not find anything) What is the smartest way for my to proceed to get my degraded array redundant again? I could delete the whole array, try set it up identically again and recopy the data, but if it is really a hardware problem that would be a waste of time. Thanks in advance ... Ramin - 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
Re: Mustn't be RAID 1 and 0 read-performance be similar?
Rustedt, Florian <[EMAIL PROTECTED]> wrote: > If the speed on RAID 0 is based on reading out in parallel, then it must be > the same on RAID 1, mustn't it? > On RAID 1, it is possible, to read two blocks in parallel to speed up, too. It's not that simple. On RAID0 you can read one single stream of data from all of the disks in parallel: you read one stream from each disk with each stream containing completely different data and merge them together to get the original stream. On RAID1 you can only read exactly the same stream from all of the disks. Thus, RAID1 cannot provide RAID0's speed-up for a single stream. However, if you read multiple streams parallel, RAID1 can do better than RAID0 because you can read stream1 from disk1, stream2 from disk2 etc. Using RAID0, this speed-up can only be achieved for streams <= chunk size. regards Mario -- Tower: "Say fuelstate." Pilot: "Fuelstate." Tower: "Say again." Pilot: "Again." Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..." - 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
[kj] is_power_of_2 in drivers/md/dm-raid1.c
Replacing n & (n - 1) for power of 2 check by is_power_of_2(n)
Signed-off-by: vignesh babu <[EMAIL PROTECTED]>
---
diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index 144071e..969b398 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define DM_MSG_PREFIX "raid1"
#define DM_IO_PAGES 64
@@ -994,7 +995,7 @@ static void free_context(struct mirror_set *ms, struct
dm_target *ti,
static inline int _check_region_size(struct dm_target *ti, uint32_t size)
{
- return !(size % (PAGE_SIZE >> 9) || (size & (size - 1)) ||
+ return !(size % (PAGE_SIZE >> 9) || !is_power_of_2(size) ||
size > ti->len);
}
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 83ddbfe..ad2836a 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "dm-snap.h"
#include "dm-bio-list.h"
@@ -415,7 +416,7 @@ static int set_chunk_size(struct dm_snapshot *s, const char
*chunk_size_arg,
chunk_size = round_up(chunk_size, PAGE_SIZE >> 9);
/* Check chunk_size is a power of 2 */
- if (chunk_size & (chunk_size - 1)) {
+ if (!is_power_of_2(chunk_size)) {
*error = "Chunk size is not a power of 2";
return -EINVAL;
}
diff --git a/drivers/md/dm-stripe.c b/drivers/md/dm-stripe.c
index 51f5e07..969944a 100644
--- a/drivers/md/dm-stripe.c
+++ b/drivers/md/dm-stripe.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#define DM_MSG_PREFIX "striped"
@@ -99,7 +100,7 @@ static int stripe_ctr(struct dm_target *ti, unsigned int
argc, char **argv)
/*
* chunk_size is a power of two
*/
- if (!chunk_size || (chunk_size & (chunk_size - 1)) ||
+ if (!is_power_of_2(chunk_size) ||
(chunk_size < (PAGE_SIZE >> SECTOR_SHIFT))) {
ti->error = "Invalid chunk size";
return -EINVAL;
--
Vignesh Babu BM
_
"Why is it that every time I'm with you, makes me believe in magic?"
-
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
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
[EMAIL PROTECTED] wrote: Would this just be relevant to network devices or would it improve support for jostled usb and sata hot-plugging I wonder? good question, I suspect that some of the error handling would be similar (for devices that are unreachable not haning the system for example), but a lot of the rest would be different (do you really want to try to auto-resync to a drive that you _think_ just reappeared, Well, omit 'think' and the answer may be "yes". A lot of systems are quite simple and RAID is common on the desktop now. If jostled USB fits into this category - then "yes". what if it's a different drive? how can you be sure? And that's the key isn't it. We have the RAID device UUID and the superblock info. Isn't that enough? If not then given the work involved an extended superblock wouldn't be unreasonable. And I suspect the capability of devices would need recording in the superblock too? eg 'retry-on-fail' I can see how md would fail a device but may now periodically retry it. If a retry shows that it's back then it would validate it (UUID) and then resync it. ) the error rate of a network is gong to be significantly higher then for USB or SATA drives (although I suppose iscsi would be limilar) I do agree - I was looking for value-add for the existing subsystem. If this benefits existing RAID users then it's more likely to be attractive. David - 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
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
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 interested in extending their code in this > direction? > or would they prefer to keep it simpler by being able to continue to assume > that the raid components are connected over a highly reliable connection? 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
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
On Mon, 13 Aug 2007, David Greaves wrote: [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) are the MD/DM maintainers interested in extending their code in this direction? or would they prefer to keep it simpler by being able to continue to assume that the raid components are connected over a highly reliable connection? if they are interested in adding (and maintaining) this functionality then there is a real possibility that NBD+MD/DM could eliminate the need for DRDB. however if they are not interested in adding all the code to deal with the network type issues, then the argument that DRDB should not be merged becouse you can do the same thing with MD/DM + NBD is invalid and can be dropped/ignored David Lang As a user I'd like to see md/nbd be extended to cope with unreliable links. I think md could be better in handling link exceptions. My unreliable memory recalls sporadic issues with hot-plug leaving md hanging and certain lower level errors (or even very high latency) causing unsatisfactory behaviour in what is supposed to be a fault 'tolerant' subsystem. Would this just be relevant to network devices or would it improve support for jostled usb and sata hot-plugging I wonder? good question, I suspect that some of the error handling would be similar (for devices that are unreachable not haning the system for example), but a lot of the rest would be different (do you really want to try to auto-resync to a drive that you _think_ just reappeared, what if it's a different drive? how can you be sure?) the error rate of a network is gong to be significantly higher then for USB or SATA drives (although I suppose iscsi would be limilar) David Lang - 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
Convert RAID1 to standard ext2
Hi, I had 2x750GB drives in a RAID1 configuration in a D-Link NAS (DNS-323) device with embedded Linux as an ext2 volume. The configuration was corrupted and the NAS no longer saw the RAID. I put the drives in another Linux box and was able to use mdadm to scan the drives. It recognized the RAID1 configuration and created the RAID device at /dev/md0. Unfortunately, it says it is corrupt and cannot be mounted. I tried using e2fsck / fsck but it says the superblock is corrupt. Trying to use copies of the superblock were unsuccessful. I am confident the data is still there and want to get to it. Is there a way to take one of the drives and convert it from being in the RAID1 set to just a standard ext2 partition in a non-destructive way? I figured this should be possible with the second drive just to be sure not to destroy both copies of the data. Thanks. - 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
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
[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) are the MD/DM maintainers interested in extending their code in this direction? or would they prefer to keep it simpler by being able to continue to assume that the raid components are connected over a highly reliable connection? if they are interested in adding (and maintaining) this functionality then there is a real possibility that NBD+MD/DM could eliminate the need for DRDB. however if they are not interested in adding all the code to deal with the network type issues, then the argument that DRDB should not be merged becouse you can do the same thing with MD/DM + NBD is invalid and can be dropped/ignored David Lang As a user I'd like to see md/nbd be extended to cope with unreliable links. I think md could be better in handling link exceptions. My unreliable memory recalls sporadic issues with hot-plug leaving md hanging and certain lower level errors (or even very high latency) causing unsatisfactory behaviour in what is supposed to be a fault 'tolerant' subsystem. Would this just be relevant to network devices or would it improve support for jostled usb and sata hot-plugging I wonder? David - 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
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
Paul Clements wrote: Well, if people would like to see a timeout option, I actually coded up a patch a couple of years ago to do just that, but I never got it into mainline because you can do almost as well by doing a check at user-level (I basically ping the nbd connection periodically and if it fails, I kill -9 the nbd-client). Yes please. David - 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
[PATCH] [442/2many] MAINTAINERS - SOFTWARE RAID (Multiple Disks) SUPPORT
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches <[EMAIL PROTECTED]> diff --git a/MAINTAINERS b/MAINTAINERS index d17ae3d..29a2179 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4205,6 +4205,8 @@ P:Neil Brown M: [EMAIL PROTECTED] L: linux-raid@vger.kernel.org S: Supported +F: drivers/md/ +F: include/linux/raid/ HIBERNATION (aka Software Suspend, aka swsusp): P: Pavel Machek - 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
