* Re: performance issue (was: Re: kernel: BUG: soft lockup - CPU#1 stuck for 60s!)
From: Rainer Fügenstein @ 2015-10-25 19:23 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Neil Brown, Linux-RAID
In-Reply-To: <20151024213139.5b20dec6@natsu>
Hello Roman,
Saturday, October 24, 2015, 6:31:39 PM, you wrote:
> Use a higher bitmap-chunk size, such as 256M or more.
I guess that would be
mdadm --grow /dev/md0 --bitmap-chunk=256M ??
is it wise to issue this command during a re-sync?
a cron.weekly job started the re-sync (although I'm pretty sure this
job has been disabled quite some time ago)
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb1[7] sdf1[3] sdc1[5] sde1[0] sdd1[8]
11721061376 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[==>..................] resync = 11.9% (348948608/2930265344) finish=7771.1min speed=5533K/sec
bitmap: 8/350 pages [32KB], 4096KB chunk
unused devices: <none>
tnx & cu
--
Best regards,
Rainer mailto:rfu@oudeis.org
^ permalink raw reply
* Re: How to recover after md crash during reshape?
From: andras @ 2015-10-25 14:15 UTC (permalink / raw)
To: Phil Turmel; +Cc: Linux-RAID
In-Reply-To: <562660EE.9020504@turmel.org>
Phil,
Thanks for all the help. I finally have some progress (and new
problems).
> Now to your big array. It is vital that it also be cleaned of UREs
> after re-creation before you do anything else. Which means it must
> *not* be created degraded (the redundancy is needed to fix UREs).
>
> According to lsdrv and your "mdadm -E" reports, the creation order you
> need is:
>
> raid device 0 /dev/sdf2 {WD-WMAZA0209553}
> raid device 1 /dev/sdd2 {WD-WMAZA0348342}
> raid device 2 /dev/sdg1 {9VS1EFFD}
> raid device 3 /dev/sde1 {5XW05FFV}
> raid device 4 /dev/sdc1 {6XW0BQL0}
> raid device 5 /dev/sdh1 {ML2220F30TEBLE}
> raid device 6 /dev/sdi2 {WD-WMAY01975001}
>
> Chunk size is 64k.
>
> Make sure your partially assembled array is stopped:
>
> mdadm --stop /dev/md1
>
> Re-create your array as follows:
>
> mdadm --create --assume-clean --verbose \
> --metadata=1.0 --raid-devices=7 --chunk=64 --level=6 \
> /dev/md1 /dev/sd{f2,d2,g1,e1,c1,h1,i2}
Being very paranoid at this stage, instead of trying to re-create the
array on the original drives, I dd-ed their content to a different set
of (bigger) drives, and issued the command on them.
The array assembled fine:
md1 : active raid6 sdc2[6] sdd1[5] sdg1[4] sdb1[3] sdf1[2] sdh2[1]
sda2[0]
7325679040 blocks super 1.0 level 6, 64k chunk, algorithm 2 [7/7]
[UUUUUUU]
bitmap: 0/11 pages [0KB], 65536KB chunk
> Use "fsck -n" to check your array's filesystem (expect some damage at
> the very begining). If it look reasonable, use fsck to fix any damage.
fsck -n run to completion but reported a ton of errors, mostly stemming
from the initial (ext4) superblock being damaged.
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_check_desc: Corrupt group descriptor: bad block for block
bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal
anyway.
Clear journal? no
The filesystem size (according to the superblock) is 1831419920
blocks
The physical size of the device is 1831419760 blocks
Either the superblock or the partition table is likely to be
corrupt!
Abort? no
data contains a file system with errors, check forced.
Resize inode not valid. Recreate? no
Pass 1: Checking inodes, blocks, and sizes
Inode 7 has illegal block(s). Clear? no
Illegal block #448536 (4285956422) in inode 7. IGNORED.
Illegal block #448537 (4292313414) in inode 7. IGNORED.
Illegal block #448538 (3675619654) in inode 7. IGNORED.
Illegal block #448539 (3686760774) in inode 7. IGNORED.
Illegal block #448541 (1880654150) in inode 7. IGNORED.
Illegal block #448542 (3636035910) in inode 7. IGNORED.
Illegal block #448543 (2516877638) in inode 7. IGNORED.
Illegal block #448544 (2920513862) in inode 7. IGNORED.
Illegal block #449560 (4285956537) in inode 7. IGNORED.
Illegal block #449561 (4292313529) in inode 7. IGNORED.
Illegal block #449562 (3675619769) in inode 7. IGNORED.
Too many illegal blocks in inode 7.
Clear inode? no
Suppress messages? no
...
and so on...
So I issued the real fsck command. It interestingly reported a
completely different set of issues, my guess is that after fixing the
superblock, the inconsistencies that fsck -n was talking about went way,
and the real ones started to show up. At any rate, now the file system
seems to be clean, expect for this message:
The filesystem size (according to the superblock) is 1831419920
blocks
The physical size of the device is 1831419760 blocks
Either the superblock or the partition table is likely to be
corrupt!
This problem prevents me from mounting the FS:
mount -o ro /dev/md1 /mnt -v
mount: wrong fs type, bad option, bad superblock on /dev/md1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
And dmesg reports:
[ 5859.527778] EXT4-fs (md1): bad geometry: block count 1831419920
exceeds size of device (1831419760 blocks)
So here I am right now. I can see a few paths forward, but first a
question:
Why is it that the re-created MD device is different in size (ever so
slightly) then the ext4 filesystem that it used to contain? I doubt it
has anything to do with the grow operation as I didn't get far enough to
actually resize the filesystem...
One side-effect of using different drives (and dd) is that the partition
table is now misaligned with the new disk geometry. For example:
fdisk -l /dev/sdb
Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x3e6b39b9
Device Boot Start End Sectors Size Id Type
/dev/sdb1 63 2930272064 2930272002 1.4T fd Linux raid
autodetect
Partition 2 does not start on physical sector boundary.
Could this be the route cause?
Here's the sizes of all the other relevant partitions:
/dev/sda2 976752064 3907029167 2930277104 1.4T fd Linux raid
autodetect
/dev/sdb1 63 2930272064 2930272002 1.4T fd Linux raid
autodetect
/dev/sdc2 976752064 3907029167 2930277104 1.4T fd Linux raid
autodetect
/dev/sdd1 63 3907024064 3907024002 1.8T fd Linux raid
autodetect
/dev/sdf1 63 2930272064 2930272002 1.4T fd Linux raid
autodetect
/dev/sdg1 63 2930272064 2930272002 1.4T fd Linux raid
autodetect
/dev/sdh2 976752064 3907029167 2930277104 1.4T fd Linux raid
autodetect
If I look at the size reported by fdisk above, on a 7-disk raid6, with
each partition of that size, I should have 1831420000 sectors available.
I'm sure mdadm takes some sectors for management, but I don't know how
much?
So, I thought of three ways of fixing it:
1. Re-create the array again, but this time force the array size to the
one reported by the filesystem, using -size. What is the unit for -size?
Is that bytes?
2. Re-create the array again, but this time use the original
super-blocks version (0.91 I think). Could that make a difference in the
size of the array?
3. Instead of DD-ing whole drives, dd just the raid6 partitions so the
partition table is correct for the drives. Maybe the misalignment trips
mdadm off and makes it to create the array in the incorrect size?
Thanks for all the help again,
Andras
^ permalink raw reply
* Fwd: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
From: Xiao Ni @ 2015-10-25 5:38 UTC (permalink / raw)
To: Neil Brown; +Cc: Jes Sorensen, linux-raid
In-Reply-To: <1445751362-15677-1-git-send-email-xni@redhat.com>
Hi Neil
I encountered one problem. When reshape one raid1 with bitmap to raid0, it'll
lose legs.
I sent the patch by git-send-email, but I can't see the mail in linux-raid. So
I forward it again. And add signed-off-by line.
Best Regards
Xiao
----- Forwarded Message -----
From: "Xiao Ni" <xni@redhat.com>
To: xni@redhat.com
Sent: Sunday, October 25, 2015 1:36:02 PM
Subject: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
One raid1 with bitmap is composed by 4 disks. It'll fail when rashape to raid0
and lose 3 disks. It should check bitmap first when reshape raid1 to raid0.
Signed-off-by: Xiao Ni <xni@redhat.com>
---
Grow.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Grow.c b/Grow.c
index 80d7b22..5e9b0bb 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1898,6 +1898,12 @@ size_change_error:
array.layout == ((1 << 8) + 2) && !(array.raid_disks & 1)) ||
(s->level == 0 && array.level == 1 && sra)) {
int err;
+
+ if (array.state & (1<<MD_SB_BITMAP_PRESENT)) {
+ cont_err("Bitmap must be removed before level can be changed\n");
+ rv = 1;
+ goto release;
+ }
err = remove_disks_for_takeover(st, sra, array.layout);
if (err) {
dprintf("Array cannot be reshaped\n");
@@ -2706,9 +2712,6 @@ static int impose_level(int fd, int level, char *devname, int verbose)
err = errno;
pr_err("%s: could not set level to %s\n",
devname, c);
- if (err == EBUSY &&
- (array.state & (1<<MD_SB_BITMAP_PRESENT)))
- cont_err("Bitmap must be removed before level can be changed\n");
return err;
}
if (verbose >= 0)
--
1.8.3.1
^ permalink raw reply related
* 2nd Faulty drive while rebuilding array on RAID5
From: Guillaume ALLEE @ 2015-10-24 22:27 UTC (permalink / raw)
To: linux-raid
Hi all,
Context:
On my RAID5 sdc was faulty. I bought a new HD, format it and add it to
my raid array. However during the rebuilding sda was detected as
faulty. Now I am not sure what to do...
I followed the steps from the wiki. See at the end my question ;-)
Thanks for your help.
$ uname -a
Linux htpc 3.8.0-35-generic #52~precise1-Ubuntu SMP Thu Jan 30
17:27:28 UTC 2014 i686 i686 i386 GNU/Linux
$ mdadm --version
mdadm - v3.2.5 - 18th May 2012
$ sudo mdadm --detail /dev/md1
/dev/md1:
Version : 0.90
Creation Time : Sun Jan 2 08:47:01 2011
Raid Level : raid5
Array Size : 5842101312 (5571.46 GiB 5982.31 GB)
Used Dev Size : 1947367104 (1857.15 GiB 1994.10 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sat Oct 24 23:36:30 2015
State : clean, FAILED
Active Devices : 2
Working Devices : 3
Failed Devices : 1
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
UUID : 426d71a2:5b25a168:a4e2eff2:d305f1c1
Events : 0.20213
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 19 1 active sync /dev/sdb3
2 0 0 2 removed
3 8 51 3 active sync /dev/sdd3
4 8 35 - spare /dev/sdc3
5 8 3 - faulty spare /dev/sda3
$ mdadm --examine /dev/sd[abcdefghijklmn]3 >> raid.status
http://pastebin.com/qaP8bvna
$ sudo mdadm --examine /dev/sd[a-z] | egrep 'Event|/dev/sd'
/dev/sda:
/dev/sdb:
/dev/sdc:
/dev/sdd:
/dev/sde:
I seems that some blocks of sda are not readable.Cf from dmesg
"[17852.126321] end_request: I/O error, dev sda, sector 1958539264"
Full dmesg available at:
http://pastebin.com/bBfcYjkg
Is there some way to re-add this disk (sda) in the array without mdadm
thinging it is a new one ?
I have seen from the wiki that I could try to recreate the array with
--assume-clean but I want to do that only in last resort.
Thanks,
Guillaume
^ permalink raw reply
* mdadm format for manual destriping
From: Marek @ 2015-10-24 19:28 UTC (permalink / raw)
To: Linux-RAID
Hi,
is there a documentation available on how mdadm stores data? E.g.
1. super-block
2. offset of first block on each drive
3. whether mdadm stores blocks as raw data or stores some kind of
metadata associated with each block e.g. disk 1 -> data_block1
immidiatelly followed by data_block 5 or
metadata_for_block_1 | data_block 1 | metadata_for_block_5 | data_block 5 |
4. how and where mdadm stores its backup superblock
5. what klind of XOR algorithm is used by mdadm
thanks,
Marek
^ permalink raw reply
* Re: performance issue (was: Re: kernel: BUG: soft lockup - CPU#1 stuck for 60s!)
From: Roman Mamedov @ 2015-10-24 16:31 UTC (permalink / raw)
To: Rainer Fügenstein; +Cc: Neil Brown, Linux-RAID
In-Reply-To: <43246687.20151024181541@oudeis.org>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On Sat, 24 Oct 2015 18:15:41 +0200
Rainer Fügenstein <rfu@oudeis.org> wrote:
> hi,
>
> > I strongly recommend adding a write-intend bitmap
> > mdadm --grow /dev/md0 --bitmap=internal
>
> I did as suggested, but now it feels like performance has dropped to
> about 1/4th of what it used to be before. since this system is already
> pretty slow by design, this is quite frustrating.
Use a higher bitmap-chunk size, such as 256M or more.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* performance issue (was: Re: kernel: BUG: soft lockup - CPU#1 stuck for 60s!)
From: Rainer Fügenstein @ 2015-10-24 16:15 UTC (permalink / raw)
To: Neil Brown, Linux-RAID
In-Reply-To: <87si5bvcj4.fsf@notabene.neil.brown.name>
hi,
> I strongly recommend adding a write-intend bitmap
> mdadm --grow /dev/md0 --bitmap=internal
I did as suggested, but now it feels like performance has dropped to
about 1/4th of what it used to be before. since this system is already
pretty slow by design, this is quite frustrating.
no soft-lockups so far, fortunately.
may a new kernel speed things up again? or can --bitmap=internal be
undone?
(need some time to prepare the upgrade to a new OS release)
tnx & cu
--
Best regards,
Rainer mailto:rfu@oudeis.org
^ permalink raw reply
* Re: [PATCH 0/2] raid1/10: Handle write errors correctly in narrow_write_error()
From: Neil Brown @ 2015-10-24 5:31 UTC (permalink / raw)
To: Jes Sorensen, Nate Dailey; +Cc: linux-raid, William.Kuzeja, xni
In-Reply-To: <wrfjoafpcvjs.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]
Jes Sorensen <Jes.Sorensen@redhat.com> writes:
> Nate Dailey <nate.dailey@stratus.com> writes:
>> Thank you!
>>
>> I confirmed that this patch prevents the bug.
>>
>> Nate
>
> Awesome, thanks Nate!
>
> Neil once you commit the final version of this patch, please let me
> know.
>
> Cheers,
> Jes
>
>>
>>
>>
>> On 10/22/2015 08:09 PM, Neil Brown wrote:
>>> Nate Dailey <nate.dailey@stratus.com> writes:
>>>
>>>> The problem is that we aren't getting true write (medium) errors.
>>>>
>>>> In this case we're testing device removals. The write errors happen
>>>> because the
>>>> disk goes away. Narrow_write_error returns 1, the bitmap bit is cleared, and
>>>> then when the device is re-added the resync might not include the sectors in
>>>> that chunk (there's some luck involved; if other writes to that chunk happen
>>>> while the disk is removed, we're okay--bug is easier to hit with
>>>> smaller bitmap
>>>> chunks because of this).
>>>>
>>>>
>>> OK, that makes sense.
>>>
>>> The device removal will be noticed when the bad block log is written
>>> out.
>>> When a bad-block is recorded we make sure to write that out promptly
>>> before bio_endio() gets called. But not before close_write() has called
>>> bitmap_end_write().
>>>
>>> So I guess we need to delay the close_write() call until the
>>> bad-block-log has been written.
>>>
>>> I think this patch should do it. Can you test?
>>>
>>> Thanks,
>>> NeilBrown
>>>
>>> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
>>> index c1ad0b075807..1a1c5160c930 100644
>>> --- a/drivers/md/raid1.c
>>> +++ b/drivers/md/raid1.c
>>> @@ -2269,8 +2269,6 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
>>> rdev_dec_pending(conf->mirrors[m].rdev,
>>> conf->mddev);
>>> }
>>> - if (test_bit(R1BIO_WriteError, &r1_bio->state))
>>> - close_write(r1_bio);
>>> if (fail) {
>>> spin_lock_irq(&conf->device_lock);
>>> list_add(&r1_bio->retry_list, &conf->bio_end_io_list);
>>> @@ -2396,6 +2394,9 @@ static void raid1d(struct md_thread *thread)
>>> r1_bio = list_first_entry(&tmp, struct r1bio,
>>> retry_list);
>>> list_del(&r1_bio->retry_list);
>>> + if (mddev->degraded)
>>> + set_bit(R1BIO_Degraded, &r1_bio->state);
>>> + close_write(r1_bio);
>>> raid_end_bio_io(r1_bio);
>>> }
>>> }
I've just pushed out a version (for raid10 as well) in my 'for-linus'
branch. I'll submit to Linus later today after zero-day comes back with
no errors.
This version contains some extra code which is not needed, but makes the
change more obviously correct.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: Fwd: manually destriping a 4 drive raid5 with one missing drive
From: Dragan Milivojević @ 2015-10-23 21:30 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <CA+sqOsYVGyCVKoRYAvgsL57tHhZn6+RaLK_7bzrUHvVK2XUNPA@mail.gmail.com>
On Fri, Oct 23, 2015 at 10:46 PM, Marek <mlf.conv@gmail.com> wrote:
> dd from mdX doesn't work i tried it even with testdisk, what you get
> is mixed up data, incomplete files.
As far as dd is concerned /dev/mdX is just another block device so it works
as expected.
^ permalink raw reply
* Re: Fwd: manually destriping a 4 drive raid5 with one missing drive
From: Marek @ 2015-10-23 20:46 UTC (permalink / raw)
To: Phil Turmel; +Cc: Linux-RAID
In-Reply-To: <562A7333.9010702@turmel.org>
dd from mdX doesn't work i tried it even with testdisk, what you get
is mixed up data, incomplete files.
{ Google mail on iPad doesn't support plain text, who knew :/ }
On Fri, Oct 23, 2015 at 7:49 PM, Phil Turmel <philip@turmel.org> wrote:
> On 10/23/2015 12:20 PM, Marek wrote:
>> Not sure if it's destrip or destripe but it's basically like puzzle
>> you take a block from each drive according to the layout you are using
>> e.g. Left symmetric and then write it down in that order computing
>> missing blocks from parity blocks - this way you would write an image
>> which you can mount without using mdadm. Data restoration companies
>> are using this technique.
>
> No special tool required. Obtain a new drive big enough to hold your
> entire array and 'dd' from /dev/mdX to your new drive.
>
> { BTW: convention on kernel.org is to reply-to-all, trim unnecessary
> context, and either bottom post or interleave your reply. }
>
> Phil
^ permalink raw reply
* Re: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
From: Jes Sorensen @ 2015-10-23 20:35 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid
In-Reply-To: <1445589144-12157-1-git-send-email-xni@redhat.com>
Xiao Ni <xni@redhat.com> writes:
> One raid1 with bitmap is composed by 4 disks. It'll fail when rashape to raid0
> and lose 3 disks. It should check bitmap first when reshape raid1 to raid0.
> ---
> Grow.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Xiao,
I believe you are also required to apply a Signed-off-by: line when
posting patches against mdadm.
Cheers,
Jes
>
> diff --git a/Grow.c b/Grow.c
> index 80d7b22..5e9b0bb 100644
> --- a/Grow.c
> +++ b/Grow.c
> @@ -1898,6 +1898,12 @@ size_change_error:
> array.layout == ((1 << 8) + 2) && !(array.raid_disks & 1)) ||
> (s->level == 0 && array.level == 1 && sra)) {
> int err;
> +
> + if (array.state & (1<<MD_SB_BITMAP_PRESENT)) {
> + cont_err("Bitmap must be removed before level can be changed\n");
> + rv = 1;
> + goto release;
> + }
> err = remove_disks_for_takeover(st, sra, array.layout);
> if (err) {
> dprintf("Array cannot be reshaped\n");
> @@ -2706,9 +2712,6 @@ static int impose_level(int fd, int level, char *devname, int verbose)
> err = errno;
> pr_err("%s: could not set level to %s\n",
> devname, c);
> - if (err == EBUSY &&
> - (array.state & (1<<MD_SB_BITMAP_PRESENT)))
> - cont_err("Bitmap must be removed before level can be changed\n");
> return err;
> }
> if (verbose >= 0)
^ permalink raw reply
* Re: [PATCH v2 01/12] block: Move integrity kobject to struct gendisk
From: Jeff Moyer @ 2015-10-23 20:21 UTC (permalink / raw)
To: Dan Williams
Cc: martin.petersen, linux-raid, linux-nvdimm, Sagi Grimberg, axboe,
dm-devel, linux-nvme, hch
In-Reply-To: <20151015195945.20721.41097.stgit@dwillia2-desk3.jf.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> From: Martin K. Petersen <martin.petersen@oracle.com>
>
> The integrity kobject purely exists to support the integrity
> subdirectory in sysfs and doesn't really have anything to do with the
> blk_integrity data structure. Move the kobject to struct gendisk where
> it belongs.
>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
> Reported-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
> Tested-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
> ---
> block/blk-integrity.c | 22 +++++++++++-----------
> include/linux/blkdev.h | 2 --
> include/linux/genhd.h | 1 +
> 3 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/block/blk-integrity.c b/block/blk-integrity.c
> index 75f29cf70188..182bfd2383ea 100644
> --- a/block/blk-integrity.c
> +++ b/block/blk-integrity.c
> @@ -249,8 +249,8 @@ struct integrity_sysfs_entry {
> static ssize_t integrity_attr_show(struct kobject *kobj, struct attribute *attr,
> char *page)
> {
> - struct blk_integrity *bi =
> - container_of(kobj, struct blk_integrity, kobj);
> + struct gendisk *disk = container_of(kobj, struct gendisk, integrity_kobj);
> + struct blk_integrity *bi = blk_get_integrity(disk);
> struct integrity_sysfs_entry *entry =
> container_of(attr, struct integrity_sysfs_entry, attr);
>
> @@ -261,8 +261,8 @@ static ssize_t integrity_attr_store(struct kobject *kobj,
> struct attribute *attr, const char *page,
> size_t count)
> {
> - struct blk_integrity *bi =
> - container_of(kobj, struct blk_integrity, kobj);
> + struct gendisk *disk = container_of(kobj, struct gendisk, integrity_kobj);
> + struct blk_integrity *bi = blk_get_integrity(disk);
> struct integrity_sysfs_entry *entry =
> container_of(attr, struct integrity_sysfs_entry, attr);
> ssize_t ret = 0;
> @@ -385,8 +385,8 @@ subsys_initcall(blk_dev_integrity_init);
>
> static void blk_integrity_release(struct kobject *kobj)
> {
> - struct blk_integrity *bi =
> - container_of(kobj, struct blk_integrity, kobj);
> + struct gendisk *disk = container_of(kobj, struct gendisk, integrity_kobj);
> + struct blk_integrity *bi = blk_get_integrity(disk);
>
> kmem_cache_free(integrity_cachep, bi);
> }
> @@ -429,14 +429,14 @@ int blk_integrity_register(struct gendisk *disk, struct blk_integrity *template)
> if (!bi)
> return -1;
>
> - if (kobject_init_and_add(&bi->kobj, &integrity_ktype,
> + if (kobject_init_and_add(&disk->integrity_kobj, &integrity_ktype,
> &disk_to_dev(disk)->kobj,
> "%s", "integrity")) {
> kmem_cache_free(integrity_cachep, bi);
> return -1;
> }
>
> - kobject_uevent(&bi->kobj, KOBJ_ADD);
> + kobject_uevent(&disk->integrity_kobj, KOBJ_ADD);
>
> bi->flags |= BLK_INTEGRITY_VERIFY | BLK_INTEGRITY_GENERATE;
> bi->interval = queue_logical_block_size(disk->queue);
> @@ -479,9 +479,9 @@ void blk_integrity_unregister(struct gendisk *disk)
>
> bi = disk->integrity;
>
> - kobject_uevent(&bi->kobj, KOBJ_REMOVE);
> - kobject_del(&bi->kobj);
> - kobject_put(&bi->kobj);
> + kobject_uevent(&disk->integrity_kobj, KOBJ_REMOVE);
> + kobject_del(&disk->integrity_kobj);
> + kobject_put(&disk->integrity_kobj);
> disk->integrity = NULL;
> }
> EXPORT_SYMBOL(blk_integrity_unregister);
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 19c2e947d4d1..830f9c07d4bb 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1472,8 +1472,6 @@ struct blk_integrity {
> unsigned short tag_size;
>
> const char *name;
> -
> - struct kobject kobj;
> };
>
> extern bool blk_integrity_is_initialized(struct gendisk *);
> diff --git a/include/linux/genhd.h b/include/linux/genhd.h
> index 2adbfa6d02bc..9e6e0dfa97ad 100644
> --- a/include/linux/genhd.h
> +++ b/include/linux/genhd.h
> @@ -199,6 +199,7 @@ struct gendisk {
> struct disk_events *ev;
> #ifdef CONFIG_BLK_DEV_INTEGRITY
> struct blk_integrity *integrity;
> + struct kobject integrity_kobj;
> #endif
> int node_id;
> };
>
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH 0/2] raid1/10: Handle write errors correctly in narrow_write_error()
From: Jes Sorensen @ 2015-10-23 18:02 UTC (permalink / raw)
To: Nate Dailey; +Cc: Neil Brown, linux-raid, William.Kuzeja, xni
In-Reply-To: <562A4475.1000904@stratus.com>
Nate Dailey <nate.dailey@stratus.com> writes:
> Thank you!
>
> I confirmed that this patch prevents the bug.
>
> Nate
Awesome, thanks Nate!
Neil once you commit the final version of this patch, please let me
know.
Cheers,
Jes
>
>
>
> On 10/22/2015 08:09 PM, Neil Brown wrote:
>> Nate Dailey <nate.dailey@stratus.com> writes:
>>
>>> The problem is that we aren't getting true write (medium) errors.
>>>
>>> In this case we're testing device removals. The write errors happen
>>> because the
>>> disk goes away. Narrow_write_error returns 1, the bitmap bit is cleared, and
>>> then when the device is re-added the resync might not include the sectors in
>>> that chunk (there's some luck involved; if other writes to that chunk happen
>>> while the disk is removed, we're okay--bug is easier to hit with
>>> smaller bitmap
>>> chunks because of this).
>>>
>>>
>> OK, that makes sense.
>>
>> The device removal will be noticed when the bad block log is written
>> out.
>> When a bad-block is recorded we make sure to write that out promptly
>> before bio_endio() gets called. But not before close_write() has called
>> bitmap_end_write().
>>
>> So I guess we need to delay the close_write() call until the
>> bad-block-log has been written.
>>
>> I think this patch should do it. Can you test?
>>
>> Thanks,
>> NeilBrown
>>
>> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
>> index c1ad0b075807..1a1c5160c930 100644
>> --- a/drivers/md/raid1.c
>> +++ b/drivers/md/raid1.c
>> @@ -2269,8 +2269,6 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
>> rdev_dec_pending(conf->mirrors[m].rdev,
>> conf->mddev);
>> }
>> - if (test_bit(R1BIO_WriteError, &r1_bio->state))
>> - close_write(r1_bio);
>> if (fail) {
>> spin_lock_irq(&conf->device_lock);
>> list_add(&r1_bio->retry_list, &conf->bio_end_io_list);
>> @@ -2396,6 +2394,9 @@ static void raid1d(struct md_thread *thread)
>> r1_bio = list_first_entry(&tmp, struct r1bio,
>> retry_list);
>> list_del(&r1_bio->retry_list);
>> + if (mddev->degraded)
>> + set_bit(R1BIO_Degraded, &r1_bio->state);
>> + close_write(r1_bio);
>> raid_end_bio_io(r1_bio);
>> }
>> }
^ permalink raw reply
* Re: Fwd: manually destriping a 4 drive raid5 with one missing drive
From: Phil Turmel @ 2015-10-23 17:49 UTC (permalink / raw)
To: Marek, Linux-RAID
In-Reply-To: <CA+sqOsY1Q4e3vNy4rmqjndsOStSGOg4JpqWBm4TTEvRdOmTkbQ@mail.gmail.com>
On 10/23/2015 12:20 PM, Marek wrote:
> Not sure if it's destrip or destripe but it's basically like puzzle
> you take a block from each drive according to the layout you are using
> e.g. Left symmetric and then write it down in that order computing
> missing blocks from parity blocks - this way you would write an image
> which you can mount without using mdadm. Data restoration companies
> are using this technique.
No special tool required. Obtain a new drive big enough to hold your
entire array and 'dd' from /dev/mdX to your new drive.
{ BTW: convention on kernel.org is to reply-to-all, trim unnecessary
context, and either bottom post or interleave your reply. }
Phil
^ permalink raw reply
* Fwd: manually destriping a 4 drive raid5 with one missing drive
From: Marek @ 2015-10-23 16:20 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <CA+sqOsYBbOwn5tJfygAR0MDCQPpd4w61XPGBLv8Mme8cT_HL8A@mail.gmail.com>
Not sure if it's destrip or destripe but it's basically like puzzle
you take a block from each drive according to the layout you are using
e.g. Left symmetric and then write it down in that order computing
missing blocks from parity blocks - this way you would write an image
which you can mount without using mdadm. Data restoration companies
are using this technique.
On Friday, October 23, 2015, Piergiorgio Sartor
<piergiorgio.sartor@nexgo.de> wrote:
>
> On Fri, Oct 23, 2015 at 11:26:12AM +0200, Marek wrote:
> > I have a 4 2TB disk raid5 512k 1.2.
> > one of the drives was accidentally wiped by ubuntu installation
> > (/dev/sda, first drive). The system has been rebooted forcefully
> > several times before this happened. Raid wouldn't come up after that.
> > The first drive has been -add ed back and a resync has been enforced.
> > What i'd like to do is to manually destrip the raid.
>
> Hi Marek,
>
> excuse my ignorance, but what does it mean "destrip" a RAID?
>
> Could you please point to some technical reference or, maybe,
> spend few more words to clarify the concept?
>
> Thanks,
>
> bye,
>
> --
>
> piergiorgio
^ permalink raw reply
* Re: manually destriping a 4 drive raid5 with one missing drive
From: Piergiorgio Sartor @ 2015-10-23 15:53 UTC (permalink / raw)
To: Marek; +Cc: Linux-RAID
In-Reply-To: <CA+sqOsZfjz0wTei+6qiv+zxXt7TA_GMO8EQ=v0EeDGFpqLrWRg@mail.gmail.com>
On Fri, Oct 23, 2015 at 11:26:12AM +0200, Marek wrote:
> I have a 4 2TB disk raid5 512k 1.2.
> one of the drives was accidentally wiped by ubuntu installation
> (/dev/sda, first drive). The system has been rebooted forcefully
> several times before this happened. Raid wouldn't come up after that.
> The first drive has been -add ed back and a resync has been enforced.
> What i'd like to do is to manually destrip the raid.
Hi Marek,
excuse my ignorance, but what does it mean "destrip" a RAID?
Could you please point to some technical reference or, maybe,
spend few more words to clarify the concept?
Thanks,
bye,
--
piergiorgio
^ permalink raw reply
* Re: [PATCH 0/2] raid1/10: Handle write errors correctly in narrow_write_error()
From: Nate Dailey @ 2015-10-23 14:30 UTC (permalink / raw)
To: Neil Brown, Jes Sorensen; +Cc: linux-raid, William.Kuzeja, xni
In-Reply-To: <87d1w6zbrv.fsf@notabene.neil.brown.name>
Thank you!
I confirmed that this patch prevents the bug.
Nate
On 10/22/2015 08:09 PM, Neil Brown wrote:
> Nate Dailey <nate.dailey@stratus.com> writes:
>
>> The problem is that we aren't getting true write (medium) errors.
>>
>> In this case we're testing device removals. The write errors happen because the
>> disk goes away. Narrow_write_error returns 1, the bitmap bit is cleared, and
>> then when the device is re-added the resync might not include the sectors in
>> that chunk (there's some luck involved; if other writes to that chunk happen
>> while the disk is removed, we're okay--bug is easier to hit with smaller bitmap
>> chunks because of this).
>>
>>
> OK, that makes sense.
>
> The device removal will be noticed when the bad block log is written
> out.
> When a bad-block is recorded we make sure to write that out promptly
> before bio_endio() gets called. But not before close_write() has called
> bitmap_end_write().
>
> So I guess we need to delay the close_write() call until the
> bad-block-log has been written.
>
> I think this patch should do it. Can you test?
>
> Thanks,
> NeilBrown
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index c1ad0b075807..1a1c5160c930 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -2269,8 +2269,6 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
> rdev_dec_pending(conf->mirrors[m].rdev,
> conf->mddev);
> }
> - if (test_bit(R1BIO_WriteError, &r1_bio->state))
> - close_write(r1_bio);
> if (fail) {
> spin_lock_irq(&conf->device_lock);
> list_add(&r1_bio->retry_list, &conf->bio_end_io_list);
> @@ -2396,6 +2394,9 @@ static void raid1d(struct md_thread *thread)
> r1_bio = list_first_entry(&tmp, struct r1bio,
> retry_list);
> list_del(&r1_bio->retry_list);
> + if (mddev->degraded)
> + set_bit(R1BIO_Degraded, &r1_bio->state);
> + close_write(r1_bio);
> raid_end_bio_io(r1_bio);
> }
> }
^ permalink raw reply
* Re: manually destriping a 4 drive raid5 with one missing drive
From: Alexander Afonyashin @ 2015-10-23 11:50 UTC (permalink / raw)
To: Marek; +Cc: Linux-RAID
In-Reply-To: <CA+sqOsZfjz0wTei+6qiv+zxXt7TA_GMO8EQ=v0EeDGFpqLrWRg@mail.gmail.com>
Hi Marek,
First, check status of disk you would like to remove via:
- cat /proc/mdstat
- mdadm -D /dev/md0 (replace md0 with you md-raid identifier)
Regards,
Alexader
On Fri, Oct 23, 2015 at 12:26 PM, Marek <mlf.conv@gmail.com> wrote:
> I have a 4 2TB disk raid5 512k 1.2.
> one of the drives was accidentally wiped by ubuntu installation
> (/dev/sda, first drive). The system has been rebooted forcefully
> several times before this happened. Raid wouldn't come up after that.
> The first drive has been -add ed back and a resync has been enforced.
> What i'd like to do is to manually destrip the raid.
>
> On Sun, Oct 18, 2015 at 12:54 AM, Neil Brown <nfbrown@novell.com> wrote:
>> Marek <mlf.conv@gmail.com> writes:
>>
>>> hi,
>>>
>>> i'd like to ask whether manual destriping of a 4 drive raid5 is
>>> possible even though the parity information is lost due to forced
>>> resync of all four drives.
>>>
>>
>> I'm sorry but I have no idea what you are asking.
>> Maybe if you provided more details about your current circumstances, how
>> you got into that situation, and what outcome you are hoping for, then I
>> might be able to help.
>>
>> NeilBrown
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] md-cluster: Only one thread should request DLM lock
From: Goldwyn Rodrigues @ 2015-10-23 10:19 UTC (permalink / raw)
To: Neil Brown, linux-raid; +Cc: gqjiang, Goldwyn Rodrigues
In-Reply-To: <874mhiz643.fsf@notabene.neil.brown.name>
On 10/22/2015 09:11 PM, Neil Brown wrote:
> rgoldwyn@suse.de writes:
>
>> From: Goldwyn Rodrigues <rgoldwyn@suse.com>
>>
>> If a DLM lock is in progress, requesting the same DLM lock will
>> result in -EBUSY. Use a mutex to make sure only one thread requests
>> for dlm_lock() function at a time.
>>
>> This will fix the error -EBUSY returned from DLM's
>> validate_lock_args().
>
> I can see that we only want one thread calling dlm_lock() with a given
> 'struct dlm_lock_resource' at a time, otherwise nasty things could
> happen.
>
> However if such a race is possible, then aren't there other possibly
> complications.
This is specific to the duration of dlm_lock() function only and not the
entire lifetime of the resource. If one thread has requested dlm_lock()
and another thread comes in and calls dlm_lock() on the same resource,
we will get -EBUSY on the second one because the lock is already requested.
Our dlm_unlock_sync() call is also a dlm_lock_sync(), and eventually
dlm_lock() call, with a NULL lock.
>
> Suppose two threads try to lock the same resource.
> Presumably one will try to lock the resource, then the next one (when it
> gets the mutex) will discover that it already has the resource, but will
> think it has exclusive access - maybe?
I am not sure if I understand this. DLM locks are supposed to be at the
node level as opposed to thread level.
>
> Then both threads will eventually try to unlock, and the second one will
> unlock something that doesn't have locked.
>
> I'm not certain, but that doesn't sound entirely safe.
>
> Which resources to we actually see races with?
>
This could happen with any resource, I have seen with ack, message, and
token.
--
Goldwyn
^ permalink raw reply
* Fwd: manually destriping a 4 drive raid5 with one missing drive
From: Marek @ 2015-10-23 9:26 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <CA+sqOsZJbvyAW6=CSG5EikhmDPt+Onjpm+VvBNPMKFmVi-ZQ8g@mail.gmail.com>
I have a 4 2TB disk raid5 512k 1.2.
one of the drives was accidentally wiped by ubuntu installation
(/dev/sda, first drive). The system has been rebooted forcefully
several times before this happened. Raid wouldn't come up after that.
The first drive has been -add ed back and a resync has been enforced.
What i'd like to do is to manually destrip the raid.
On Sun, Oct 18, 2015 at 12:54 AM, Neil Brown <nfbrown@novell.com> wrote:
> Marek <mlf.conv@gmail.com> writes:
>
>> hi,
>>
>> i'd like to ask whether manual destriping of a 4 drive raid5 is
>> possible even though the parity information is lost due to forced
>> resync of all four drives.
>>
>
> I'm sorry but I have no idea what you are asking.
> Maybe if you provided more details about your current circumstances, how
> you got into that situation, and what outcome you are hoping for, then I
> might be able to help.
>
> NeilBrown
^ permalink raw reply
* Re: RAID6 grow unexpected results
From: Neil Brown @ 2015-10-23 7:15 UTC (permalink / raw)
To: Liwei, linux-raid
In-Reply-To: <CAPE0SYwiCn7L4iDKXS92pLz6JSLaXVdxggj-kE_bDDFM8w-ppg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Liwei <xieliwei@gmail.com> writes:
> On Fri, 23 Oct 2015 at 06:37 Neil Brown <nfbrown@novell.com> wrote:
>>
>> Liwei <xieliwei@gmail.com> writes:
>>
>> > Hi list,
>> > I tried growing a RAID6 array by executing the mdadm --add and
>> > mdadm --grow --raid-devices commands. Usually that should run fine and
>> > I can continue with pvresize.
>>
>> That is incorrect. You cannot run "pvresize" until the reshape
>> completes.
>
>
> Ah, my bad. It's been a while since I did that. So if I had been
> patient, all would have been well?
>
>>
>>
>> >
>> > This time however, the actual usable raid array size did not
>> > change even though reshape begins. In my confusion, I decided to
>> > reboot. That didn't solve the problem (and apparently the reshape was
>> > interrupted, but mdadm shows the grown array as clean?)
>>
>> Clean is expected. It will be in an intermediate state, part has
>> reshaped to extra devices, part is still the original.
>>
>> >
>> > I then executed mdadm --grow --size=max, which seemed to have
>> > increased the array size, but apparently by too much. Now I'm getting
>> > "attempt to access beyond end of device" errors for each of the
>> > component drives. A new reshape operation has also begun, which I
>> > expect would fail as the array size is now too big.
>>
>> "--size" isn't the same as "--array-size".
>> "--size" is the size of the component devices to use.
>>
>> The "attempt to access beyond end of device" errors are unexpected but
>> presumably related o the "--size=max". Maybe the 'max' chosen was too
>> large. That suggests a bug somewhere.
>> You probably want to reduce that size back to where it was.
>
>
> I just realised I got the wrong command. I used --array-size=max
> instead. A reboot seemed to have reverted the change.
>
>>
>>
>> >
>> > What did I do wrong and how can I remedy this?
>>
>> Could we start with "mdadm --examine" status of all devices, "mdadm
>> --detail" of the array, and all kernel messages that could possibly
>> relate to the array since you first started this exercise?
>
>
> Eventually it was a foul up on my part. Things seem to be back to
> normal after a reboot, and the reshape is in progress. Apologies for
> the confusion!
Good to know that thing are working - thanks.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: RAID6 grow unexpected results
From: Liwei @ 2015-10-23 6:14 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <87io5yzg1a.fsf@notabene.neil.brown.name>
On Fri, 23 Oct 2015 at 06:37 Neil Brown <nfbrown@novell.com> wrote:
>
> Liwei <xieliwei@gmail.com> writes:
>
> > Hi list,
> > I tried growing a RAID6 array by executing the mdadm --add and
> > mdadm --grow --raid-devices commands. Usually that should run fine and
> > I can continue with pvresize.
>
> That is incorrect. You cannot run "pvresize" until the reshape
> completes.
Ah, my bad. It's been a while since I did that. So if I had been
patient, all would have been well?
>
>
> >
> > This time however, the actual usable raid array size did not
> > change even though reshape begins. In my confusion, I decided to
> > reboot. That didn't solve the problem (and apparently the reshape was
> > interrupted, but mdadm shows the grown array as clean?)
>
> Clean is expected. It will be in an intermediate state, part has
> reshaped to extra devices, part is still the original.
>
> >
> > I then executed mdadm --grow --size=max, which seemed to have
> > increased the array size, but apparently by too much. Now I'm getting
> > "attempt to access beyond end of device" errors for each of the
> > component drives. A new reshape operation has also begun, which I
> > expect would fail as the array size is now too big.
>
> "--size" isn't the same as "--array-size".
> "--size" is the size of the component devices to use.
>
> The "attempt to access beyond end of device" errors are unexpected but
> presumably related o the "--size=max". Maybe the 'max' chosen was too
> large. That suggests a bug somewhere.
> You probably want to reduce that size back to where it was.
I just realised I got the wrong command. I used --array-size=max
instead. A reboot seemed to have reverted the change.
>
>
> >
> > What did I do wrong and how can I remedy this?
>
> Could we start with "mdadm --examine" status of all devices, "mdadm
> --detail" of the array, and all kernel messages that could possibly
> relate to the array since you first started this exercise?
Eventually it was a foul up on my part. Things seem to be back to
normal after a reboot, and the reshape is in progress. Apologies for
the confusion!
Liwei
>
>
> NeilBrown
>
> >
> > Liwei
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Hung RAID5 array with discard
From: Neil Brown @ 2015-10-23 5:51 UTC (permalink / raw)
To: Peter Kieser, Terry Hardie; +Cc: linux-raid
In-Reply-To: <5629BE44.8070205@kieser.ca>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
Peter Kieser <peter@kieser.ca> writes:
> On 2015-10-22 9:42 PM, Neil Brown wrote:
>> Peter Kieser <peter@kieser.ca> writes:
>>
>>> FYI I ran into this problem in 3.18.22 when forcing RAID5 TRIM support
>>> w/ raid456.devices_handle_discard_safely on Intel DC S3500 SSDs.
>> Can you please be precise about the problem you experienced.
>> Complete kernel messages are a minimum.
>> Anything interesting that might have been happening at the time might
>> help.
>>
>> Thanks,
>> NeilBrown
>
> Same behaviour as the original poster. Enabled the module knob, then ran
> mkfs.ext4, which starts to do "Discarding device blocks" and then the
> machine hard locked. No kernel messages.
>
Thanks.
The original poster reported a hung-task dump...
When you say "hard locked" - can you still access from another
window/login, or is it totally forzen?
If former, are then any processes in D start? maybe mdXX-raid5?
Can you get /proc/$PID/stack of that process?
If totally frozen - do you have a console? Can you alt-sysrq-W ??
Or have you since rebooted and the problem isn't repeatable?
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: Hung RAID5 array with discard
From: Peter Kieser @ 2015-10-23 4:57 UTC (permalink / raw)
To: Neil Brown, Terry Hardie; +Cc: linux-raid
In-Reply-To: <87y4euxkj2.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On 2015-10-22 9:42 PM, Neil Brown wrote:
> Peter Kieser <peter@kieser.ca> writes:
>
>> FYI I ran into this problem in 3.18.22 when forcing RAID5 TRIM support
>> w/ raid456.devices_handle_discard_safely on Intel DC S3500 SSDs.
> Can you please be precise about the problem you experienced.
> Complete kernel messages are a minimum.
> Anything interesting that might have been happening at the time might
> help.
>
> Thanks,
> NeilBrown
Same behaviour as the original poster. Enabled the module knob, then ran
mkfs.ext4, which starts to do "Discarding device blocks" and then the
machine hard locked. No kernel messages.
-Peter
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4311 bytes --]
^ permalink raw reply
* Re: Hung RAID5 array with discard
From: Neil Brown @ 2015-10-23 4:42 UTC (permalink / raw)
To: Peter Kieser, Terry Hardie; +Cc: linux-raid
In-Reply-To: <562909AC.7040003@kieser.ca>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Peter Kieser <peter@kieser.ca> writes:
> FYI I ran into this problem in 3.18.22 when forcing RAID5 TRIM support
> w/ raid456.devices_handle_discard_safely on Intel DC S3500 SSDs.
Can you please be precise about the problem you experienced.
Complete kernel messages are a minimum.
Anything interesting that might have been happening at the time might
help.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ 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