* Re: raid1 - mismatches after resuming interrupted recovery
From: Jes Sorensen @ 2015-10-30 18:07 UTC (permalink / raw)
To: Nate Dailey; +Cc: NeilBrown, linux-raid
In-Reply-To: <5633A172.3020804@stratus.com>
Nate Dailey <nate.dailey@stratus.com> writes:
> This is the the same as "ignore recovery_offset if bitmap exists",
> describing how I hit the problem (before attempting to put a patch
> together to fix it).
Thanks for the clarification Nate, I thought it was two different
issues.
Clearly my grey hair is eating away at my brain. Neil please do your
best to ignore me :)
Jes
> On 10/30/2015 11:58 AM, Jes Sorensen wrote:
>> Nate Dailey <nate.dailey@stratus.com> writes:
>>> I've found that if I interrupt a recovery by removing the target
>>> device, do IO before the recovery checkpoint, then re-add the device
>>> and let the recovery complete, the mismatch_cnt is non-zero after
>>> doing a check.
>> Neil,
>>
>> While I am on the nagging path, here is another one.
>>
>> Jes
>>
>>> Here's exactly what I'm doing:
>>>
>>> - create a 5 GB raid1 with internal bitmap
>>>
>>> - do a check, verify zero mismatch_cnt
>>>
>>> - remove one member device
>>>
>>> - dd 256MB with 2GB seek
>>>
>>> - lower sync_speed_min/max to 500
>>>
>>> - re-add removed device
>>>
>>> - wait 15 sec
>>>
>>> - remove the same member device again
>>>
>>> - dd 1MB with 1 GB seek
>>>
>>> - restore sync_speed_min/max to system defaults
>>>
>>> - re-add removed device
>>>
>>> - when recovery competes, do another check
>>>
>>> At this point the mismatch_cnt is non-zero.
>>>
>>>
>>> I originally hit this on RHEL 7.1, but tested 4.1.1 from kernel.org
>>> and it happens there too.
>>>
>>> I'm out of my league in terms of trying to fix this, but would be
>>> happy to test a fix. I wonder if it's really necessary to resume a
>>> bitmap recovery from the checkpoint? Wouldn't the bitmap always
>>> reflect what needs to be copied?
>>>
>>> Nate
>>>
>>> --
>>> 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: raid1 - mismatches after resuming interrupted recovery
From: Nate Dailey @ 2015-10-30 16:57 UTC (permalink / raw)
To: Jes Sorensen, NeilBrown; +Cc: linux-raid
In-Reply-To: <wrfj1tccpcuc.fsf@carbonite.lan.trained-monkey.org>
This is the the same as "ignore recovery_offset if bitmap exists", describing
how I hit the problem (before attempting to put a patch together to fix it).
Nate
On 10/30/2015 11:58 AM, Jes Sorensen wrote:
> Nate Dailey <nate.dailey@stratus.com> writes:
>> I've found that if I interrupt a recovery by removing the target
>> device, do IO before the recovery checkpoint, then re-add the device
>> and let the recovery complete, the mismatch_cnt is non-zero after
>> doing a check.
> Neil,
>
> While I am on the nagging path, here is another one.
>
> Jes
>
>> Here's exactly what I'm doing:
>>
>> - create a 5 GB raid1 with internal bitmap
>>
>> - do a check, verify zero mismatch_cnt
>>
>> - remove one member device
>>
>> - dd 256MB with 2GB seek
>>
>> - lower sync_speed_min/max to 500
>>
>> - re-add removed device
>>
>> - wait 15 sec
>>
>> - remove the same member device again
>>
>> - dd 1MB with 1 GB seek
>>
>> - restore sync_speed_min/max to system defaults
>>
>> - re-add removed device
>>
>> - when recovery competes, do another check
>>
>> At this point the mismatch_cnt is non-zero.
>>
>>
>> I originally hit this on RHEL 7.1, but tested 4.1.1 from kernel.org
>> and it happens there too.
>>
>> I'm out of my league in terms of trying to fix this, but would be
>> happy to test a fix. I wonder if it's really necessary to resume a
>> bitmap recovery from the checkpoint? Wouldn't the bitmap always
>> reflect what needs to be copied?
>>
>> Nate
>>
>> --
>> 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/raid5: fix locking in handle_stripe_clean_event()
From: Shaohua Li @ 2015-10-30 16:25 UTC (permalink / raw)
To: Roman Gushchin
Cc: Neil Brown, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org
In-Reply-To: <47541446213767@webcorp02e.yandex-team.ru>
On Fri, Oct 30, 2015 at 05:02:47PM +0300, Roman Gushchin wrote:
> > Isn't the 4.1 fix just:
> >
> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > index e5befa356dbe..6e4350a78257 100644
> > --- a/drivers/md/raid5.c
> > +++ b/drivers/md/raid5.c
> > @@ -3522,16 +3522,16 @@ returnbi:
> > * no updated data, so remove it from hash list and the stripe
> > * will be reinitialized
> > */
> > - spin_lock_irq(&conf->device_lock);
> > unhash:
> > + spin_lock_irq(conf->hash_locks + sh->hash_lock_index);
> > remove_hash(sh);
> > + spin_unlock_irq(conf->hash_locks + sh->hash_lock_index);
> > if (head_sh->batch_head) {
> > sh = list_first_entry(&sh->batch_list,
> > struct stripe_head, batch_list);
> > if (sh != head_sh)
> > goto unhash;
> > }
> > - spin_unlock_irq(&conf->device_lock);
> > sh = head_sh;
> >
> > if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
> >
> > ??
>
> In my opion, this patch looks correct, although it seems to me, that there is an another issue here.
>
> > if (head_sh->batch_head) {
> > sh = list_first_entry(&sh->batch_list,
> > struct stripe_head, batch_list);
> > if (sh != head_sh)
> > goto unhash;
> > }
>
> With a patch above this code will be executed without taking any locks. It it correct?
> In my opinion, we need to take at least sh->stripe_lock, which protects sh->batch_head.
> Or do I miss something?
>
> If you want, we can handle this issue separately.
The batch_list list doesn't need the protection. Only the remove_hash() need it.
Thanks,
Shaohua
^ permalink raw reply
* Re: raid1 - mismatches after resuming interrupted recovery
From: Jes Sorensen @ 2015-10-30 15:58 UTC (permalink / raw)
To: NeilBrown; +Cc: Nate Dailey, linux-raid
In-Reply-To: <559AAAAA.2030904@stratus.com>
Nate Dailey <nate.dailey@stratus.com> writes:
> I've found that if I interrupt a recovery by removing the target
> device, do IO before the recovery checkpoint, then re-add the device
> and let the recovery complete, the mismatch_cnt is non-zero after
> doing a check.
Neil,
While I am on the nagging path, here is another one.
Jes
> Here's exactly what I'm doing:
>
> - create a 5 GB raid1 with internal bitmap
>
> - do a check, verify zero mismatch_cnt
>
> - remove one member device
>
> - dd 256MB with 2GB seek
>
> - lower sync_speed_min/max to 500
>
> - re-add removed device
>
> - wait 15 sec
>
> - remove the same member device again
>
> - dd 1MB with 1 GB seek
>
> - restore sync_speed_min/max to system defaults
>
> - re-add removed device
>
> - when recovery competes, do another check
>
> At this point the mismatch_cnt is non-zero.
>
>
> I originally hit this on RHEL 7.1, but tested 4.1.1 from kernel.org
> and it happens there too.
>
> I'm out of my league in terms of trying to fix this, but would be
> happy to test a fix. I wonder if it's really necessary to resume a
> bitmap recovery from the checkpoint? Wouldn't the bitmap always
> reflect what needs to be copied?
>
> Nate
>
> --
> 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/raid5: fix locking in handle_stripe_clean_event()
From: Roman Gushchin @ 2015-10-30 14:02 UTC (permalink / raw)
To: Neil Brown, linux-kernel@vger.kernel.org
Cc: Shaohua Li, linux-raid@vger.kernel.org
In-Reply-To: <87ziz1w33r.fsf@notabene.neil.brown.name>
> Isn't the 4.1 fix just:
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index e5befa356dbe..6e4350a78257 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -3522,16 +3522,16 @@ returnbi:
> * no updated data, so remove it from hash list and the stripe
> * will be reinitialized
> */
> - spin_lock_irq(&conf->device_lock);
> unhash:
> + spin_lock_irq(conf->hash_locks + sh->hash_lock_index);
> remove_hash(sh);
> + spin_unlock_irq(conf->hash_locks + sh->hash_lock_index);
> if (head_sh->batch_head) {
> sh = list_first_entry(&sh->batch_list,
> struct stripe_head, batch_list);
> if (sh != head_sh)
> goto unhash;
> }
> - spin_unlock_irq(&conf->device_lock);
> sh = head_sh;
>
> if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
>
> ??
In my opion, this patch looks correct, although it seems to me, that there is an another issue here.
> if (head_sh->batch_head) {
> sh = list_first_entry(&sh->batch_list,
> struct stripe_head, batch_list);
> if (sh != head_sh)
> goto unhash;
> }
With a patch above this code will be executed without taking any locks. It it correct?
In my opinion, we need to take at least sh->stripe_lock, which protects sh->batch_head.
Or do I miss something?
If you want, we can handle this issue separately.
Thanks,
Roman
^ permalink raw reply
* Re: [PATCH] drivers/md/md.c: ignore recovery_offset if bitmap exists
From: Nate Dailey @ 2015-10-30 13:30 UTC (permalink / raw)
To: Neil Brown, linux-raid; +Cc: Jes.Sorensen
In-Reply-To: <87r3kdvzl5.fsf@notabene.neil.brown.name>
I first tested 4.3-rc6 that I already had laying around, and verified that the
bug still happens.
Then I reverted 7eb418851f3278de67126ea0c427641ab4792c57, rebuilt & installed,
and tested again. Reverting this patch did indeed fix the bug.
Thank you!
Nate
On 10/29/2015 10:51 PM, Neil Brown wrote:
> On Sat, Aug 15 2015, Nate Dailey wrote:
>
>> I hate to nag... but looking for feedback on this change, which addresses what
>> seems to me to be a serious bug.
> Being a nag is good. I don't have the earlier emails in my inbox - I
> wonder what happened to them.... and for some reason this one was marked
> "read".
> But it arrived about when I converted over to notmuch and just before I
> went on 3 weeks leave...
>
> Anyway, Jes just poked me so I'm looking now.
>
>> Thanks,
>> Nate
>>
>>
>>
>>
>> On 07/29/2015 04:46 PM, Joe Lawrence wrote:
>>> On 07/28/2015 03:28 PM, Nate Dailey wrote:
>>>> If a bitmap recovery is interrupted and later restarted, then
>>>> sectors below the recovery offset, written between interruption
>>>> and resumption, will not be copied. This results in corruption.
>>>>
>>>> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777511
>>>> for a script that can be used to repro this.
>>>>
>>>> Seems like ignoring the recovery_offset if a bitmap exists is
>>>> the way to go.
> This doesn't feel like the right solution.
> Why does the presence of a bitmap affect the validity of
> ->recovery_offset.
>
> Surely recovery_offset should always be reliable and we should always
> use it. Maybe it isn't being updated correctly in some situation when a
> bitmap is present.
>
> Does it ever make sense to honour the recovery-offset when a device is
> re-added?
> I don't think it does....
>
> Oh. Look what I found.
> commit 7eb418851f3278de67126ea0c427641ab4792c57
> Author: NeilBrown <neilb@suse.de>
> Date: Tue Jan 14 15:55:14 2014 +1100
>
> md: allow a partially recovered device to be hot-added to an array.
>
> ...
> - rdev->recovery_offset = 0;
> + if (rdev->saved_raid_disk < 0)
> + rdev->recovery_offset = 0;
>
>
> we used to clear recovery_offset for a re-add, but we don't any more.
> I guess this patch introduced the bug.
>
> I cannot find anything in my mail logs to suggest why I wrote that
> patch.
>
> Right now I cannot think of any real justification for that patch.
> Could someone please test to see if reverting that patch fixes the
> problem?
>
> sorry for the delay in getting to this.
>
> Thanks.
> NeilBrown
>
>
>
>>>> Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
>>>> ---
>>>> drivers/md/md.c | 24 +++++++++++++-----------
>>>> 1 file changed, 13 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>>>> index 0c2a4e8..79c6285 100644
>>>> --- a/drivers/md/md.c
>>>> +++ b/drivers/md/md.c
>>>> @@ -7738,16 +7738,18 @@ void md_do_sync(struct md_thread *thread)
>>>> else {
>>>> /* recovery follows the physical size of devices */
>>>> max_sectors = mddev->dev_sectors;
>>>> - j = MaxSector;
>>>> - rcu_read_lock();
>>>> - rdev_for_each_rcu(rdev, mddev)
>>>> - if (rdev->raid_disk >= 0 &&
>>>> - !test_bit(Faulty, &rdev->flags) &&
>>>> - !test_bit(In_sync, &rdev->flags) &&
>>>> - rdev->recovery_offset < j)
>>>> - j = rdev->recovery_offset;
>>>> - rcu_read_unlock();
>>>> -
>>>> + /* we don't use the offset if there's a bitmap */
>>>> + if (!mddev->bitmap) {
>>>> + j = MaxSector;
>>>> + rcu_read_lock();
>>>> + rdev_for_each_rcu(rdev, mddev)
>>>> + if (rdev->raid_disk >= 0 &&
>>>> + !test_bit(Faulty, &rdev->flags) &&
>>>> + !test_bit(In_sync, &rdev->flags) &&
>>>> + rdev->recovery_offset < j)
>>>> + j = rdev->recovery_offset;
>>>> + rcu_read_unlock();
>>>> + }
>>>> /* If there is a bitmap, we need to make sure all
>>>> * writes that started before we added a spare
>>>> * complete before we start doing a recovery.
>>>> @@ -7756,7 +7758,7 @@ void md_do_sync(struct md_thread *thread)
>>>> * recovery has checked that bit and skipped that
>>>> * region.
>>>> */
>>>> - if (mddev->bitmap) {
>>>> + else {
>>>> mddev->pers->quiesce(mddev, 1);
>>>> mddev->pers->quiesce(mddev, 0);
>>>> }
>>>>
>>> [+cc Ben & Cyril from the Debian bug report]
>>>
>>> -- Joe
>>>
>>> --
>>> 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
* quickest way for complex operation?
From: Jens-U. Mozdzen @ 2015-10-30 13:26 UTC (permalink / raw)
To: linux-raid
Hi,
I have a working RAID6, consisting of seven disks.
I'd like to change all disks, because we suspect problems with the
drive types / controller combination.
On top, I'd like to reduce the number of disks to six - the seventh
disk was added during a operations test and the added space is not
actually needed. (The upper layers still see the size of the RAID
device as it was when only six disks were used).
The server chassis has 12 slots, ten of which are available to the
RAID disks (seven disks, plus three empty slots).
As a first step, I inserted three of the new disks into the empty
slots, added them as spares to the RAID set and ran mdraid --replace
for three of the old disks.
The question is, how do I optimally continue once the first three
disks are replaced and the according three old disks are removed. Can
I both replace and resize in a single (or almost single) step?
I had hoped that something along the following might work:
- fail one of the remaining 4 old drives
- mark the other three old drives for replace
- reshape the RAID to 6 disks (which probably will start right away)
- insert the three new disks and add them as spares
which then *might* result (after the resync) in four old disks marked
as faulty, leaving me with a six-disk RAID6 consisting of only the new
disks.
Am I on the right track, or will I have to run this in individual
steps (replace three more disks, then fail the remaining old disk,
then reshape)?
The data is fully backed up and replicated live to another server, so
the reduced resiliency to disk failure is less of a problem. But I'd
like to do an online replacement, without taking days. The new disks
are much faster than the old ones, too.
Thank you for any insight, ideas or comments you'd like to share.
Regards,
Jens
^ permalink raw reply
* Re: Raid array name by mdadm
From: Anugraha Sinha @ 2015-10-30 12:32 UTC (permalink / raw)
To: Sheng Yang, Dragan Milivojević; +Cc: linux-raid
In-Reply-To: <CA+2rt40+GxLeSUaQYouHjg=1pC8tJFJrEZFj5ZV0cm03hOJb5g@mail.gmail.com>
Hi Sheng,
On 10/29/2015 7:01 AM, Sheng Yang wrote:
> On Wed, Oct 28, 2015 at 2:40 PM, Sheng Yang <sheng@yasker.org> wrote:
>> On Wed, Oct 28, 2015 at 12:56 PM, Dragan Milivojević
>> <galileo@pkm-inc.com> wrote:
>>> mdadm --create /dev/md/device-123 --verbose --level=mirror
>>> --raid-devices=2 /dev/loop0 /dev/loop1
>>>
>>> [root@eos ~]# ll /dev/md/device-123
>>> lrwxrwxrwx 1 root root 8 Oct 28 20:53 /dev/md/device-123 -> ../md127
>>>
>>> [root@eos ~]# mdadm --detail --scan
>>> ARRAY /dev/md/device-123 metadata=1.2 name=device-123
>>> UUID=03ba5df7:7c5cc933:367e19ef:384665c5
>>
>> Thank Dragan! It works!
>>
>> Seems it's mdadm itself create the link rather than do through kernel,
>> which gave me a little trouble. :D
>
> Hi Dragan,
>
> One more question if you don't mind:
>
> When you do
>
> mdadm --stop /dev/md/device-123
>
> Would mdadm remove the broken link file /dev/md/device-123 automatically?
>
> I found I have to remove the link file manually later...
>
You stopped the array. You might want to assemble it once again saying
mdadm --assemble /dev/md/device-123 /dev/loop0 /dev/loop1
Then, it would just create a new /dev/md*number* and create the link
with /dev/md/device-123.
This is my logical thought, havent looked at the mdadm code though to
confirm this.
Regards
Anugraha
--
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] [mdadm] add crc32c and use it for r5l checksum
From: Neil Brown @ 2015-10-30 6:39 UTC (permalink / raw)
To: linux-raid; +Cc: shli, hch, dan.j.williams, kernel-team, Song Liu
In-Reply-To: <1446059166-1376285-1-git-send-email-songliubraving@fb.com>
[-- Attachment #1: Type: text/plain, Size: 6341 bytes --]
On Thu, Oct 29 2015, Song Liu wrote:
> In kernel space, r5l checksum will use crc32c:
> http://marc.info/?l=linux-raid&m=144598970529191
> mdadm need to change too.
>
> This patch ports a simplified crc32c algorithm from kernel code,
> and used in super1.c:write_empty_r5l_meta_block();
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> Signed-off-by: Shaohua Li <shli@fb.com>
applied, thanks.
NeilBrown
> ---
> Makefile | 2 +-
> crc32c.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> super1.c | 11 +++----
> 3 files changed, 109 insertions(+), 8 deletions(-)
> create mode 100644 crc32c.c
>
> diff --git a/Makefile b/Makefile
> index 544e6cb..fde2e63 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -133,7 +133,7 @@ OBJS = mdadm.o config.o policy.o mdstat.o ReadMe.o util.o maps.o lib.o \
> mdopen.o super0.o super1.o super-ddf.o super-intel.o bitmap.o \
> super-mbr.o super-gpt.o \
> restripe.o sysfs.o sha1.o mapfile.o crc32.o sg_io.o msg.o xmalloc.o \
> - platform-intel.o probe_roms.o
> + platform-intel.o probe_roms.o crc32c.o
>
> CHECK_OBJS = restripe.o sysfs.o maps.o lib.o xmalloc.o dlink.o
>
> diff --git a/crc32c.c b/crc32c.c
> new file mode 100644
> index 0000000..156cba1
> --- /dev/null
> +++ b/crc32c.c
> @@ -0,0 +1,104 @@
> +/*
> + * Oct 28, 2015 Song Liu simplified the code and port it to mdadm
> + *
> + * Aug 8, 2011 Bob Pearson with help from Joakim Tjernlund and George Spelvin
> + * cleaned up code to current version of sparse and added the slicing-by-8
> + * algorithm to the closely similar existing slicing-by-4 algorithm.
> + *
> + * Oct 15, 2000 Matt Domsch <Matt_Domsch@dell.com>
> + * Nicer crc32 functions/docs submitted by linux@horizon.com. Thanks!
> + * Code was from the public domain, copyright abandoned. Code was
> + * subsequently included in the kernel, thus was re-licensed under the
> + * GNU GPL v2.
> + *
> + * Oct 12, 2000 Matt Domsch <Matt_Domsch@dell.com>
> + * Same crc32 function was used in 5 other places in the kernel.
> + * I made one version, and deleted the others.
> + * There are various incantations of crc32(). Some use a seed of 0 or ~0.
> + * Some xor at the end with ~0. The generic crc32() function takes
> + * seed as an argument, and doesn't xor at the end. Then individual
> + * users can do whatever they need.
> + * drivers/net/smc9194.c uses seed ~0, doesn't xor with ~0.
> + * fs/jffs2 uses seed 0, doesn't xor with ~0.
> + * fs/partitions/efi.c uses seed ~0, xor's with ~0.
> + *
> + * This source code is licensed under the GNU General Public License,
> + * Version 2. See the file COPYING for more details.
> + */
> +
> +#include <sys/types.h>
> +#include <asm/types.h>
> +#include <stdlib.h>
> +
> +/*
> + * There are multiple 16-bit CRC polynomials in common use, but this is
> + * *the* standard CRC-32 polynomial, first popularized by Ethernet.
> + * x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0
> + */
> +#define CRCPOLY_LE 0xedb88320
> +#define CRCPOLY_BE 0x04c11db7
> +
> +/*
> + * This is the CRC32c polynomial, as outlined by Castagnoli.
> + * x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+
> + * x^8+x^6+x^0
> + */
> +#define CRC32C_POLY_LE 0x82F63B78
> +
> +/**
> + * crc32_le_generic() - Calculate bitwise little-endian Ethernet AUTODIN II
> + * CRC32/CRC32C
> + * @crc: seed value for computation. ~0 for Ethernet, sometimes 0 for other
> + * uses, or the previous crc32/crc32c value if computing incrementally.
> + * @p: pointer to buffer over which CRC32/CRC32C is run
> + * @len: length of buffer @p
> + * @polynomial: CRC32/CRC32c LE polynomial
> + */
> +static inline __u32 crc32_le_generic(__u32 crc, unsigned char const *p,
> + size_t len, __u32 polynomial)
> +{
> + int i;
> + while (len--) {
> + crc ^= *p++;
> + for (i = 0; i < 8; i++)
> + crc = (crc >> 1) ^ ((crc & 1) ? polynomial : 0);
> + }
> + return crc;
> +}
> +
> +__u32 crc32_le(__u32 crc, unsigned char const *p, size_t len)
> +{
> + return crc32_le_generic(crc, p, len, CRCPOLY_LE);
> +}
> +
> +__u32 crc32c_le(__u32 crc, unsigned char const *p, size_t len)
> +{
> + return crc32_le_generic(crc, p, len, CRC32C_POLY_LE);
> +}
> +
> +/**
> + * crc32_be_generic() - Calculate bitwise big-endian Ethernet AUTODIN II CRC32
> + * @crc: seed value for computation. ~0 for Ethernet, sometimes 0 for
> + * other uses, or the previous crc32 value if computing incrementally.
> + * @p: pointer to buffer over which CRC32 is run
> + * @len: length of buffer @p
> + * @polynomial: CRC32 BE polynomial
> + */
> +static inline __u32 crc32_be_generic(__u32 crc, unsigned char const *p,
> + size_t len, __u32 polynomial)
> +{
> + int i;
> + while (len--) {
> + crc ^= *p++ << 24;
> + for (i = 0; i < 8; i++)
> + crc =
> + (crc << 1) ^ ((crc & 0x80000000) ? polynomial :
> + 0);
> + }
> + return crc;
> +}
> +
> +__u32 crc32_be(__u32 crc, unsigned char const *p, size_t len)
> +{
> + return crc32_be_generic(crc, p, len, CRCPOLY_BE);
> +}
> diff --git a/super1.c b/super1.c
> index 58e6f9d..1735c2d 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -1625,10 +1625,7 @@ static unsigned long choose_bm_space(unsigned long devsize)
> static void free_super1(struct supertype *st);
>
> #define META_BLOCK_SIZE 4096
> -unsigned long crc32(
> - unsigned long crc,
> - const unsigned char *buf,
> - unsigned len);
> +__u32 crc32c_le(__u32 crc, unsigned char const *p, size_t len);
>
> static int write_empty_r5l_meta_block(struct supertype *st, int fd)
> {
> @@ -1652,9 +1649,9 @@ static int write_empty_r5l_meta_block(struct supertype *st, int fd)
> mb->seq = __cpu_to_le64(random32());
> mb->position = __cpu_to_le64(0);
>
> - crc = crc32(0xffffffff, sb->set_uuid, sizeof(sb->set_uuid));
> - crc = crc32(crc, (void *)mb, META_BLOCK_SIZE);
> - mb->checksum = __cpu_to_le32(crc);
> + crc = crc32c_le(0xffffffff, sb->set_uuid, sizeof(sb->set_uuid));
> + crc = crc32c_le(crc, (void *)mb, META_BLOCK_SIZE);
> + mb->checksum = crc;
>
> if (lseek64(fd, (sb->data_offset) * 512, 0) < 0LL) {
> pr_err("cannot seek to offset of the meta block\n");
> --
> 2.4.6
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH] raid5-cache: use crc32c checksum
From: Neil Brown @ 2015-10-30 6:37 UTC (permalink / raw)
To: Bart Van Assche, Shaohua Li; +Cc: linux-raid, Kernel-team, songliubraving, hch
In-Reply-To: <56315032.7070904@sandisk.com>
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
On Thu, Oct 29 2015, Bart Van Assche wrote:
> On 10/28/2015 08:41 AM, Shaohua Li wrote:
>> crc32c has lower overhead with cpu acceleration. It's a shame I didn't
>> use it in first post, sorry. This changes disk format, but we are still
>> ok in current stage.
>>
>> V2: delete unnecessary type conversion as pointed out by Bart
>
> Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Thanks. I've applied the second version and added your reviewed-by.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/md/md.c: ignore recovery_offset if bitmap exists
From: Neil Brown @ 2015-10-30 2:51 UTC (permalink / raw)
To: Nate Dailey, linux-raid; +Cc: Jes.Sorensen
In-Reply-To: <55CE0207.1020707@stratus.com>
[-- Attachment #1: Type: text/plain, Size: 4241 bytes --]
On Sat, Aug 15 2015, Nate Dailey wrote:
> I hate to nag... but looking for feedback on this change, which addresses what
> seems to me to be a serious bug.
Being a nag is good. I don't have the earlier emails in my inbox - I
wonder what happened to them.... and for some reason this one was marked
"read".
But it arrived about when I converted over to notmuch and just before I
went on 3 weeks leave...
Anyway, Jes just poked me so I'm looking now.
>
> Thanks,
> Nate
>
>
>
>
> On 07/29/2015 04:46 PM, Joe Lawrence wrote:
>> On 07/28/2015 03:28 PM, Nate Dailey wrote:
>>> If a bitmap recovery is interrupted and later restarted, then
>>> sectors below the recovery offset, written between interruption
>>> and resumption, will not be copied. This results in corruption.
>>>
>>> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777511
>>> for a script that can be used to repro this.
>>>
>>> Seems like ignoring the recovery_offset if a bitmap exists is
>>> the way to go.
This doesn't feel like the right solution.
Why does the presence of a bitmap affect the validity of
->recovery_offset.
Surely recovery_offset should always be reliable and we should always
use it. Maybe it isn't being updated correctly in some situation when a
bitmap is present.
Does it ever make sense to honour the recovery-offset when a device is
re-added?
I don't think it does....
Oh. Look what I found.
commit 7eb418851f3278de67126ea0c427641ab4792c57
Author: NeilBrown <neilb@suse.de>
Date: Tue Jan 14 15:55:14 2014 +1100
md: allow a partially recovered device to be hot-added to an array.
...
- rdev->recovery_offset = 0;
+ if (rdev->saved_raid_disk < 0)
+ rdev->recovery_offset = 0;
we used to clear recovery_offset for a re-add, but we don't any more.
I guess this patch introduced the bug.
I cannot find anything in my mail logs to suggest why I wrote that
patch.
Right now I cannot think of any real justification for that patch.
Could someone please test to see if reverting that patch fixes the
problem?
sorry for the delay in getting to this.
Thanks.
NeilBrown
>>>
>>> Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
>>> ---
>>> drivers/md/md.c | 24 +++++++++++++-----------
>>> 1 file changed, 13 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>>> index 0c2a4e8..79c6285 100644
>>> --- a/drivers/md/md.c
>>> +++ b/drivers/md/md.c
>>> @@ -7738,16 +7738,18 @@ void md_do_sync(struct md_thread *thread)
>>> else {
>>> /* recovery follows the physical size of devices */
>>> max_sectors = mddev->dev_sectors;
>>> - j = MaxSector;
>>> - rcu_read_lock();
>>> - rdev_for_each_rcu(rdev, mddev)
>>> - if (rdev->raid_disk >= 0 &&
>>> - !test_bit(Faulty, &rdev->flags) &&
>>> - !test_bit(In_sync, &rdev->flags) &&
>>> - rdev->recovery_offset < j)
>>> - j = rdev->recovery_offset;
>>> - rcu_read_unlock();
>>> -
>>> + /* we don't use the offset if there's a bitmap */
>>> + if (!mddev->bitmap) {
>>> + j = MaxSector;
>>> + rcu_read_lock();
>>> + rdev_for_each_rcu(rdev, mddev)
>>> + if (rdev->raid_disk >= 0 &&
>>> + !test_bit(Faulty, &rdev->flags) &&
>>> + !test_bit(In_sync, &rdev->flags) &&
>>> + rdev->recovery_offset < j)
>>> + j = rdev->recovery_offset;
>>> + rcu_read_unlock();
>>> + }
>>> /* If there is a bitmap, we need to make sure all
>>> * writes that started before we added a spare
>>> * complete before we start doing a recovery.
>>> @@ -7756,7 +7758,7 @@ void md_do_sync(struct md_thread *thread)
>>> * recovery has checked that bit and skipped that
>>> * region.
>>> */
>>> - if (mddev->bitmap) {
>>> + else {
>>> mddev->pers->quiesce(mddev, 1);
>>> mddev->pers->quiesce(mddev, 0);
>>> }
>>>
>> [+cc Ben & Cyril from the Debian bug report]
>>
>> -- Joe
>>
>> --
>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Good day friend!
From: Abdul @ 2015-10-30 2:15 UTC (permalink / raw)
To: Recipients
i have an interesting business proposal for you that will be of immense
benefit to both of us.we stand to gain 26.2 million USD between us in a matter of days
^ permalink raw reply
* Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()
From: Neil Brown @ 2015-10-30 1:35 UTC (permalink / raw)
To: Roman Gushchin, linux-kernel@vger.kernel.org
Cc: Shaohua Li, linux-raid@vger.kernel.org
In-Reply-To: <30651446128148@webcorp02d.yandex-team.ru>
[-- Attachment #1: Type: text/plain, Size: 3850 bytes --]
On Fri, Oct 30 2015, Roman Gushchin wrote:
> 29.10.2015, 03:35, "Neil Brown" <neilb@suse.de>:
>> On Wed, Oct 28 2015, Roman Gushchin wrote:
>>
>>> After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
>>> __find_stripe() is called under conf->hash_locks + hash.
>>> But handle_stripe_clean_event() calls remove_hash() under
>>> conf->device_lock.
>>>
>>> Under some cirscumstances the hash chain can be circuited,
>>> and we get an infinite loop with disabled interrupts and locked hash
>>> lock in __find_stripe(). This leads to hard lockup on multiple CPUs
>>> and following system crash.
>>>
>>> I was able to reproduce this behavior on raid6 over 6 ssd disks.
>>> The devices_handle_discard_safely option should be set to enable trim
>>> support. The following script was used:
>>>
>>> for i in `seq 1 32`; do
>>> dd if=/dev/zero of=large$i bs=10M count=100 &
>>> done
>>>
>>> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
>>> Cc: Neil Brown <neilb@suse.de>
>>> Cc: Shaohua Li <shli@kernel.org>
>>> Cc: linux-raid@vger.kernel.org
>>> Cc: <stable@vger.kernel.org> # 3.10 - 3.19
>>
>> Hi Roman,
>> thanks for reporting this and providing a fix.
>>
>> I'm a bit confused by that stable range: 3.10 - 3.19
>>
>> The commit you identify as introducing the bug was added in 3.13, so
>> presumably 3.10, 3.11, 3.12 are not affected.
>
> Sure, it's my mistake. Correct range is 3.13 - 3.19. Sorry.
>
>> Also the bug is still present in mainline, so 4.0, 4.1, 4.2 are also
>> affected, though the patch needs to be revised a bit for 4.1 and later.
>
> Yes, exactly, but things are a bit more complicated in mainline.
> I'll try to prepare a patch for mainline in a couple of days.
>
Thanks for the confirmation.
Isn't the 4.1 fix just:
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index e5befa356dbe..6e4350a78257 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3522,16 +3522,16 @@ returnbi:
* no updated data, so remove it from hash list and the stripe
* will be reinitialized
*/
- spin_lock_irq(&conf->device_lock);
unhash:
+ spin_lock_irq(conf->hash_locks + sh->hash_lock_index);
remove_hash(sh);
+ spin_unlock_irq(conf->hash_locks + sh->hash_lock_index);
if (head_sh->batch_head) {
sh = list_first_entry(&sh->batch_list,
struct stripe_head, batch_list);
if (sh != head_sh)
goto unhash;
}
- spin_unlock_irq(&conf->device_lock);
sh = head_sh;
if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
??
Or maybe
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index e5befa356dbe..704ef7fcfbf8 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3509,6 +3509,7 @@ returnbi:
if (!discard_pending &&
test_bit(R5_Discard, &sh->dev[sh->pd_idx].flags)) {
+ int hash;
clear_bit(R5_Discard, &sh->dev[sh->pd_idx].flags);
clear_bit(R5_UPTODATE, &sh->dev[sh->pd_idx].flags);
if (sh->qd_idx >= 0) {
@@ -3522,16 +3523,17 @@ returnbi:
* no updated data, so remove it from hash list and the stripe
* will be reinitialized
*/
- spin_lock_irq(&conf->device_lock);
unhash:
+ hash = sh->hash_lock_index;
+ spin_lock_irq(conf->hash_locks + hash);
remove_hash(sh);
+ spin_unlock_irq(conf->hash_locks + hash);
if (head_sh->batch_head) {
sh = list_first_entry(&sh->batch_list,
struct stripe_head, batch_list);
if (sh != head_sh)
goto unhash;
}
- spin_unlock_irq(&conf->device_lock);
sh = head_sh;
if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
For personal reasons I would like to get this resolved today or
tomorrow, though it would be silly to rush if there is any uncertainty.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply related
* Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()
From: Greg KH @ 2015-10-29 21:22 UTC (permalink / raw)
To: Roman Gushchin
Cc: Neil Brown, linux-kernel@vger.kernel.org, Shaohua Li,
linux-raid@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <30651446128148@webcorp02d.yandex-team.ru>
On Thu, Oct 29, 2015 at 05:15:48PM +0300, Roman Gushchin wrote:
> 29.10.2015, 03:35, "Neil Brown" <neilb@suse.de>:
> > On Wed, Oct 28 2015, Roman Gushchin wrote:
> >
> >> After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
> >> __find_stripe() is called under conf->hash_locks + hash.
> >> But handle_stripe_clean_event() calls remove_hash() under
> >> conf->device_lock.
> >>
> >> Under some cirscumstances the hash chain can be circuited,
> >> and we get an infinite loop with disabled interrupts and locked hash
> >> lock in __find_stripe(). This leads to hard lockup on multiple CPUs
> >> and following system crash.
> >>
> >> I was able to reproduce this behavior on raid6 over 6 ssd disks.
> >> The devices_handle_discard_safely option should be set to enable trim
> >> support. The following script was used:
> >>
> >> for i in `seq 1 32`; do
> >> dd if=/dev/zero of=large$i bs=10M count=100 &
> >> done
> >>
> >> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> >> Cc: Neil Brown <neilb@suse.de>
> >> Cc: Shaohua Li <shli@kernel.org>
> >> Cc: linux-raid@vger.kernel.org
> >> Cc: <stable@vger.kernel.org> # 3.10 - 3.19
> >
> > Hi Roman,
> > thanks for reporting this and providing a fix.
> >
> > I'm a bit confused by that stable range: 3.10 - 3.19
> >
> > The commit you identify as introducing the bug was added in 3.13, so
> > presumably 3.10, 3.11, 3.12 are not affected.
>
> Sure, it's my mistake. Correct range is 3.13 - 3.19. Sorry.
>
> > Also the bug is still present in mainline, so 4.0, 4.1, 4.2 are also
> > affected, though the patch needs to be revised a bit for 4.1 and later.
>
> Yes, exactly, but things are a bit more complicated in mainline.
> I'll try to prepare a patch for mainline in a couple of days.
We can't do anything with a patch that is not already in Linus's tree,
which is why this isn't even in my patch queue anymore. Please resend
this once the fix is in Linus's tree, with the git commit id of what it
is there and we will be glad to queue it up.
thanks,
greg k-h
^ permalink raw reply
* Re: How to recover after md crash during reshape?
From: Andras Tantos @ 2015-10-29 16:59 UTC (permalink / raw)
To: Phil Turmel; +Cc: Linux-RAID
In-Reply-To: <5630FB05.5070902@turmel.org>
Phil,
On 10/28/2015 9:42 AM, Phil Turmel wrote:
> If you stop the array cleanly and then manually re-assemble with
> --update=metadata, you might get around it. (Specify all of the
> devices explicitly to ensure you don't get burned by v0.90's problems
> with last partitions.) You definitely don't want to stay on v0.90, but
> you may need to for now to get out of trouble. Phil
It seems that my mdadm doesn't have an --update=metadata option, which
if I understand it right means I have to re-create the array with the
no-bitmap option. How dangerous is that? Is it possible that things get
overwritten during the re-create process in the data portion of the array?
I've read that GRUB (which is my bootloader) didn't support v1.0
superblocks for a while. It seems that 0.99 version of GRUB (which is
what I have) has it, but how to make certain? I don't want to render my
system un-bootable...
Can you expand a little bit on the problems of v0.90 superblocks and why
upgrading is advantageous? What I've read about the differences (lifted
limit of number of devices/array and 2TB per device limit) don't really
apply to my case.
Thanks,
Andras
^ permalink raw reply
* Reconstruct a RAID 6 that has failed in a non typical manner
From: Clement Parisot @ 2015-10-29 15:59 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <404650428.13997384.1446132658661.JavaMail.zimbra@inria.fr>
Hi everyone,
we've got a problem with our old RAID 6.
root@ftalc2.nancy.grid5000.fr(physical):~# uname -a
Linux ftalc2.nancy.grid5000.fr 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 GNU/Linux
root@ftalc2.nancy.grid5000.fr(physical):~# cat /etc/debian_version
6.0.8
root@ftalc2.nancy.grid5000.fr(physical):~# mdadm -V
mdadm - v3.1.4 - 31st August 2010
After an electrical maintenance, 2 of our HDD came in fail state. An alert was sent that said everything was reconstructing.
g5kadmin@ftalc2.nancy.grid5000.fr(physical):~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid6 sda[0] sdp[15] sdo[14] sdn[13] sdm[12] sdl[11] sdk[18] sdj[9] sdi[8] sdh[16] sdg[6] sdf[5] sde[4] sdd[17] sdc[2] sdb[1](F)
13666978304 blocks super 1.2 level 6, 128k chunk, algorithm 2 [16/15] [U_UUUUUUUUUUUUUU]
[>....................] resync = 0.0% (916936/976212736) finish=16851.9min speed=964K/sec
md1 : active raid1 sdq2[0] sdr2[2]
312276856 blocks super 1.2 [2/2] [UU]
[===>.................] resync = 18.4% (57566208/312276856) finish=83.2min speed=50956K/sec
md0 : active raid1 sdq1[0] sdr1[2]
291828 blocks super 1.2 [2/2] [UU]
unused devices: <none>
md1 reconstruction works but md2 failed as a 3rd HDD seems to be broked. A new disk has been successfully added to replace a failed one.
All of the disks of md2 changed to Spare state. We rebooted the server but it was worse.
mdadm --detail command show that 13 disks left on the array and 3 are removed.
/dev/md2:
Version : 1.2
Creation Time : Tue Oct 2 16:28:23 2012
Raid Level : raid6
Used Dev Size : 976212736 (930.99 GiB 999.64 GB)
Raid Devices : 16
Total Devices : 13
Persistence : Superblock is persistent
Update Time : Wed Oct 28 13:46:13 2015
State : active, FAILED, Not Started
Active Devices : 13
Working Devices : 13
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
Name : ftalc2.nancy.grid5000.fr:2 (local to host ftalc2.nancy.grid5000.fr)
UUID : 2d0b91e8:a0b10f4c:3fa285f9:3198a918
Events : 5834052
Number Major Minor RaidDevice State
0 0 0 0 removed
1 0 0 1 removed
2 8 16 2 active sync /dev/sdb
17 8 32 3 active sync /dev/sdc
4 8 48 4 active sync /dev/sdd
5 8 64 5 active sync /dev/sde
6 0 0 6 removed
16 8 96 7 active sync /dev/sdg
8 8 112 8 active sync /dev/sdh
9 8 128 9 active sync /dev/sdi
18 8 144 10 active sync /dev/sdj
11 8 160 11 active sync /dev/sdk
13 8 192 13 active sync /dev/sdm
14 8 208 14 active sync /dev/sdn
As you can see, RAID is in "active, FAILED, Not Started" State. We tried to add the new disk, re-add the previously removed disks as they appears to have no errors.
2/3 of the disks should still contains the datas. We want to recover it.
But there is a problem, devices /dev/sda and /dev/sdf can't be re-added:
mdadm: failed to add /dev/sda to /dev/md/2: Device or resource busy
mdadm: failed to add /dev/sdf to /dev/md/2: Device or resource busy
mdadm: /dev/md/2 assembled from 13 drives and 1 spare - not enough to start the array.
I tried procedure on RAID_Recovery wiki
mdadm --assemble --force /dev/md2 /dev/sda /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm /dev/sdn /dev/sdo /dev/sdp
but it failed.
mdadm: failed to add /dev/sdg to /dev/md2: Device or resource busy
mdadm: failed to RUN_ARRAY /dev/md2: Input/output error
mdadm: Not enough devices to start the array.
Any help or tips on how to diagnose better the situation or solve it would be higly appreciated :-)
Thanks in advance,
Best regards,
Clément and Marc
--
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/raid5: fix locking in handle_stripe_clean_event()
From: Roman Gushchin @ 2015-10-29 14:15 UTC (permalink / raw)
To: Neil Brown, linux-kernel@vger.kernel.org
Cc: Shaohua Li, linux-raid@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <87r3kebjgx.fsf@notabene.neil.brown.name>
29.10.2015, 03:35, "Neil Brown" <neilb@suse.de>:
> On Wed, Oct 28 2015, Roman Gushchin wrote:
>
>> After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
>> __find_stripe() is called under conf->hash_locks + hash.
>> But handle_stripe_clean_event() calls remove_hash() under
>> conf->device_lock.
>>
>> Under some cirscumstances the hash chain can be circuited,
>> and we get an infinite loop with disabled interrupts and locked hash
>> lock in __find_stripe(). This leads to hard lockup on multiple CPUs
>> and following system crash.
>>
>> I was able to reproduce this behavior on raid6 over 6 ssd disks.
>> The devices_handle_discard_safely option should be set to enable trim
>> support. The following script was used:
>>
>> for i in `seq 1 32`; do
>> dd if=/dev/zero of=large$i bs=10M count=100 &
>> done
>>
>> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
>> Cc: Neil Brown <neilb@suse.de>
>> Cc: Shaohua Li <shli@kernel.org>
>> Cc: linux-raid@vger.kernel.org
>> Cc: <stable@vger.kernel.org> # 3.10 - 3.19
>
> Hi Roman,
> thanks for reporting this and providing a fix.
>
> I'm a bit confused by that stable range: 3.10 - 3.19
>
> The commit you identify as introducing the bug was added in 3.13, so
> presumably 3.10, 3.11, 3.12 are not affected.
Sure, it's my mistake. Correct range is 3.13 - 3.19. Sorry.
> Also the bug is still present in mainline, so 4.0, 4.1, 4.2 are also
> affected, though the patch needs to be revised a bit for 4.1 and later.
Yes, exactly, but things are a bit more complicated in mainline.
I'll try to prepare a patch for mainline in a couple of days.
Thanks,
Roman
^ permalink raw reply
* Re: 2nd Faulty drive while rebuilding array on RAID5
From: Phil Turmel @ 2015-10-29 12:21 UTC (permalink / raw)
To: Guillaume ALLEE; +Cc: linux-raid
In-Reply-To: <CABEdK7wDU42phn2RTqUQWVTCet5v+WqtRYoD0ezvHXpGioapmQ@mail.gmail.com>
Good morning Guillaume,
On 10/28/2015 04:35 PM, Guillaume ALLEE wrote:
> Thanks for your answer. I have tested my sda3 with badblocks and it
> seems really bad like 6 digits unreadable blocks...
Hmm. Is there any chance your cabling or power supply is at fault?
>> Something's missing. I see only sd[abcd]3. Where's the report for
>> /dev/sde* ?
> Yep because /dev/sde is not part of my /dec/md1 array.
Ok.
> "ARRAY /dev/md1 level=raid5 num-devices=4 metadata=00.90
> UUID=426d71a2:5b25a168:a4e2eff2:d305f1c1
> devices=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sdd3"
Just for future reference: you aren't expected to keep the output of
"mdadm -Es" as your permanent mdadm.conf. Your system will be much more
robust if you trim that to just the MD device name and the UUID.
>> Yes, you have WD20EARS and ST3000DM001 drive models. These are not safe
>> to use in raid arrays due to lack of error recovery control.
> Okay I will look at that for my next HDs.
Yes, it should guide your future purchasing, but you have a crisis on
your hands -- you *must* set your driver timeouts to deal with your
consumer-grade desktop drives or your array *will* crash again *soon*.
>> You need to stop the array and perform an '--assemble --force' with the
>> last four devices (exclude /dev/sdc). The ones that have "Raid Device"
>> 0, 1, 2, & 3.
> Here is the assemble output.
>
> #mdadm --assemble --force /dev/md1 /dev/sda3 /dev/sdb3 /dev/sdd3
> mdadm: no recogniseable superblock on /dev/sda3
> mdadm: /dev/sda3 has no superblock - assembly aborted
Hmmm. You need three readable drives with original data to get out of
this trap. What happened to the original /dev/sdc? Using it with a
carefully constructed --create --assume-clean may be your only chance to
recover anything.
Also, before you risk wiping anything else, generate mdadm -E reports
for each device along with a "smartctl -i -A -l scterc" report. That
ties the array details (especially role) for each device to the drive
serial number. As you plug and unplug devices, names can change.
Just post that information inline in your next reply -- no need to use
pastebin.
Phil
^ permalink raw reply
* Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()
From: Neil Brown @ 2015-10-29 0:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Roman Gushchin, Shaohua Li, linux-raid, stable
In-Reply-To: <1446022340-1453-1-git-send-email-klamm@yandex-team.ru>
[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]
On Wed, Oct 28 2015, Roman Gushchin wrote:
> After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
> __find_stripe() is called under conf->hash_locks + hash.
> But handle_stripe_clean_event() calls remove_hash() under
> conf->device_lock.
>
> Under some cirscumstances the hash chain can be circuited,
> and we get an infinite loop with disabled interrupts and locked hash
> lock in __find_stripe(). This leads to hard lockup on multiple CPUs
> and following system crash.
>
> I was able to reproduce this behavior on raid6 over 6 ssd disks.
> The devices_handle_discard_safely option should be set to enable trim
> support. The following script was used:
>
> for i in `seq 1 32`; do
> dd if=/dev/zero of=large$i bs=10M count=100 &
> done
>
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Neil Brown <neilb@suse.de>
> Cc: Shaohua Li <shli@kernel.org>
> Cc: linux-raid@vger.kernel.org
> Cc: <stable@vger.kernel.org> # 3.10 - 3.19
Hi Roman,
thanks for reporting this and providing a fix.
I'm a bit confused by that stable range: 3.10 - 3.19
The commit you identify as introducing the bug was added in 3.13, so
presumably 3.10, 3.11, 3.12 are not affected.
Also the bug is still present in mainline, so 4.0, 4.1, 4.2 are also
affected, though the patch needs to be revised a bit for 4.1 and later.
Does that match your understanding? Or is there something that I am
missing?
Thanks,
NeilBrown
> ---
> drivers/md/raid5.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index e421016..5fa7549 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -3060,6 +3060,8 @@ static void handle_stripe_clean_event(struct r5conf *conf,
> }
> if (!discard_pending &&
> test_bit(R5_Discard, &sh->dev[sh->pd_idx].flags)) {
> + int hash = sh->hash_lock_index;
> +
> clear_bit(R5_Discard, &sh->dev[sh->pd_idx].flags);
> clear_bit(R5_UPTODATE, &sh->dev[sh->pd_idx].flags);
> if (sh->qd_idx >= 0) {
> @@ -3073,9 +3075,9 @@ static void handle_stripe_clean_event(struct r5conf *conf,
> * no updated data, so remove it from hash list and the stripe
> * will be reinitialized
> */
> - spin_lock_irq(&conf->device_lock);
> + spin_lock_irq(conf->hash_locks + hash);
> remove_hash(sh);
> - spin_unlock_irq(&conf->device_lock);
> + spin_unlock_irq(conf->hash_locks + hash);
> if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
> set_bit(STRIPE_HANDLE, &sh->state);
>
> --
> 2.4.3
>
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH] raid5-cache: use crc32c checksum
From: Bart Van Assche @ 2015-10-28 22:46 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid, Kernel-team, songliubraving, hch, neilb
In-Reply-To: <20151028154124.GA439358@devbig084.prn1.facebook.com>
On 10/28/2015 08:41 AM, Shaohua Li wrote:
> crc32c has lower overhead with cpu acceleration. It's a shame I didn't
> use it in first post, sorry. This changes disk format, but we are still
> ok in current stage.
>
> V2: delete unnecessary type conversion as pointed out by Bart
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
^ permalink raw reply
* Re: Raid array name by mdadm
From: Sheng Yang @ 2015-10-28 22:01 UTC (permalink / raw)
To: Dragan Milivojević; +Cc: linux-raid
In-Reply-To: <CA+2rt40zrLoUuGhVcq2DxLiX39PRryeygFN=AZEu_5g0TwR=pQ@mail.gmail.com>
On Wed, Oct 28, 2015 at 2:40 PM, Sheng Yang <sheng@yasker.org> wrote:
> On Wed, Oct 28, 2015 at 12:56 PM, Dragan Milivojević
> <galileo@pkm-inc.com> wrote:
>>> I tried to create a raid using:
>>>
>>> # mdadm --create device-123 --verbose --level=mirror --raid-devices=2
>>> --name=device-123 /dev/sda /dev/sdb
>>> mdadm: Defaulting to version 1.2 metadata
>>> mdadm: array /dev/md/device-123 started.
>>>
>>> But what I got in the end is only /dev/md127. The directory of
>>> /dev/md/ doesn't exist.
>>
>>
>> try mdadm --create /dev/md/device-123,
>>
>> for example:
>>
>> truncate -s 512M disk0
>> truncate -s 512M disk1
>>
>> losetup /dev/loop0 disk0
>> losetup /dev/loop1 disk1
>>
>> mdadm --create /dev/md/device-123 --verbose --level=mirror
>> --raid-devices=2 /dev/loop0 /dev/loop1
>>
>> [root@eos ~]# ll /dev/md/device-123
>> lrwxrwxrwx 1 root root 8 Oct 28 20:53 /dev/md/device-123 -> ../md127
>>
>> [root@eos ~]# mdadm --detail --scan
>> ARRAY /dev/md/device-123 metadata=1.2 name=device-123
>> UUID=03ba5df7:7c5cc933:367e19ef:384665c5
>
> Thank Dragan! It works!
>
> Seems it's mdadm itself create the link rather than do through kernel,
> which gave me a little trouble. :D
Hi Dragan,
One more question if you don't mind:
When you do
mdadm --stop /dev/md/device-123
Would mdadm remove the broken link file /dev/md/device-123 automatically?
I found I have to remove the link file manually later...
--Sheng
>
> --Sheng
--
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: Raid array name by mdadm
From: Sheng Yang @ 2015-10-28 21:40 UTC (permalink / raw)
To: Dragan Milivojević; +Cc: linux-raid
In-Reply-To: <CALtW_agEVF9x83WP6GO0mJ9zjggS_7_9TJ5dJEdijmR8wHf49A@mail.gmail.com>
On Wed, Oct 28, 2015 at 12:56 PM, Dragan Milivojević
<galileo@pkm-inc.com> wrote:
>> I tried to create a raid using:
>>
>> # mdadm --create device-123 --verbose --level=mirror --raid-devices=2
>> --name=device-123 /dev/sda /dev/sdb
>> mdadm: Defaulting to version 1.2 metadata
>> mdadm: array /dev/md/device-123 started.
>>
>> But what I got in the end is only /dev/md127. The directory of
>> /dev/md/ doesn't exist.
>
>
> try mdadm --create /dev/md/device-123,
>
> for example:
>
> truncate -s 512M disk0
> truncate -s 512M disk1
>
> losetup /dev/loop0 disk0
> losetup /dev/loop1 disk1
>
> mdadm --create /dev/md/device-123 --verbose --level=mirror
> --raid-devices=2 /dev/loop0 /dev/loop1
>
> [root@eos ~]# ll /dev/md/device-123
> lrwxrwxrwx 1 root root 8 Oct 28 20:53 /dev/md/device-123 -> ../md127
>
> [root@eos ~]# mdadm --detail --scan
> ARRAY /dev/md/device-123 metadata=1.2 name=device-123
> UUID=03ba5df7:7c5cc933:367e19ef:384665c5
Thank Dragan! It works!
Seems it's mdadm itself create the link rather than do through kernel,
which gave me a little trouble. :D
--Sheng
--
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: 2nd Faulty drive while rebuilding array on RAID5
From: Guillaume ALLEE @ 2015-10-28 20:35 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <562D67E3.6050708@turmel.org>
Hi Phil,
Thanks for your answer. I have tested my sda3 with badblocks and it
seems really bad like 6 digits unreadable blocks...
> Something's missing. I see only sd[abcd]3. Where's the report for
> /dev/sde* ?
Yep because /dev/sde is not part of my /dec/md1 array.
"ARRAY /dev/md1 level=raid5 num-devices=4 metadata=00.90
UUID=426d71a2:5b25a168:a4e2eff2:d305f1c1
devices=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sdd3"
>
> Yes, you have WD20EARS and ST3000DM001 drive models. These are not safe
> to use in raid arrays due to lack of error recovery control.
Okay I will look at that for my next HDs.
> You need to stop the array and perform an '--assemble --force' with the
> last four devices (exclude /dev/sdc). The ones that have "Raid Device"
> 0, 1, 2, & 3.
Here is the assemble output.
#mdadm --assemble --force /dev/md1 /dev/sda3 /dev/sdb3 /dev/sdd3
mdadm: no recogniseable superblock on /dev/sda3
mdadm: /dev/sda3 has no superblock - assembly aborted
>
> If that fails, show mdadm's responses in your next reply.
> Phil
Thanks I will read those links
2015-10-26 0:38 GMT+01:00 Phil Turmel <philip@turmel.org>:
> Hi Guillaume,
>
> On 10/24/2015 06:27 PM, Guillaume ALLEE wrote:
>> 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...
>
> Unfortunately, you are suffering from classic timeout mismatch. I've
> put some links in the postscript for you to read. Most likely, your
> original sdc wasn't really bad.
>
> [trim /]
>
>> $ mdadm --examine /dev/sd[abcdefghijklmn]3 >> raid.status
>> http://pastebin.com/qaP8bvna
>
> Something's missing. I see only sd[abcd]3. Where's the report for
> /dev/sde* ?
>
> [trim /]
>
>> Full dmesg available at:
>> http://pastebin.com/bBfcYjkg
>
> Yes, you have WD20EARS and ST3000DM001 drive models. These are not safe
> to use in raid arrays due to lack of error recovery control.
>
>> Is there some way to re-add this disk (sda) in the array without mdadm
>> thinging it is a new one ?
>
> You need to stop the array and perform an '--assemble --force' with the
> last four devices (exclude /dev/sdc). The ones that have "Raid Device"
> 0, 1, 2, & 3.
>
> If that fails, show mdadm's responses in your next reply. If it works,
> your array will be available to mount, but degraded. You will not be
> able to add your new sdc to the array while there are unresolved UREs,
> so you will need to backup your important data from the degraded array.
> UREs can only be fixed by writing over them -- normally done
> automatically by MD with proper drives. You will have to overwrite
> those spots with zeroes or use dd_rescue to move the data to fresh
> drives (with zeroes in place of the unreadable spots).
>
>> 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.
>
> Do *NOT* recreate the array. (Unless you're starting over after backing
> up the files from the degraded array.)
>
> Phil
>
> [1] http://marc.info/?l=linux-raid&m=139050322510249&w=2
> [2] http://marc.info/?l=linux-raid&m=135863964624202&w=2
> [3] http://marc.info/?l=linux-raid&m=135811522817345&w=1
> [4] http://marc.info/?l=linux-raid&m=133761065622164&w=2
> [5] http://marc.info/?l=linux-raid&m=132477199207506
> [6] http://marc.info/?l=linux-raid&m=133665797115876&w=2
> [7] http://marc.info/?l=linux-raid&m=142487508806844&w=3
> [8] http://marc.info/?l=linux-raid&m=144535576302583&w=2
>
^ permalink raw reply
* Re: Raid array name by mdadm
From: Dragan Milivojević @ 2015-10-28 19:56 UTC (permalink / raw)
To: Sheng Yang; +Cc: linux-raid
In-Reply-To: <CA+2rt40JQcxv8CTw-+bpXDGFNorgS53B+thrkNeGN6B2JRQmBw@mail.gmail.com>
> I tried to create a raid using:
>
> # mdadm --create device-123 --verbose --level=mirror --raid-devices=2
> --name=device-123 /dev/sda /dev/sdb
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md/device-123 started.
>
> But what I got in the end is only /dev/md127. The directory of
> /dev/md/ doesn't exist.
try mdadm --create /dev/md/device-123,
for example:
truncate -s 512M disk0
truncate -s 512M disk1
losetup /dev/loop0 disk0
losetup /dev/loop1 disk1
mdadm --create /dev/md/device-123 --verbose --level=mirror
--raid-devices=2 /dev/loop0 /dev/loop1
[root@eos ~]# ll /dev/md/device-123
lrwxrwxrwx 1 root root 8 Oct 28 20:53 /dev/md/device-123 -> ../md127
[root@eos ~]# mdadm --detail --scan
ARRAY /dev/md/device-123 metadata=1.2 name=device-123
UUID=03ba5df7:7c5cc933:367e19ef:384665c5
^ permalink raw reply
* [PATCH] [mdadm] add crc32c and use it for r5l checksum
From: Song Liu @ 2015-10-28 19:06 UTC (permalink / raw)
To: linux-raid; +Cc: neilb, shli, hch, dan.j.williams, kernel-team, Song Liu
In kernel space, r5l checksum will use crc32c:
http://marc.info/?l=linux-raid&m=144598970529191
mdadm need to change too.
This patch ports a simplified crc32c algorithm from kernel code,
and used in super1.c:write_empty_r5l_meta_block();
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Shaohua Li <shli@fb.com>
---
Makefile | 2 +-
crc32c.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
super1.c | 11 +++----
3 files changed, 109 insertions(+), 8 deletions(-)
create mode 100644 crc32c.c
diff --git a/Makefile b/Makefile
index 544e6cb..fde2e63 100644
--- a/Makefile
+++ b/Makefile
@@ -133,7 +133,7 @@ OBJS = mdadm.o config.o policy.o mdstat.o ReadMe.o util.o maps.o lib.o \
mdopen.o super0.o super1.o super-ddf.o super-intel.o bitmap.o \
super-mbr.o super-gpt.o \
restripe.o sysfs.o sha1.o mapfile.o crc32.o sg_io.o msg.o xmalloc.o \
- platform-intel.o probe_roms.o
+ platform-intel.o probe_roms.o crc32c.o
CHECK_OBJS = restripe.o sysfs.o maps.o lib.o xmalloc.o dlink.o
diff --git a/crc32c.c b/crc32c.c
new file mode 100644
index 0000000..156cba1
--- /dev/null
+++ b/crc32c.c
@@ -0,0 +1,104 @@
+/*
+ * Oct 28, 2015 Song Liu simplified the code and port it to mdadm
+ *
+ * Aug 8, 2011 Bob Pearson with help from Joakim Tjernlund and George Spelvin
+ * cleaned up code to current version of sparse and added the slicing-by-8
+ * algorithm to the closely similar existing slicing-by-4 algorithm.
+ *
+ * Oct 15, 2000 Matt Domsch <Matt_Domsch@dell.com>
+ * Nicer crc32 functions/docs submitted by linux@horizon.com. Thanks!
+ * Code was from the public domain, copyright abandoned. Code was
+ * subsequently included in the kernel, thus was re-licensed under the
+ * GNU GPL v2.
+ *
+ * Oct 12, 2000 Matt Domsch <Matt_Domsch@dell.com>
+ * Same crc32 function was used in 5 other places in the kernel.
+ * I made one version, and deleted the others.
+ * There are various incantations of crc32(). Some use a seed of 0 or ~0.
+ * Some xor at the end with ~0. The generic crc32() function takes
+ * seed as an argument, and doesn't xor at the end. Then individual
+ * users can do whatever they need.
+ * drivers/net/smc9194.c uses seed ~0, doesn't xor with ~0.
+ * fs/jffs2 uses seed 0, doesn't xor with ~0.
+ * fs/partitions/efi.c uses seed ~0, xor's with ~0.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ */
+
+#include <sys/types.h>
+#include <asm/types.h>
+#include <stdlib.h>
+
+/*
+ * There are multiple 16-bit CRC polynomials in common use, but this is
+ * *the* standard CRC-32 polynomial, first popularized by Ethernet.
+ * x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0
+ */
+#define CRCPOLY_LE 0xedb88320
+#define CRCPOLY_BE 0x04c11db7
+
+/*
+ * This is the CRC32c polynomial, as outlined by Castagnoli.
+ * x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+
+ * x^8+x^6+x^0
+ */
+#define CRC32C_POLY_LE 0x82F63B78
+
+/**
+ * crc32_le_generic() - Calculate bitwise little-endian Ethernet AUTODIN II
+ * CRC32/CRC32C
+ * @crc: seed value for computation. ~0 for Ethernet, sometimes 0 for other
+ * uses, or the previous crc32/crc32c value if computing incrementally.
+ * @p: pointer to buffer over which CRC32/CRC32C is run
+ * @len: length of buffer @p
+ * @polynomial: CRC32/CRC32c LE polynomial
+ */
+static inline __u32 crc32_le_generic(__u32 crc, unsigned char const *p,
+ size_t len, __u32 polynomial)
+{
+ int i;
+ while (len--) {
+ crc ^= *p++;
+ for (i = 0; i < 8; i++)
+ crc = (crc >> 1) ^ ((crc & 1) ? polynomial : 0);
+ }
+ return crc;
+}
+
+__u32 crc32_le(__u32 crc, unsigned char const *p, size_t len)
+{
+ return crc32_le_generic(crc, p, len, CRCPOLY_LE);
+}
+
+__u32 crc32c_le(__u32 crc, unsigned char const *p, size_t len)
+{
+ return crc32_le_generic(crc, p, len, CRC32C_POLY_LE);
+}
+
+/**
+ * crc32_be_generic() - Calculate bitwise big-endian Ethernet AUTODIN II CRC32
+ * @crc: seed value for computation. ~0 for Ethernet, sometimes 0 for
+ * other uses, or the previous crc32 value if computing incrementally.
+ * @p: pointer to buffer over which CRC32 is run
+ * @len: length of buffer @p
+ * @polynomial: CRC32 BE polynomial
+ */
+static inline __u32 crc32_be_generic(__u32 crc, unsigned char const *p,
+ size_t len, __u32 polynomial)
+{
+ int i;
+ while (len--) {
+ crc ^= *p++ << 24;
+ for (i = 0; i < 8; i++)
+ crc =
+ (crc << 1) ^ ((crc & 0x80000000) ? polynomial :
+ 0);
+ }
+ return crc;
+}
+
+__u32 crc32_be(__u32 crc, unsigned char const *p, size_t len)
+{
+ return crc32_be_generic(crc, p, len, CRCPOLY_BE);
+}
diff --git a/super1.c b/super1.c
index 58e6f9d..1735c2d 100644
--- a/super1.c
+++ b/super1.c
@@ -1625,10 +1625,7 @@ static unsigned long choose_bm_space(unsigned long devsize)
static void free_super1(struct supertype *st);
#define META_BLOCK_SIZE 4096
-unsigned long crc32(
- unsigned long crc,
- const unsigned char *buf,
- unsigned len);
+__u32 crc32c_le(__u32 crc, unsigned char const *p, size_t len);
static int write_empty_r5l_meta_block(struct supertype *st, int fd)
{
@@ -1652,9 +1649,9 @@ static int write_empty_r5l_meta_block(struct supertype *st, int fd)
mb->seq = __cpu_to_le64(random32());
mb->position = __cpu_to_le64(0);
- crc = crc32(0xffffffff, sb->set_uuid, sizeof(sb->set_uuid));
- crc = crc32(crc, (void *)mb, META_BLOCK_SIZE);
- mb->checksum = __cpu_to_le32(crc);
+ crc = crc32c_le(0xffffffff, sb->set_uuid, sizeof(sb->set_uuid));
+ crc = crc32c_le(crc, (void *)mb, META_BLOCK_SIZE);
+ mb->checksum = crc;
if (lseek64(fd, (sb->data_offset) * 512, 0) < 0LL) {
pr_err("cannot seek to offset of the meta block\n");
--
2.4.6
^ permalink raw reply related
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