* Re: GET_ARRAY_INFO assumptions?
From: NeilBrown @ 2017-04-20 21:49 UTC (permalink / raw)
To: Jes Sorensen, Shaohua Li; +Cc: linux-raid
In-Reply-To: <59ca76c6-1f1f-4d9c-4eb9-d468131e0d55@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
On Thu, Apr 20 2017, Jes Sorensen wrote:
>
> I think I got it right this time and pushed it into git. It made things
> a lot prettier too IMHO :)
>
> In the process I also changed the behavior of
> sysfs_read(GET_ARRAY_STATE) as I really didn't like how it was copying
> in the string rather than parsing it.
>
> I am traveling at the moment and don't yet have my new raid test box
> setup back at the office, so my testing is limited. If I broke something
> badly, feel free to throw rotten tomatoes at me.
>
> Cheers,
> Jes
Looks good to me, except...
/*
* Beware map_name() uses strcmp() so active-idle must come before
* active, to be detected correctly.
*/
???
If map_name() used strncmp() you might need to be careful, but not with
strcmp.
Also:
int map_name(mapping_t *map, char *name)
{
while (map->name) {
if (strcmp(map->name, name)==0)
return map->num;
map++;
}
return map->num;
}
Both returns do the same thing... so there should (could) just be one.
is:
while (map->name && strcmp(map->name, name) != 0)
map++;
return map->num;
too terse??
I do like that you could use map_name to parse the array_state file.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [md PATCH] md: handle read-only member devices better.
From: NeilBrown @ 2017-04-20 21:54 UTC (permalink / raw)
To: Shaohua Li; +Cc: Linux-RAID, Nanda Kishore Chinnaram
In-Reply-To: <20170420202306.zcsx4prawtqyapfy@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
On Thu, Apr 20 2017, Shaohua Li wrote:
> On Sat, Apr 15, 2017 at 02:45:31PM +1000, Neil Brown wrote:
>> On Wed, Apr 12 2017, Shaohua Li wrote:
>>
>> > On Thu, Apr 13, 2017 at 08:53:48AM +1000, Neil Brown wrote:
>> >>
>> >> 1/ If an array has any read-only devices when it is started,
>> >> the array itself must be read-only
>> >> 2/ A read-only device cannot be added to an array after it is
>> >> started.
>> >> 3/ Setting an array to read-write should not succeed
>> >> if any member devices are read-only
>> >
>> > Didn't get these. We call md_import_device() first to open under layer disk. We
>> > always use FMOD_READ|FMOD_WRITE to open the disk. So if the disk is ro,
>> > md_import_device should fail, we don't add the disk to the array. Why would we
>> > have such issues?
>> >
>>
>> Because life isn't always as simple as we might like it to be. :-(
>>
>> md_import_device() calls lock_rdev() which calls blkdev_get_by_dev().
>>
>> blkdev_get_by_dev() doesn't pay much attention to the mode, nor does
>> blkdev_get() which it calls. The main place where FMODE_WRITE could be
>> rejected on a read-only device is in the device's 'open()' function. A
>> few open functions do check for read-only, but it isn't at all
>> consistent.
>> scsi/sd.c does, block/loop.c doesn't, nor does nvme. Most drivers seem
>> to ignore the mode.
>>
>> blkdev_get_by_path() has
>>
>> if ((mode & FMODE_WRITE) && bdev_read_only(bdev)) {
>> blkdev_put(bdev, mode);
>> return ERR_PTR(-EACCES);
>> }
>>
>> so when you open a device by path name you always get this check, but
>> not when you open a device by device-number like md does.
>> It is worth having a look at
>> Commit: e51900f7d38c ("block: revert block_dev read-only check")
>> from 2011. The bdev_read_only() check was in blkdev_get() for a while,
>> but it was moved out because doing that broke md and dm and others.
>>
>> So at present, callers of blkdev_get_by_dev() need to do their own
>> bdev_read_only() tests before writing.
>> We could discuss where in md.c is the best place to put them, but unless
>> you want to take on a largish project to 'fix' (or audit) all callers of
>> blkdev_get_by_dev(), they need to go in md somewhere.
>
> It's unfortunate we need the hack, but anyway I applied this. I'm wonding how
> useful a ro array is. At least ro array with .sync_request is dangerous because
> we could read inconsistent data.
For a RAID0, a ro array is as useful as any other ro device.
For RAID1 etc it isn't so obvious, but the code tries to do the
correct thing I think. e.g. if a RAID1 is not known to be in-sync, then
reads will all come from the "first" device, so data should not
inconsistent.
If that first device fails, you will start getting reads from the second
device, which could be a problem.
I think it is better to allow access despite possible problems rather
than denying the possibility of read-only access altogether.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH] md/raid1: remove unused queue
From: Lidong Zhong @ 2017-04-21 3:52 UTC (permalink / raw)
To: linux-raid
From: Lidong Zhong <lidong.zhong@suse.com>
A queue is declared and get from the disk of the array, but it's not
used anywhere. So removing it from the source.
Signed-off-by: Lidong Zhong <lidong.zhong@suse.com>
---
drivers/md/raid1.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index a34f587..559f848 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -3064,7 +3064,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
err = -EINVAL;
spin_lock_init(&conf->device_lock);
rdev_for_each(rdev, mddev) {
- struct request_queue *q;
int disk_idx = rdev->raid_disk;
if (disk_idx >= mddev->raid_disks
|| disk_idx < 0)
@@ -3077,8 +3076,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
if (disk->rdev)
goto abort;
disk->rdev = rdev;
- q = bdev_get_queue(rdev->bdev);
-
disk->head_position = 0;
disk->seq_start = MaxSector;
}
--
2.10.0
^ permalink raw reply related
* Re: [PATCH] md/raid1: remove unused queue
From: Guoqing Jiang @ 2017-04-21 7:10 UTC (permalink / raw)
To: Lidong Zhong, linux-raid
In-Reply-To: <20170421035216.25771-1-lzhong@suse.com>
On 04/21/2017 11:52 AM, Lidong Zhong wrote:
> From: Lidong Zhong <lidong.zhong@suse.com>
>
> A queue is declared and get from the disk of the array, but it's not
> used anywhere. So removing it from the source.
>
> Signed-off-by: Lidong Zhong <lidong.zhong@suse.com>
> ---
> drivers/md/raid1.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index a34f587..559f848 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -3064,7 +3064,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
> err = -EINVAL;
> spin_lock_init(&conf->device_lock);
> rdev_for_each(rdev, mddev) {
> - struct request_queue *q;
> int disk_idx = rdev->raid_disk;
> if (disk_idx >= mddev->raid_disks
> || disk_idx < 0)
> @@ -3077,8 +3076,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
> if (disk->rdev)
> goto abort;
> disk->rdev = rdev;
> - q = bdev_get_queue(rdev->bdev);
> -
> disk->head_position = 0;
> disk->seq_start = MaxSector;
> }
Seems commit 8ae12666 "block: kill merge_bvec_fn() completely" forgot to
kill them. I think we can remove similar code from raid10 as well.
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e3fd725..00a2d25f 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3565,7 +3565,6 @@ static int raid10_run(struct mddev *mddev)
rdev_for_each(rdev, mddev) {
long long diff;
- struct request_queue *q;
disk_idx = rdev->raid_disk;
if (disk_idx < 0)
@@ -3584,7 +3583,6 @@ static int raid10_run(struct mddev *mddev)
goto out_free_conf;
disk->rdev = rdev;
}
- q = bdev_get_queue(rdev->bdev);
diff = (rdev->new_data_offset - rdev->data_offset);
if (!mddev->reshape_backwards)
diff = -diff;
Lidong, care to send a new version to include raid10 part? Thanks.
Cheers,
Guoqing
^ permalink raw reply related
* [PATCH] md/raid1/10: remove unused queue
From: Lidong Zhong @ 2017-04-21 7:21 UTC (permalink / raw)
To: linux-raid
From: Lidong Zhong <lidong.zhong@suse.com>
A queue is declared and get from the disk of the array, but it's not
used anywhere. So removing it from the source.
Signed-off-by: Lidong Zhong <lzhong@suse.com>
---
drivers/md/raid1.c | 3 ---
drivers/md/raid10.c | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index a34f58772022..559f848794a6 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -3064,7 +3064,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
err = -EINVAL;
spin_lock_init(&conf->device_lock);
rdev_for_each(rdev, mddev) {
- struct request_queue *q;
int disk_idx = rdev->raid_disk;
if (disk_idx >= mddev->raid_disks
|| disk_idx < 0)
@@ -3077,8 +3076,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
if (disk->rdev)
goto abort;
disk->rdev = rdev;
- q = bdev_get_queue(rdev->bdev);
-
disk->head_position = 0;
disk->seq_start = MaxSector;
}
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e89a8d78a9ed..5c629f289216 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3759,7 +3759,6 @@ static int raid10_run(struct mddev *mddev)
rdev_for_each(rdev, mddev) {
long long diff;
- struct request_queue *q;
disk_idx = rdev->raid_disk;
if (disk_idx < 0)
@@ -3778,7 +3777,6 @@ static int raid10_run(struct mddev *mddev)
goto out_free_conf;
disk->rdev = rdev;
}
- q = bdev_get_queue(rdev->bdev);
diff = (rdev->new_data_offset - rdev->data_offset);
if (!mddev->reshape_backwards)
diff = -diff;
--
2.12.0
^ permalink raw reply related
* Re: [PATCH] md/raid1/10: remove unused queue
From: Guoqing Jiang @ 2017-04-21 7:45 UTC (permalink / raw)
To: Lidong Zhong, linux-raid
In-Reply-To: <20170421072138.1117-1-lzhong@suse.com>
On 04/21/2017 03:21 PM, Lidong Zhong wrote:
> From: Lidong Zhong <lidong.zhong@suse.com>
>
> A queue is declared and get from the disk of the array, but it's not
> used anywhere. So removing it from the source.
Acted-by: Guoqing Jiang <gqjiang@suse.com>
Thanks,
Guoqing
> Signed-off-by: Lidong Zhong <lzhong@suse.com>
> ---
> drivers/md/raid1.c | 3 ---
> drivers/md/raid10.c | 2 --
> 2 files changed, 5 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index a34f58772022..559f848794a6 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -3064,7 +3064,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
> err = -EINVAL;
> spin_lock_init(&conf->device_lock);
> rdev_for_each(rdev, mddev) {
> - struct request_queue *q;
> int disk_idx = rdev->raid_disk;
> if (disk_idx >= mddev->raid_disks
> || disk_idx < 0)
> @@ -3077,8 +3076,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
> if (disk->rdev)
> goto abort;
> disk->rdev = rdev;
> - q = bdev_get_queue(rdev->bdev);
> -
> disk->head_position = 0;
> disk->seq_start = MaxSector;
> }
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index e89a8d78a9ed..5c629f289216 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -3759,7 +3759,6 @@ static int raid10_run(struct mddev *mddev)
>
> rdev_for_each(rdev, mddev) {
> long long diff;
> - struct request_queue *q;
>
> disk_idx = rdev->raid_disk;
> if (disk_idx < 0)
> @@ -3778,7 +3777,6 @@ static int raid10_run(struct mddev *mddev)
> goto out_free_conf;
> disk->rdev = rdev;
> }
> - q = bdev_get_queue(rdev->bdev);
> diff = (rdev->new_data_offset - rdev->data_offset);
> if (!mddev->reshape_backwards)
> diff = -diff;
^ permalink raw reply
* Re: [PATCH 1/7] Makefile, LLVM: add -no-integrated-as to KBUILD_[AC]FLAGS
From: Masahiro Yamada @ 2017-04-21 7:49 UTC (permalink / raw)
To: Michael Davidson
Cc: Michal Marek, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Herbert Xu, David S. Miller, Shaohua Li, Alexander Potapenko,
Dmitry Vyukov, Matthias Kaehlcke, X86 ML,
Linux Kbuild mailing list, Linux Kernel Mailing List,
linux-crypto, linux-raid
In-Reply-To: <20170317001520.85223-2-md@google.com>
Hi Michael,
2017-03-17 9:15 GMT+09:00 Michael Davidson <md@google.com>:
> Add -no-integrated-as to KBUILD_AFLAGS and KBUILD_CFLAGS
> for clang.
From the code-diff, it is apparent that
you added -no-integrated-as.
Rather, I'd like to see "why" in the git-log.
Obviously, clang needs this patch to build the kernel,
but can you describe the reason why the integrated assembler is bad?
With git-log reworded, I will pick up this shortly.
Thanks!
> Signed-off-by: Michael Davidson <md@google.com>
> ---
> Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index b841fb36beb2..b21fd0ca2946 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -704,6 +704,8 @@ KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
> # See modpost pattern 2
> KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
> KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
> +KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
> +KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
> else
>
> # These warnings generated too much noise in a regular build.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] dm-crypt: run in a WQ_HIGHPRI workqueue
From: Enric Balletbo i Serra @ 2017-04-21 9:11 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, timmurray
Cc: dm-devel, linux-raid, linux-kernel, ghackmann
From: Tim Murray <timmurray@google.com>
Running dm-crypt in a standard workqueue results in IO competing for CPU
time with standard user apps, which can lead to pipeline bubbles and
seriously degraded performance. Move to a WQ_HIGHPRI workqueue to
protect against that.
Signed-off-by: Tim Murray <timmurray@google.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
We think that would be interesting share one issue that we have and know
the opinion of the maintainers about this patch.
One of the major causes of Bullhead devices slowdowns, is that when the
system is under load, the kworkers responsible for dm-verity and dm-crypt
are runnable but may not run for 10s of ms per iteration. This then results
in mmcqd not being called as often, and the net effect is that disk IO
performance goes to zero. We can see significant improvements when moving
to a WQ_HIGHPRI workqueue for verity and kcryptd.
---
drivers/md/dm-crypt.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 8dbecf1..0b7ffa2 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2738,16 +2738,24 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
}
ret = -ENOMEM;
- cc->io_queue = alloc_workqueue("kcryptd_io", WQ_MEM_RECLAIM, 1);
+ cc->io_queue = alloc_workqueue("kcryptd_io",
+ WQ_HIGHPRI |
+ WQ_MEM_RECLAIM,
+ 1);
if (!cc->io_queue) {
ti->error = "Couldn't create kcryptd io queue";
goto bad;
}
if (test_bit(DM_CRYPT_SAME_CPU, &cc->flags))
- cc->crypt_queue = alloc_workqueue("kcryptd", WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM, 1);
+ cc->crypt_queue = alloc_workqueue("kcryptd",
+ WQ_HIGHPRI |
+ WQ_MEM_RECLAIM, 1);
else
- cc->crypt_queue = alloc_workqueue("kcryptd", WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM | WQ_UNBOUND,
+ cc->crypt_queue = alloc_workqueue("kcryptd",
+ WQ_HIGHPRI |
+ WQ_MEM_RECLAIM |
+ WQ_UNBOUND,
num_online_cpus());
if (!cc->crypt_queue) {
ti->error = "Couldn't create kcryptd queue";
--
2.9.3
^ permalink raw reply related
* [PATCH 3.18-stable] dm bufio: hide bogus warning
From: Arnd Bergmann @ 2017-04-21 13:41 UTC (permalink / raw)
To: stable
Cc: Arnd Bergmann, Mike Snitzer, gregkh, linux-kernel, linux-raid,
dm-devel, Alasdair Kergon
mips-gcc-5.3 warns about correct code on linux-3.18 and earlier:
In file included from ../include/linux/blkdev.h:4:0,
from ../drivers/md/dm-bufio.h:12,
from ../drivers/md/dm-bufio.c:9:
../drivers/md/dm-bufio.c: In function 'alloc_buffer':
../include/linux/sched.h:1975:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
../drivers/md/dm-bufio.c:325:11: note: 'noio_flag' was declared here
The warning disappeared on later kernels with this commit: be0c37c985ed
("MIPS: Rearrange PTE bits into fixed positions.") I assume this only
happened because it changed some inlining decisions.
On 3.18.y, we can shut up the warning by adding an extra initialization.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/md/dm-bufio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index ecbd3ffcf359..91fe43b98c96 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -349,6 +349,7 @@ static void *alloc_buffer_data(struct dm_bufio_client *c, gfp_t gfp_mask,
* as if GFP_NOIO was specified.
*/
+ noio_flag = 0;
if (gfp_mask & __GFP_NORETRY)
noio_flag = memalloc_noio_save();
--
2.9.0
^ permalink raw reply related
* Re: GET_ARRAY_INFO assumptions?
From: Tomasz Majchrzak @ 2017-04-21 14:06 UTC (permalink / raw)
To: Jes Sorensen; +Cc: NeilBrown, Shaohua Li, linux-raid
In-Reply-To: <59ca76c6-1f1f-4d9c-4eb9-d468131e0d55@gmail.com>
On Thu, Apr 20, 2017 at 12:05:54PM -0400, Jes Sorensen wrote:
> On 04/17/2017 07:48 PM, NeilBrown wrote:
> >On Fri, Apr 14 2017, Jes Sorensen wrote:
> >>Looking some more at this, it may be simpler than I thought. How about
> >>this approach (only compile tested):
> >>
> >>int md_array_active(int fd)
> >>{
> >> struct mdinfo *sra;
> >> struct mdu_array_info_s array;
> >> int ret;
> >>
> >> sra = sysfs_read(fd, NULL, GET_VERSION | GET_DISKS);
> >> if (sra) {
> >> if (!sra->array.raid_disks &&
> >> !(sra->array.major_version == -1 &&
> >> sra->array.minor_version == -2))
> >> ret = -ENODEV;
> >> else
> >> ret = 0;
> >>
> >> free(sra);
> >> } else {
> >> ret = ioctl(fd, GET_ARRAY_INFO, &array);
> >> }
> >>
> >> return !ret;
> >>}
> >>
> >>Note 'major = -1 && minor = -2' is sysfs_read's way of saying 'external'.
> >>
> >>This pretty much mimics what the kernel does in the ioctl handler for
> >>GET_ARRAY_INFO:
> >>
> >> case GET_ARRAY_INFO:
> >> if (!mddev->raid_disks && !mddev->external)
> >> err = -ENODEV;
> >> else
> >> err = get_array_info(mddev, argp);
> >> goto out;
> >>
> >>What do you think?
> >
> >I think that it accurately mimics what the current code does.
> >I'm not sure that is what we really want.
> >For testing in Incremental.c if an array is "active" we really
> >should be testing more than "raid_disks != 0".
> >We should be testing, as Shaohua suggested, if
> >array_state != 'clear' or 'inactive'.
> >You cannot get that info through the ioctl interface, so I suppose
> >I decided the current test was 'close enough'.
> >If we are going to stop supported kernels that don't have (e.g.)
> >array_state, then we should really fo the right thing and test
> >array_state.
>
> I think I got it right this time and pushed it into git. It made
> things a lot prettier too IMHO :)
>
> In the process I also changed the behavior of
> sysfs_read(GET_ARRAY_STATE) as I really didn't like how it was
> copying in the string rather than parsing it.
>
> I am traveling at the moment and don't yet have my new raid test box
> setup back at the office, so my testing is limited. If I broke
> something badly, feel free to throw rotten tomatoes at me.
>
Hi Jes,
Compilation with "-O2" flag fails:
CXFLAGS=-O2 make
cc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DVERSION=\"4.0-85-g4435675\" -DVERS_DATE="\"2017-04-20\"" -DUSE_PTHREADS
-DBINDIR=\"/sbin\" -c -o Query.o Query.c
Query.c: In function ‘Query’:
Query.c:92:9: error: ‘level’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
printf("%s: %s %s %d devices, %d spare%s. Use mdadm --detail for more
detail.\n",
^
Query.c:92:9: error: ‘spare_disks’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
Query.c:92:9: error: ‘raid_disks’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
make: *** [Query.o] Error 1
Regards,
Tomek
^ permalink raw reply
* Re: GET_ARRAY_INFO assumptions?
From: Jes Sorensen @ 2017-04-21 16:08 UTC (permalink / raw)
To: Tomasz Majchrzak; +Cc: NeilBrown, Shaohua Li, linux-raid
In-Reply-To: <20170421140634.GA3073@proton.igk.intel.com>
On 04/21/2017 10:06 AM, Tomasz Majchrzak wrote:
> On Thu, Apr 20, 2017 at 12:05:54PM -0400, Jes Sorensen wrote:
>> On 04/17/2017 07:48 PM, NeilBrown wrote:
>>> On Fri, Apr 14 2017, Jes Sorensen wrote:
>>>> Looking some more at this, it may be simpler than I thought. How about
>>>> this approach (only compile tested):
>>>>
>>>> int md_array_active(int fd)
>>>> {
>>>> struct mdinfo *sra;
>>>> struct mdu_array_info_s array;
>>>> int ret;
>>>>
>>>> sra = sysfs_read(fd, NULL, GET_VERSION | GET_DISKS);
>>>> if (sra) {
>>>> if (!sra->array.raid_disks &&
>>>> !(sra->array.major_version == -1 &&
>>>> sra->array.minor_version == -2))
>>>> ret = -ENODEV;
>>>> else
>>>> ret = 0;
>>>>
>>>> free(sra);
>>>> } else {
>>>> ret = ioctl(fd, GET_ARRAY_INFO, &array);
>>>> }
>>>>
>>>> return !ret;
>>>> }
>>>>
>>>> Note 'major = -1 && minor = -2' is sysfs_read's way of saying 'external'.
>>>>
>>>> This pretty much mimics what the kernel does in the ioctl handler for
>>>> GET_ARRAY_INFO:
>>>>
>>>> case GET_ARRAY_INFO:
>>>> if (!mddev->raid_disks && !mddev->external)
>>>> err = -ENODEV;
>>>> else
>>>> err = get_array_info(mddev, argp);
>>>> goto out;
>>>>
>>>> What do you think?
>>>
>>> I think that it accurately mimics what the current code does.
>>> I'm not sure that is what we really want.
>>> For testing in Incremental.c if an array is "active" we really
>>> should be testing more than "raid_disks != 0".
>>> We should be testing, as Shaohua suggested, if
>>> array_state != 'clear' or 'inactive'.
>>> You cannot get that info through the ioctl interface, so I suppose
>>> I decided the current test was 'close enough'.
>>> If we are going to stop supported kernels that don't have (e.g.)
>>> array_state, then we should really fo the right thing and test
>>> array_state.
>>
>> I think I got it right this time and pushed it into git. It made
>> things a lot prettier too IMHO :)
>>
>> In the process I also changed the behavior of
>> sysfs_read(GET_ARRAY_STATE) as I really didn't like how it was
>> copying in the string rather than parsing it.
>>
>> I am traveling at the moment and don't yet have my new raid test box
>> setup back at the office, so my testing is limited. If I broke
>> something badly, feel free to throw rotten tomatoes at me.
>>
>
> Hi Jes,
>
> Compilation with "-O2" flag fails:
>
> CXFLAGS=-O2 make
>
> cc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
> -DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
> -DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
> -DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
> -DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
> -DVERSION=\"4.0-85-g4435675\" -DVERS_DATE="\"2017-04-20\"" -DUSE_PTHREADS
> -DBINDIR=\"/sbin\" -c -o Query.o Query.c
>
> Query.c: In function ‘Query’:
> Query.c:92:9: error: ‘level’ may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> printf("%s: %s %s %d devices, %d spare%s. Use mdadm --detail for more
> detail.\n",
> ^
> Query.c:92:9: error: ‘spare_disks’ may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> Query.c:92:9: error: ‘raid_disks’ may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> cc1: all warnings being treated as errors
> make: *** [Query.o] Error 1
Fixed!
I do take patches ;)
Cheers,
Jes
^ permalink raw reply
* Re: GET_ARRAY_INFO assumptions?
From: Jes Sorensen @ 2017-04-21 16:13 UTC (permalink / raw)
To: NeilBrown, Shaohua Li; +Cc: linux-raid
In-Reply-To: <87k26esqac.fsf@notabene.neil.brown.name>
On 04/20/2017 05:49 PM, NeilBrown wrote:
> On Thu, Apr 20 2017, Jes Sorensen wrote:
>
>>
>> I think I got it right this time and pushed it into git. It made things
>> a lot prettier too IMHO :)
>>
>> In the process I also changed the behavior of
>> sysfs_read(GET_ARRAY_STATE) as I really didn't like how it was copying
>> in the string rather than parsing it.
>>
>> I am traveling at the moment and don't yet have my new raid test box
>> setup back at the office, so my testing is limited. If I broke something
>> badly, feel free to throw rotten tomatoes at me.
>>
>> Cheers,
>> Jes
>
> Looks good to me, except...
>
> /*
> * Beware map_name() uses strcmp() so active-idle must come before
> * active, to be detected correctly.
> */
>
> ???
> If map_name() used strncmp() you might need to be careful, but not with
> strcmp.
Hmmm I should know better than that! I did work on glibc back in the day
after all :(
> Also:
>
> int map_name(mapping_t *map, char *name)
> {
> while (map->name) {
> if (strcmp(map->name, name)==0)
> return map->num;
> map++;
> }
>
> return map->num;
> }
>
> Both returns do the same thing... so there should (could) just be one.
> is:
>
> while (map->name && strcmp(map->name, name) != 0)
> map++;
> return map->num;
>
> too terse??
Looks good to me - applied a patch for it.
> I do like that you could use map_name to parse the array_state file.
I actually had it done first with a large if list, but then discovered
maps.c and felt I had to change it :)
Cheers,
Jes
> Thanks,
> NeilBrown
>
^ permalink raw reply
* 15772 linux-raid
From: xa0ajutor @ 2017-04-22 4:24 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: 820.zip --]
[-- Type: application/zip, Size: 2362 bytes --]
^ permalink raw reply
* Recover array after I panicked
From: Patrik Dahlström @ 2017-04-23 9:47 UTC (permalink / raw)
To: linux-raid
Hello,
Here's the story:
I started with a 5x6 TB raid5 array. I added another 6 TB drive and
started to grow the array. However, one of my SATA cables were bad and
the reshape gave me lots of I/O errors.
Instead of fixing the SATA cable issue directly, I shutdown the server
and swapped places of 2 drives. My reasoning was that putting the new
drive in a good slot would reduce the I/O errors. Bad move, I know. I
tried a few commands but was not able to continue the reshape.
I then took out the server from the rack and replaced the SATA cable. No
more I/O errors, but at this point I am unable to recreate the array.
This is when I really started to panic. After multiple attempts at
rescuing the array, I tried running the Permute_array.pl script [1] with
some local modifications to additionally try different chunk sizes. So
far I've had no luck.
I don't remember what commands I have run.
I have the OS on a separate drive, i.e. /var/log and /etc is intact.
raid metadata version is 1.2.
Ubuntu 16.04.02 LTS
Kernel 4.4.0-72-generic
mdadm 3.3
Is there any help you can offer?
[1] https://raid.wiki.kernel.org/index.php/Permute_array.pl
^ permalink raw reply
* Re: Recover array after I panicked
From: Andreas Klauer @ 2017-04-23 10:16 UTC (permalink / raw)
To: Patrik Dahlström; +Cc: linux-raid
In-Reply-To: <3957da08-6ff4-3c15-e499-157244a767aa@powerlamerz.org>
On Sun, Apr 23, 2017 at 11:47:34AM +0200, Patrik Dahlström wrote:
> Is there any help you can offer?
Is there any mdadm --examine output?
What was on the array? Regular filesystem, unencrypted, or LVM, LUKS, ...?
If it's LUKS encrypted and you had RAID metadata at the end, yet
mdadm --create'd new metadata at the start, that would likely have
damaged your LUKS header beyond repair (and regular filesystems
don't like it, either).
If it's unencrypted data, as a last resort you can always go and find
the header of a large file of known type... for example if you find
a megapixel JPEG image and the first 512K of it are part of that then
your chunksize would be 512K and then you can go looking for the
next chunk on the other disks... and that should give you some notion
of the RAID layout and offset.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Recover array after I panicked
From: Patrik Dahlström @ 2017-04-23 10:23 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <20170423101639.GA4471@metamorpher.de>
On 04/23/2017 12:16 PM, Andreas Klauer wrote:
> On Sun, Apr 23, 2017 at 11:47:34AM +0200, Patrik Dahlström wrote:
>> Is there any help you can offer?
>
> Is there any mdadm --examine output?
At this point, it is incorrect. I've lost the output from the working
raid too, unless it's located in any log in /var/log/.
I have /etc/mdadm/mdadm.conf, but don't know if it's updated.
>
> What was on the array? Regular filesystem, unencrypted, or LVM, LUKS, ...?
Regular filesystem, unencrypted ext4.
>
> If it's LUKS encrypted and you had RAID metadata at the end, yet
> mdadm --create'd new metadata at the start, that would likely have
> damaged your LUKS header beyond repair (and regular filesystems
> don't like it, either).
No file system encryption.
>
> If it's unencrypted data, as a last resort you can always go and find
> the header of a large file of known type... for example if you find
> a megapixel JPEG image and the first 512K of it are part of that then
> your chunksize would be 512K and then you can go looking for the
> next chunk on the other disks... and that should give you some notion
> of the RAID layout and offset.
That's not a bad idea. Will hopefully narrow down my unknown variables.
>
> Regards
> Andreas Klauer
>
^ permalink raw reply
* Re: Recover array after I panicked
From: Andreas Klauer @ 2017-04-23 10:46 UTC (permalink / raw)
To: Patrik Dahlström; +Cc: linux-raid
In-Reply-To: <37269c2b-1788-a0b6-6d91-84c6b6bdd16c@powerlamerz.org>
On Sun, Apr 23, 2017 at 12:23:17PM +0200, Patrik Dahlström wrote:
> At this point, it is incorrect.
:-(
> I've lost the output from the working
> raid too, unless it's located in any log in /var/log/.
If you have kernel logs from before your accident...
check for stuff like this:
[ 7.328420] md: md6 stopped.
[ 7.329705] md/raid:md6: device sdb6 operational as raid disk 0
[ 7.329705] md/raid:md6: device sdg6 operational as raid disk 6
[ 7.329706] md/raid:md6: device sdh6 operational as raid disk 5
[ 7.329706] md/raid:md6: device sdf6 operational as raid disk 4
[ 7.329706] md/raid:md6: device sde6 operational as raid disk 3
[ 7.329707] md/raid:md6: device sdd6 operational as raid disk 2
[ 7.329707] md/raid:md6: device sdc6 operational as raid disk 1
[ 7.329924] md/raid:md6: raid level 5 active with 7 out of 7 devices, algorithm 2
[ 7.329936] md6: detected capacity change from 0 to 1500282617856
That's not everything but it's something.
Also in the future for experiments, go with overlays.
https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file
(and the overlay manipulation functions below that)
Lets you mess with mdadm --create stuff w/o actually overwriting original metadata.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Recover array after I panicked
From: Patrik Dahlström @ 2017-04-23 11:12 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <20170423104606.GA4603@metamorpher.de>
On 04/23/2017 12:46 PM, Andreas Klauer wrote:
> On Sun, Apr 23, 2017 at 12:23:17PM +0200, Patrik Dahlström wrote:
>> At this point, it is incorrect.
>
> :-(
>
>> I've lost the output from the working
>> raid too, unless it's located in any log in /var/log/.
>
> If you have kernel logs from before your accident...
> check for stuff like this:
>
> [ 7.328420] md: md6 stopped.
> [ 7.329705] md/raid:md6: device sdb6 operational as raid disk 0
> [ 7.329705] md/raid:md6: device sdg6 operational as raid disk 6
> [ 7.329706] md/raid:md6: device sdh6 operational as raid disk 5
> [ 7.329706] md/raid:md6: device sdf6 operational as raid disk 4
> [ 7.329706] md/raid:md6: device sde6 operational as raid disk 3
> [ 7.329707] md/raid:md6: device sdd6 operational as raid disk 2
> [ 7.329707] md/raid:md6: device sdc6 operational as raid disk 1
> [ 7.329924] md/raid:md6: raid level 5 active with 7 out of 7 devices, algorithm 2
> [ 7.329936] md6: detected capacity change from 0 to 1500282617856
>
> That's not everything but it's something.
I got some of that!
[ 3.100350] md/raid:md1: device sde operational as raid disk 4
[ 3.100350] md/raid:md1: device sdc operational as raid disk 3
[ 3.100350] md/raid:md1: device sdd operational as raid disk 2
[ 3.100351] md/raid:md1: device sda operational as raid disk 0
[ 3.100351] md/raid:md1: device sdb operational as raid disk 1
[ 3.100689] md/raid:md1: allocated 5432kB
[ 3.100699] md/raid:md1: raid level 5 active with 5 out of 5 devices,
algorithm 2
[ 3.100700] RAID conf printout:
[ 3.100700] --- level:5 rd:5 wd:5
[ 3.100700] disk 0, o:1, dev:sda
[ 3.100700] disk 1, o:1, dev:sdb
[ 3.100701] disk 2, o:1, dev:sdd
[ 3.100701] disk 3, o:1, dev:sdc
[ 3.100701] disk 4, o:1, dev:sde
[ 3.101006] created bitmap (44 pages) for device md1
[ 3.102245] md1: bitmap initialized from disk: read 3 pages, set 0 of
89423 bits
[ 3.159019] md1: detected capacity change from 0 to 24004163272704
At least I now know in what order that I should assemble my original 5
drives:
sda, sdb, sdd, sdc, sde
It would only be logical for the new drive (sdf) to be last in that list.
>
> Also in the future for experiments, go with overlays.
>
> https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file
> (and the overlay manipulation functions below that)
>
> Lets you mess with mdadm --create stuff w/o actually overwriting original metadata.
Will do
>
> Regards
> Andreas Klauer
>
^ permalink raw reply
* Re: Recover array after I panicked
From: Wols Lists @ 2017-04-23 11:36 UTC (permalink / raw)
To: Patrik Dahlström, Andreas Klauer; +Cc: linux-raid
In-Reply-To: <754209bb-9990-2a36-2233-d7d1273c8e37@powerlamerz.org>
On 23/04/17 12:12, Patrik Dahlström wrote:
> At least I now know in what order that I should assemble my original 5
> drives:
> sda, sdb, sdd, sdc, sde
> It would only be logical for the new drive (sdf) to be last in that list.
And, as the raid wiki tells you, download lspci and run that. That will
hopefully tell us a lot about what's left of the various headers on your
disks.
My worry is that Permute_Array will have tried a whole bunch of "mdadm
--create" variants and totally trashed your original headers.
Cheers,
Wol
^ permalink raw reply
* Re: Recover array after I panicked
From: Patrik Dahlström @ 2017-04-23 11:47 UTC (permalink / raw)
To: Wols Lists, Andreas Klauer; +Cc: linux-raid
In-Reply-To: <58FC91B8.5090603@youngman.org.uk>
On 04/23/2017 01:36 PM, Wols Lists wrote:
> On 23/04/17 12:12, Patrik Dahlström wrote:
>> At least I now know in what order that I should assemble my original 5
>> drives:
>> sda, sdb, sdd, sdc, sde
>> It would only be logical for the new drive (sdf) to be last in that list.
>
> And, as the raid wiki tells you, download lspci and run that. That will
> hopefully tell us a lot about what's left of the various headers on your
> disks.
I didn't find that part on the wiki. Here's the output of lspci:
00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers (rev 07)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6 (rev f1)
00:1c.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #7 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 03)
02:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 30)
03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
>
> My worry is that Permute_Array will have tried a whole bunch of "mdadm
> --create" variants and totally trashed your original headers.
This is most likely.
>
> Cheers,
> Wol
>
^ permalink raw reply
* Re: Recover array after I panicked
From: Reindl Harald @ 2017-04-23 11:53 UTC (permalink / raw)
To: Patrik Dahlström, Wols Lists, Andreas Klauer; +Cc: linux-raid
In-Reply-To: <69b83c56-4d88-bd6d-1189-02f9d231bb00@powerlamerz.org>
Am 23.04.2017 um 13:47 schrieb Patrik Dahlström:
>
>
> On 04/23/2017 01:36 PM, Wols Lists wrote:
>> On 23/04/17 12:12, Patrik Dahlström wrote:
>>> At least I now know in what order that I should assemble my original 5
>>> drives:
>>> sda, sdb, sdd, sdc, sde
>>> It would only be logical for the new drive (sdf) to be last in that list.
>>
>> And, as the raid wiki tells you, download lspci and run that. That will
>> hopefully tell us a lot about what's left of the various headers on your
>> disks.
> I didn't find that part on the wiki. Here's the output of lspci
"lspci" is surely nonsense but even "lsscsi" by looking at the
helpoutput hardly shows "various headers on your disks", so when someone
recommends a command and it's only useful with a defined set of
non-default params he should mention that clearly instead point to some
random command
> 00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers (rev 07)
> 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
> 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)
> 00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
> 00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31)
> 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #5 (rev f1)
> 00:1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6 (rev f1)
> 00:1c.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #7 (rev f1)
> 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
> 00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
> 00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
> 01:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 03)
> 02:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 30)
> 03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
> 04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
^ permalink raw reply
* Re: Recover array after I panicked
From: Roman Mamedov @ 2017-04-23 11:58 UTC (permalink / raw)
To: Wols Lists; +Cc: Patrik Dahlström, Andreas Klauer, linux-raid
In-Reply-To: <58FC91B8.5090603@youngman.org.uk>
On Sun, 23 Apr 2017 12:36:24 +0100
Wols Lists <antlists@youngman.org.uk> wrote:
> And, as the raid wiki tells you, download lspci and run that
Maybe you meant lsdrv. https://github.com/pturmel/lsdrv
--
With respect,
Roman
^ permalink raw reply
* Re: Recover array after I panicked
From: Wols Lists @ 2017-04-23 12:11 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Patrik Dahlström, Andreas Klauer, linux-raid
In-Reply-To: <20170423165810.75b5836e@natsu>
On 23/04/17 12:58, Roman Mamedov wrote:
> On Sun, 23 Apr 2017 12:36:24 +0100
> Wols Lists <antlists@youngman.org.uk> wrote:
>
>> And, as the raid wiki tells you, download lspci and run that
>
> Maybe you meant lsdrv. https://github.com/pturmel/lsdrv
>
Sorry, yes I did ... (too many ls_xxx commands :-)
Cheers,
Wol
^ permalink raw reply
* Re: Recover array after I panicked
From: Patrik Dahlström @ 2017-04-23 12:15 UTC (permalink / raw)
To: Wols Lists, Roman Mamedov; +Cc: Andreas Klauer, linux-raid
In-Reply-To: <58FC99ED.7080705@youngman.org.uk>
On 04/23/2017 02:11 PM, Wols Lists wrote:
> On 23/04/17 12:58, Roman Mamedov wrote:
>> On Sun, 23 Apr 2017 12:36:24 +0100
>> Wols Lists <antlists@youngman.org.uk> wrote:
>>
>>> And, as the raid wiki tells you, download lspci and run that
>>
>> Maybe you meant lsdrv. https://github.com/pturmel/lsdrv
>>
> Sorry, yes I did ... (too many ls_xxx commands :-)
Ok, I had to patch lsdrv a bit to make it run. Diff:
diff --git a/lsdrv b/lsdrv
index fe6e77d..e868dbc 100755
--- a/lsdrv
+++ b/lsdrv
@@ -386,7 +386,8 @@ def probe_block(blocklink):
peers = " (w/ %s)" % ",".join(peers)
else:
peers = ""
- blk.FS = "MD %s (%s/%s)%s %s" % (blk.array.md.LEVEL, blk.slave.slot, blk.array.md.raid_disks, peers, blk.slave.state)
+ if blk.array.md:
+ blk.FS = "MD %s (%s/%s)%s %s" % (blk.array.md.LEVEL, blk.slave.slot, blk.array.md.raid_disks, peers, blk.slave.state)
else:
blk.__dict__.update(extractvars(runx(['mdadm', '--export', '--examine', '/dev/block/'+blk.dev])))
blk.FS = "MD %s (%s) inactive" % (blk.MD_LEVEL, blk.MD_DEVICES)
@@ -402,9 +403,11 @@ def probe_block(blocklink):
else:
blk.FS = "Empty/Unknown"
if blk.ID_FS_LABEL:
- blk.FS += " '%s'" % blk.ID_FS_LABEL
+ if blk.FS:
+ blk.FS += " '%s'" % blk.ID_FS_LABEL
if blk.ID_FS_UUID:
- blk.FS += " {%s}" % blk.ID_FS_UUID
+ if blk.FS:
+ blk.FS += " {%s}" % blk.ID_FS_UUID
for part in blk.partitions:
probe_block(blkpath+'/'+part)
return blk
Here's the output of a run. Overlays are enabled:
PCI [ahci] 00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31)
├scsi 0:0:0:0 ATA WDC WD60EFRX-68M {WD-WX91D6535N7Y}
│└sda 5.46t [8:0] None
│ └dm-2 5.46t [252:2] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├scsi 1:0:0:0 ATA WDC WD600PF4PZ-4 {WD-WX11D741AE8K}
│└sdb 5.64t [8:16] None
│ └dm-5 5.64t [252:5] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├scsi 2:0:0:0 ATA WDC WD60EFRX-68M {WD-WX11DC449Y02}
│└sdc 5.46t [8:32] None
│ └dm-1 5.46t [252:1] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├scsi 3:0:0:0 ATA WDC WD60EFRX-68L {WD-WX11DA53427A}
│└sdd 5.46t [8:48] None
│ └dm-3 5.46t [252:3] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├scsi 4:0:0:0 ATA WDC WD60EFRX-68L {WD-WXB1HB4W238J}
│└sde 5.46t [8:64] None
│ └dm-4 5.46t [252:4] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
└scsi 5:0:0:0 ATA WDC WD60EFRX-68L {WD-WX41D75LN7CK}
└sdf 5.46t [8:80] None
└dm-6 5.46t [252:6] MD raid5 (6) inactive 'rack-server-1:1' {18cd5b54-707a-36df-36be-8f01e8a77122}
USB [usb-storage] Bus 001 Device 003: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge {77C301992933}
└scsi 6:0:0:0 WDC WD20 WD-WMC301992933 {WD-WMC301992933}
└sdg 1.82t [8:96] Partitioned (dos)
├sdg1 1.80t [8:97] ext4 {eb94342f-2eea-4318-9f79-3517ae1ccaad}
│└Mounted as /dev/sdg1 @ /
├sdg2 1.00k [8:98] Partitioned (dos)
└sdg5 15.93g [8:101] swap {568ea822-2f0c-42a8-a355-1a2e856728a0}
└dm-0 15.93g [252:0] swap {fac64c73-bb78-417d-9323-a5dd381178bf}
USB [usb-storage] Bus 001 Device 006: ID 0781:5567 SanDisk Corp. Cruzer Blade {2005224340054080F2CD}
└scsi 9:0:0:0 SanDisk Cruzer Blade {2005224340054080F2CD}
└sdh 3.73g [8:112] Partitioned (dos)
└sdh1 3.73g [8:113] vfat {6E17-F675}
└Mounted as /dev/sdh1 @ /media/cdrom
Other Block Devices
├loop0 5.86t [7:0] DM_snapshot_cow
│└dm-4 5.46t [252:4] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├loop1 5.86t [7:1] DM_snapshot_cow
│└dm-1 5.46t [252:1] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├loop2 5.86t [7:2] Empty/Unknown
│└dm-2 5.46t [252:2] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├loop3 5.86t [7:3] DM_snapshot_cow
│└dm-3 5.46t [252:3] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├loop4 5.86t [7:4] DM_snapshot_cow
│└dm-5 5.64t [252:5] MD raid5 (6) inactive 'rack-server-1:1' {510d9668-d30c-b4cd-cc76-9fcace98c3b1}
├loop5 5.86t [7:5] DM_snapshot_cow
│└dm-6 5.46t [252:6] MD raid5 (6) inactive 'rack-server-1:1' {18cd5b54-707a-36df-36be-8f01e8a77122}
├loop6 0.00k [7:6] Empty/Unknown
└loop7 0.00k [7:7] Empty/Unknown
Please note that the superblocks have probably been trashed by Permute arrays
>
> Cheers,
> Wol
>
^ permalink raw reply related
* Re: Recover array after I panicked
From: Patrik Dahlström @ 2017-04-23 12:32 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <37269c2b-1788-a0b6-6d91-84c6b6bdd16c@powerlamerz.org>
On 04/23/2017 12:23 PM, Patrik Dahlström wrote:
> On 04/23/2017 12:16 PM, Andreas Klauer wrote:
>> On Sun, Apr 23, 2017 at 11:47:34AM +0200, Patrik Dahlström wrote:
>>> Is there any help you can offer?
>>
>> Is there any mdadm --examine output?
> At this point, it is incorrect. I've lost the output from the working
> raid too, unless it's located in any log in /var/log/.
> I have /etc/mdadm/mdadm.conf, but don't know if it's updated.
>
>>
>> What was on the array? Regular filesystem, unencrypted, or LVM, LUKS, ...?
> Regular filesystem, unencrypted ext4.
>
>>
>> If it's LUKS encrypted and you had RAID metadata at the end, yet
>> mdadm --create'd new metadata at the start, that would likely have
>> damaged your LUKS header beyond repair (and regular filesystems
>> don't like it, either).
> No file system encryption.
>
>>
>> If it's unencrypted data, as a last resort you can always go and find
>> the header of a large file of known type... for example if you find
>> a megapixel JPEG image and the first 512K of it are part of that then
>> your chunksize would be 512K and then you can go looking for the
>> next chunk on the other disks... and that should give you some notion
>> of the RAID layout and offset.
> That's not a bad idea. Will hopefully narrow down my unknown variables.
Okay, I extracted parts of an mkv file and this is what I found out:
* playing 512 kb of data is OK
* playing 1024 kb of data will give me the following error (from mpv):
[mkv] Invalid EBML length at position 539473
[mkv] Corrupt file detected. Trying to resync starting from position
539473...
"position 539473" is at ~527 kb, which leads me to suspect that the
correct chunk size is 512 kb.
Any thoughts?
>
>>
>> Regards
>> Andreas Klauer
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox