Adds description for subarray delete and subarray rename switches. Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> --- mdadm.8 | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/mdadm.8 b/mdadm.8 index 4edfc41..edc511c 100644 --- a/mdadm.8 +++ b/mdadm.8 @@ -1173,6 +1173,20 @@ the block where the superblock would be is overwritten even if it doesn't appear to be valid. .TP +.B ...

Added new metatata_update type update_rename_subarray and its update_process service to perform rename_subarray in context of mdmon. It allows to modify metadata of managed arrays) Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> --- super-intel.c | 42 +++++++++++++++++++++++++++++++++++++++--- 1 files changed, 39 insertions(+), 3 deletions(-) diff --git a/super-intel.c b/super-intel.c index b26cd06..3b21cd9 100644 --- a/super-intel.c +++ ...

To support delete feature patch adds --kill-subarray switch (no short form) with optional parameter to specify member index. Instead one can use -N <name> or -u <uuid> to choose array. mdadm --kill-subarray[=member-id | -N <name> | -u <uuid> \ <container-or-devlist> <container-or-devlist> is either container device or list of devices. In the second case, if the container with given array is active, the list of disk devices MUST be complete ie. must contain all valid container ...

For active container with remaining raid0 volume (mdmon is not running) patch adds possibility to delete subarray and update metadata on all component devices belonging to this volume. Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> --- Makefile | 4 +- mdadm.h | 21 +++++ super-intel.c | 40 +++++++++ util.c | 262 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 325 insertions(+), 2 deletions(-) diff ...

Patch adds a simple mechanism to write a value to sysfs file giving its full path. Existing methods need eg. mdinfo available what is not always necessary/available. Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> --- mdadm.h | 1 + sysfs.c | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/mdadm.h b/mdadm.h index 402a8c6..304378a 100644 --- a/mdadm.h +++ b/mdadm.h @@ -419,6 +419,7 @@ extern int ...

This allows finding the array which contains a given component. Components are named using the kernel-internal string name such as "sda1" or "hdb". Don't return member arrays, only the contain that contains them. Also tidy up the parsing of 'inactive' arrays in /proc/mdstat. If we see 'inactive' we need to set 'in_devs' immediately as there is no level coming. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> --- ...

devnum2devname() returns pointer to memory allocated with strdup. It must be released to prevent memory leak. Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> --- util.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/util.c b/util.c index d292a66..423b66f 100644 --- a/util.c +++ b/util.c @@ -1502,7 +1502,11 @@ int mdmon_pid(int devnum) char pid[10]; int fd; int n; - sprintf(path, "%s/%s.pid", pid_dir, ...

raid1.c's read_balance() function has: const unsigned long this_sector = r1_bio->sector; Doesn't that need to be: const sector_t this_sector = r1_bio->sector; for compatibility with LBD on 32-bit platforms? It looks as though truncating the sector number to 32 bits could cause it to read *above* the resync window on an unsync'ed disk. -- Jordan Russell --

I'm at the point now where I'm just looking for triage advice so I can work on it tonight. Most of the contents were backed up offsite, but a little bit out of date. Nothing critical, but inconvenient, like recovery images for relative's systems. Do I kill it and start over, or is there any hope of recovering from the reshape? --

The system froze sometime in the middle of the night, and oddly... the --backup-file I specified last night is missing. Is there any reason that mdadm would unlink it for a short span of time during the reshape? The raid5 array was 4x500GB drives, I was reshaping to raid6 by adding another 500gb drive. $ sudo mdadm --assemble /dev/md1 mdadm: Failed to restore critical section for reshape, sorry. Possibly you needed to specify the --backup-file FC12, using $ mdadm ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, I'm using Linux' MD feature with two RAID 1 arrays and am pretty happy with it. Since I'm planning to change my disk layout, I'd like to switch to RAID level 10. But when configuring current 2.6.33 stable kernel, I found RAID 10 marked experimental. Why is this that case? I normally do not tend to ignore the "EXPERIMENTAL" warning; in fact, my current "home server" kernel does not include any single item marked ...

Hello Neil, list, I am trying to fix one RAID6 array wich have 12x1.5TB (samsung) drives. Actually the array have 1 missing drive, and 3 wich have some bad sectors! Genearlly because it is RAID6 there is no data lost, because the bad sectors are not in one address line, but i can't rebuild the missing drive, because the kernel drops out the bad sector-drives one by one during the rebuild process. My question is, there is any way, to force the array to keep the members in even if have ...

What version of the kernel are you running? If it's running anywhere recent kernel it shouldn't kick drives upon read error but instead recreate from parity. You should probably send "repair" to the md device (echo repair > /sys/block/mdX/md/sync_action) and see if that fixes the bad blocks. I believe this came in 2.6.15 or something like that (google if you're in that neighbourhood, if you're in 2.6.26 or alike then you should be fine). -- Mikael Abrahamsson email: ...

There was a thread[1] some time ago, where HPA confirmed that the RAID6 data is sufficient to write an algorithm which will be able to determine which sector is in fact the offending one. There wasn't any interest to incorporate this into the sync_action/repair function though :( [1] http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07327.html --

Yes. -hpa --

On Thu, 22 Apr 2010 15:56:21 -0400 there's only one, and yes, you're right.. /dev/md2p6 isn't in the list. According to blkid: # blkid /dev/sda1: UUID="9a9beac0-d5fa-94d1-86df-b710391e5a7c" TYPE="linux_raid_member" /dev/sda2: UUID="8327bc1c-3d13-ee78-86df-b710391e5a7c" TYPE="linux_raid_member" /dev/sda3: UUID="01821f8d-da8e-fd6a-86df-b710391e5a7c" TYPE="linux_raid_member" /dev/sdb1: UUID="9a9beac0-d5fa-94d1-86df-b710391e5a7c" TYPE="linux_raid_member" /dev/sdb2: ...

I'm a bit confused. What kernel and nfs-utils version is running on the problematic Linux server? Also, what are the contents of /proc/net/rpc/nfsd.export/content and /proc/net/rpc/nfsd.content after you try to access the filesystem? --

Huh. That should be new enough for it to be using uuid's. I wonder why it isn't? --

On Thu, 22 Apr 2010 15:47:30 -0400 $ ls -1 /dev/disk/by-uuid/ 0e9742f6-44e3-431c-911f-4c914e4f81d5 31ae89c6-dba6-4351-b3a9-e8b08be07c3d 4429ba7a-afd2-4c61-83a0-900dae1bccdc 463bbc42-c19b-4b9e-bae7-838ac0e2e5c6 473b9320-88a4-44eb-b592-2ac98619bc9b 53d16b07-d496-4f8f-ad59-ea34aaf169f4 6adf1c55-405c-43cf-a84d-be5d2746d300 b35a7bca-12ad-4738-a895-52f20b7cc5d9 dc892f1f-0b83-41dd-bde7-0761295f33a3 f7ac4165-320f-4235-a78a-5fe1bd0aac24 -- Dont wait to die to find paradise... -- Cheerz, Vlad ...

Weird, I wonder if they just forgot to update the spec sheet for the drive then since it says 300k. --

It is a DOS executable. As previously mentioned, you can use: USB floppy emulation (if the BIOS supports it) USB HD emulation Booting from an HD partition (e.g. temporarily break RAID for one of the swap partitons, and install DOS in that partition). syslinux + memdisk + image file pxelinux + memdisk + image file I use the latter for using DOS bios upgrades etc. remotely using IPMI+SoL. If anyone want to try and reverse-engineer wdidle3, it appears to have been compiled with Watcom ...

+1 Insightful. This is a gem of a tip - so much so that I've archived the text of this as I KNOW it will come in handy soon. It may be been semi-off topic, but it is worth its weight in gold! Thankyou! On Wed, 21 Apr 2010 21:31:27 +0200, Clinton Lee Taylor -- Steven Haigh Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 --

Gaah, yes. How about just making it "unsigned long" instead of sector_t, and telling people that if they have more than 2**32 chunks in their RAID array, they should damn well use a 64-bit CPU. The alternative, of course, is to use "sector_div()" everywhere. Neil? Linus --