* Re: LVM RAID1 syncing component
From: Joe Lawrence @ 2014-12-01 21:19 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20141127074158.2a3472f3@notabene.brown>
On Thu, 27 Nov 2014 07:41:58 +1100
NeilBrown <neilb@suse.de> wrote:
> On Mon, 24 Nov 2014 23:07:32 -0500 Joe Lawrence <joe.lawrence@stratus.com>
> wrote:
>
> > Does anyone know how its possible to determine which side of an LVM RAID 1
> > is the stale partner during RAID resync?
> >
> > In ordinary MD RAID, I believe you can check
> > /sys/block/md0/md/dev-XXX/state,
>
> Why do you believe that?
>
> During a resync (after an unclean shutdown) the devices are indistinguishable.
> RAID1 reads all drives and if there is a difference it chooses one data block
> to write to the others - always the one with the lowest index number.
>
> So with md or LVM it is the same: first "first" is "copied" to the "second".
Hi Neil,
Here's a quick example of my thought-process, where md2 is an in-sync
RAID1 of sdq2 and sdr2 with an internal write bitmap:
% mdadm --fail /dev/md3 /dev/sdr2
% mdadm --remove /dev/md3 /dev/sdr2
[ ... File I/O to /dev/md3 ... ]
% mdadm -X /dev/sd[qr]2
Filename : /dev/sdq2
Magic : 6d746962
Version : 4
UUID : 073511ee:0b0c20e0:662ae8da:b53c7979
Events : 8526 << ECq
Events Cleared : 8498
State : OK
Chunksize : 64 MB
Daemon : 5s flush period
Write Mode : Normal
Sync Size : 16768896 (15.99 GiB 17.17 GB)
Bitmap : 256 bits (chunks), 5 dirty (2.0%)
Filename : /dev/sdr2
Magic : 6d746962
Version : 4
UUID : 073511ee:0b0c20e0:662ae8da:b53c7979
Events : 8513 << ECr
Events Cleared : 8498
State : OK
Chunksize : 64 MB
Daemon : 5s flush period
Write Mode : Normal
Sync Size : 16768896 (15.99 GiB 17.17 GB)
Bitmap : 256 bits (chunks), 5 dirty (2.0%)
[ Note that ECq > ECr, which makes sense since sdq was the remaining
disk standing in the RAID. ]
% mdadm --add /dev/md3 /dev/sdr2
% mdadm --detail /dev/md3
/dev/md3:
Version : 1.2
Creation Time : Thu Nov 13 15:47:19 2014
Raid Level : raid1
Array Size : 16768896 (15.99 GiB 17.17 GB)
Used Dev Size : 16768896 (15.99 GiB 17.17 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Dec 1 16:07:55 2014
State : active, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Rebuild Status : 0% complete
Name : dhcp-linux-2192-2025:3
UUID : 073511ee:0b0c20e0:662ae8da:b53c7979
Events : 8528
Number Major Minor RaidDevice State
0 65 2 0 active sync /dev/sdq2
1 65 18 1 spare rebuilding /dev/sdr2
% head /sys/block/md3/md/dev-sd*/state
==> /sys/block/md3/md/dev-sdq2/state <==
in_sync
==> /sys/block/md3/md/dev-sdr2/state <==
spare
In this scenario, sdr was re-added to the RAID and with a lower events-
cleared count. I assume that MD will only need to read the data
represented by the dirty bitmap bits from the "active sync" disk to the
"spare rebuilding" disk. Is this not the case?
Regards,
-- Joe
^ permalink raw reply
* Re: [PATCH 5/8 v2] dm: replace memset by memzero_explicit
From: Milan Broz @ 2014-12-01 21:03 UTC (permalink / raw)
To: Mike Snitzer
Cc: Julia Lawall, Alasdair Kergon, kernel-janitors, dm-devel,
Neil Brown, linux-raid, linux-kernel
In-Reply-To: <1417367029-32762-6-git-send-email-Julia.Lawall@lip6.fr>
On 11/30/2014 06:03 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Memset on a local variable may be removed when it is called just before the
> variable goes out of scope. Using memzero_explicit defeats this
> optimization. A simplified version of the semantic patch that makes this
> change is as follows: (http://coccinelle.lip6.fr/)
Ack, but I submitted the same patch a week ago....
https://www.redhat.com/archives/dm-devel/2014-November/msg00084.html
Mike, please could you add this to linux-next tree or you want this
to go through Herbert's tree?
(I do not think it is good idea for DM patches.)
Thanks,
Milan
>
> // <smpl>
> @@
> identifier x;
> type T;
> @@
>
> {
> ... when any
> T x[...];
> ... when any
> when exists
> - memset
> + memzero_explicit
> (x,
> -0,
> ...)
> ... when != x
> when strict
> }
> // </smpl>
>
> This change was suggested by Daniel Borkmann <dborkman@redhat.com>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> Daniel Borkmann suggested that these patches could go through Herbert Xu's
> cryptodev tree.
>
> v2: fixed email address
>
> drivers/md/dm-crypt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
> index fc93b93..08981be 100644
> --- a/drivers/md/dm-crypt.c
> +++ b/drivers/md/dm-crypt.c
> @@ -705,7 +705,7 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
> for (i = 0; i < ((1 << SECTOR_SHIFT) / 8); i++)
> crypto_xor(data + i * 8, buf, 8);
> out:
> - memset(buf, 0, sizeof(buf));
> + memzero_explicit(buf, sizeof(buf));
> return r;
> }
>
>
^ permalink raw reply
* Re: Split RAID: Proposal for archival RAID using incremental batch checksum
From: Anshuman Aggarwal @ 2014-12-01 16:34 UTC (permalink / raw)
To: NeilBrown; +Cc: Mdadm
In-Reply-To: <CAK-d5dY4QEDupxjkon_+6z0Z7ggPKv=PLF60zTkeSBsbd4+mPQ@mail.gmail.com>
On 1 December 2014 at 21:30, Anshuman Aggarwal
<anshuman.aggarwal@gmail.com> wrote:
> On 26 November 2014 at 11:54, Anshuman Aggarwal
> <anshuman.aggarwal@gmail.com> wrote:
>> On 25 November 2014 at 04:20, NeilBrown <neilb@suse.de> wrote:
>>> On Mon, 24 Nov 2014 12:59:47 +0530 Anshuman Aggarwal
>>> <anshuman.aggarwal@gmail.com> wrote:
>>>
>>>> On 3 November 2014 at 11:22, NeilBrown <neilb@suse.de> wrote:
>>>> > On Thu, 30 Oct 2014 20:30:40 +0530 Anshuman Aggarwal
>>>> > <anshuman.aggarwal@gmail.com> wrote:
>>>> >
>>>> >> Would chunksize==disksize work? Wouldn't that lead to the entire
>>>> >> parity be invalidated for any write to any of the disks (assuming md
>>>> >> operates at a chunk level)...also please see my reply below
>>>> >
>>>> > Operating at a chunk level would be a very poor design choice. md/raid5
>>>> > operates in units of 1 page (4K).
>>>>
>>>> It appears that my requirement may be met by a partitionable md raid 4
>>>> array where the partitions are all on individual underlying block
>>>> devices not striped across the block devices. Is that currently
>>>> possible with md raid? I dont' see how but such an enhancement could
>>>> do all that I had outlined earlier
>>>>
>>>> Is this possible to implement using RAID4 and MD already?
>>>
>>> Nearly. RAID4 currently requires the chunk size to be a power of 2.
>>> Rounding down the size of your drives to match that could waste nearly half
>>> the space. However it should work as a proof-of-concept.
>>>
>>> RAID0 supports non-power-of-2 chunk sizes. Doing the same thing for
>>> RAID4/5/6 would be quite possible.
>>>
>>>> can the
>>>> partitions be made to write to individual block devices such that
>>>> parity updates don't require reading all devices?
>>>
>>> md/raid4 will currently tries to minimize total IO requests when performing
>>> an update, but prefer spreading the IO over more devices if the total number
>>> of requests is the same.
>>>
>>> So for a 4-drive RAID4, Updating a single block can be done by:
>>> read old data block, read parity, write data, write parity - 4 IO requests
>>> or
>>> read other 2 data blocks, write data, write parity - 4 IO requests.
>>>
>>> In this case it will prefer the second, which is not what you want.
>>> With 5-drive RAID4, the second option will require 5 IO requests, so the first
>>> will be chosen.
>>> It is quite trivial to flip this default for testing
>>>
>>> - if (rmw < rcw && rmw > 0) {
>>> + if (rmw <= rcw && rmw > 0) {
>>>
>>>
>>> If you had 5 drives, you could experiment with no code changes.
>>> Make the chunk size the largest power of 2 that fits in the device, and then
>>> partition to align the partitions on those boundaries.
>>
>> If the chunk size is almost the same as the device size, I assume the
>> entire chunk is not invalidated for parity on writing to a single
>> block? i.e. if only 1 block is updated only that blocks parity will be
>> read and written and not for the whole chunk? If thats' the case, what
>> purpose does a chunk serve in md raid ? If that's not the case, it
>> wouldn't work because a single block updation would lead to parity
>> being written for the entire chunk, which is the size of the device
>>
>> I do have more than 5 drives though they are in use currently. I will
>> create a small testing partition on each device of the same size and
>> run the test on that after ensuring that the drives do go to sleep.
>>
>>>
>>> NeilBrown
>>>
>
> Wouldn't the meta data writes wake up all the disks in the cluster
> anyways (defeating the purpose)? This idea will require metadata to
> not be written out to each device (is that even possible or on the
> cards?)
>
> I am about to try out your suggestion with the chunk sizes anyways but
> thought about the metadata being a major stumbling block.
>
And it seems to be confirmed that the metadata write is waking up the
other drives. On any write to a particular drive the metadata update
is accessing all the others.
Am I correct in assuming that all metadata is currently written as
part of the block device itself and that the external metadata is
still embedded in each of the block devices (only the format of the
metadata is defined externally?) I guess to implement this we would
need to store metadata elsewhere which may be a major development
work. Still that may be a flexibility desired in md raid for other
reasons...
Neil, your thoughts.
>>
>> Thanks,
>> Anshuman
>>>
>>>>
>>>> To illustrate:
>>>> -----------------RAID - 4 ---------------------
>>>> |
>>>> Device 1 Device 2 Device 3 Parity
>>>> A1 B1 C1 P1
>>>> A2 B2 C2 P2
>>>> A3 B3 C3 P3
>>>>
>>>> Each device gets written to independently (via a layer of block
>>>> devices)...so Data on Device 1 is written as A1, A2, A3 contiguous
>>>> blocks leading to updation of P1, P2 P3 (without causing any reads on
>>>> devices 2 and 3 using XOR for the parity).
>>>>
>>>> In RAID4, IIUC data gets striped and all devices become a single block device.
>>>>
>>>>
>>>> >
>>>> >
>>>> >>
>>>> >> On 29 October 2014 14:55, Anshuman Aggarwal <anshuman.aggarwal@gmail.com> wrote:
>>>> >> > Right on most counts but please see comments below.
>>>> >> >
>>>> >> > On 29 October 2014 14:35, NeilBrown <neilb@suse.de> wrote:
>>>> >> >> Just to be sure I understand, you would have N + X devices. Each of the N
>>>> >> >> devices contains an independent filesystem and could be accessed directly if
>>>> >> >> needed. Each of the X devices contains some codes so that if at most X
>>>> >> >> devices in total died, you would still be able to recover all of the data.
>>>> >> >> If more than X devices failed, you would still get complete data from the
>>>> >> >> working devices.
>>>> >> >>
>>>> >> >> Every update would only write to the particular N device on which it is
>>>> >> >> relevant, and all of the X devices. So N needs to be quite a bit bigger
>>>> >> >> than X for the spin-down to be really worth it.
>>>> >> >>
>>>> >> >> Am I right so far?
>>>> >> >
>>>> >> > Perfectly right so far. I typically have a N to X ratio of 4 (4
>>>> >> > devices to 1 data) so spin down is totally worth it for data
>>>> >> > protection but more on that below.
>>>> >> >
>>>> >> >>
>>>> >> >> For some reason the writes to X are delayed... I don't really understand
>>>> >> >> that part.
>>>> >> >
>>>> >> > This delay is basically designed around archival devices which are
>>>> >> > rarely read from and even more rarely written to. By delaying writes
>>>> >> > on 2 criteria ( designated cache buffer filling up or preset time
>>>> >> > duration from last write expiring) we can significantly reduce the
>>>> >> > writes on the parity device. This assumes that we are ok to lose a
>>>> >> > movie or two in case the parity disk is not totally up to date but are
>>>> >> > more interested in device longevity.
>>>> >> >
>>>> >> >>
>>>> >> >> Sounds like multi-parity RAID6 with no parity rotation and
>>>> >> >> chunksize == devicesize
>>>> >> > RAID6 would present us with a joint device and currently only allows
>>>> >> > writes to that directly, yes? Any writes will be striped.
>>>> >
>>>> > If the chunksize equals the device size, then you need a very large write for
>>>> > it to be striped.
>>>> >
>>>> >> > In any case would md raid allow the underlying device to be written to
>>>> >> > directly? Also how would it know that the device has been written to
>>>> >> > and hence parity has to be updated? What about the superblock which
>>>> >> > the FS would not know about?
>>>> >
>>>> > No, you wouldn't write to the underlying device. You would carefully
>>>> > partition the RAID5 so each partition aligns exactly with an underlying
>>>> > device. Then write to the partition.
>>>> >
>>>> >> >
>>>> >> > Also except for the delayed checksum writing part which would be
>>>> >> > significant if one of the objectives is to reduce the amount of
>>>> >> > writes. Can we delay that in the code currently for RAID6? I
>>>> >> > understand the objective of RAID6 is to ensure data recovery and we
>>>> >> > are looking at a compromise in this case.
>>>> >
>>>> > "simple matter of programming"
>>>> > Of course there would be a limit to how much data can be buffered in memory
>>>> > before it has to be flushed out.
>>>> > If you are mostly storing movies, then they are probably too large to
>>>> > buffer. Why not just write them out straight away?
>>>> >
>>>> > NeilBrown
>>>> >
>>>> >
>>>> >
>>>> >> >
>>>> >> > If feasible, this can be an enhancement to MD RAID as well where N
>>>> >> > devices are presented instead of a single joint device in case of
>>>> >> > raid6 (maybe the multi part device can be individual disks?)
>>>> >> >
>>>> >> > It will certainly solve my problem of where to store the metadata. I
>>>> >> > was currently hoping to just store it as a configuration file to be
>>>> >> > read by the initramfs since in this case worst case scenario the
>>>> >> > checksum goes out of sync and is rebuilt from scratch.
>>>> >> >
>>>> >> >>
>>>> >> >> I wouldn't use device-mapper myself, but you are unlikely to get an entirely
>>>> >> >> impartial opinion from me on that topic.
>>>> >> >
>>>> >> > I haven't hacked around the kernel internals much so far so will have
>>>> >> > to dig out that history. I will welcome any particular links/mail
>>>> >> > threads I should look at for guidance (with both yours and opposing
>>>> >> > points of view)
>>>> >> --
>>>> >> 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
>>>> >
>>>> --
>>>> 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: Split RAID: Proposal for archival RAID using incremental batch checksum
From: Anshuman Aggarwal @ 2014-12-01 16:00 UTC (permalink / raw)
To: NeilBrown; +Cc: Mdadm
In-Reply-To: <CAK-d5dZnWpmyPfWTGB74wHojeywdiXDnT6Fs0yqYqn7bJpSL-Q@mail.gmail.com>
On 26 November 2014 at 11:54, Anshuman Aggarwal
<anshuman.aggarwal@gmail.com> wrote:
> On 25 November 2014 at 04:20, NeilBrown <neilb@suse.de> wrote:
>> On Mon, 24 Nov 2014 12:59:47 +0530 Anshuman Aggarwal
>> <anshuman.aggarwal@gmail.com> wrote:
>>
>>> On 3 November 2014 at 11:22, NeilBrown <neilb@suse.de> wrote:
>>> > On Thu, 30 Oct 2014 20:30:40 +0530 Anshuman Aggarwal
>>> > <anshuman.aggarwal@gmail.com> wrote:
>>> >
>>> >> Would chunksize==disksize work? Wouldn't that lead to the entire
>>> >> parity be invalidated for any write to any of the disks (assuming md
>>> >> operates at a chunk level)...also please see my reply below
>>> >
>>> > Operating at a chunk level would be a very poor design choice. md/raid5
>>> > operates in units of 1 page (4K).
>>>
>>> It appears that my requirement may be met by a partitionable md raid 4
>>> array where the partitions are all on individual underlying block
>>> devices not striped across the block devices. Is that currently
>>> possible with md raid? I dont' see how but such an enhancement could
>>> do all that I had outlined earlier
>>>
>>> Is this possible to implement using RAID4 and MD already?
>>
>> Nearly. RAID4 currently requires the chunk size to be a power of 2.
>> Rounding down the size of your drives to match that could waste nearly half
>> the space. However it should work as a proof-of-concept.
>>
>> RAID0 supports non-power-of-2 chunk sizes. Doing the same thing for
>> RAID4/5/6 would be quite possible.
>>
>>> can the
>>> partitions be made to write to individual block devices such that
>>> parity updates don't require reading all devices?
>>
>> md/raid4 will currently tries to minimize total IO requests when performing
>> an update, but prefer spreading the IO over more devices if the total number
>> of requests is the same.
>>
>> So for a 4-drive RAID4, Updating a single block can be done by:
>> read old data block, read parity, write data, write parity - 4 IO requests
>> or
>> read other 2 data blocks, write data, write parity - 4 IO requests.
>>
>> In this case it will prefer the second, which is not what you want.
>> With 5-drive RAID4, the second option will require 5 IO requests, so the first
>> will be chosen.
>> It is quite trivial to flip this default for testing
>>
>> - if (rmw < rcw && rmw > 0) {
>> + if (rmw <= rcw && rmw > 0) {
>>
>>
>> If you had 5 drives, you could experiment with no code changes.
>> Make the chunk size the largest power of 2 that fits in the device, and then
>> partition to align the partitions on those boundaries.
>
> If the chunk size is almost the same as the device size, I assume the
> entire chunk is not invalidated for parity on writing to a single
> block? i.e. if only 1 block is updated only that blocks parity will be
> read and written and not for the whole chunk? If thats' the case, what
> purpose does a chunk serve in md raid ? If that's not the case, it
> wouldn't work because a single block updation would lead to parity
> being written for the entire chunk, which is the size of the device
>
> I do have more than 5 drives though they are in use currently. I will
> create a small testing partition on each device of the same size and
> run the test on that after ensuring that the drives do go to sleep.
>
>>
>> NeilBrown
>>
Wouldn't the meta data writes wake up all the disks in the cluster
anyways (defeating the purpose)? This idea will require metadata to
not be written out to each device (is that even possible or on the
cards?)
I am about to try out your suggestion with the chunk sizes anyways but
thought about the metadata being a major stumbling block.
>
> Thanks,
> Anshuman
>>
>>>
>>> To illustrate:
>>> -----------------RAID - 4 ---------------------
>>> |
>>> Device 1 Device 2 Device 3 Parity
>>> A1 B1 C1 P1
>>> A2 B2 C2 P2
>>> A3 B3 C3 P3
>>>
>>> Each device gets written to independently (via a layer of block
>>> devices)...so Data on Device 1 is written as A1, A2, A3 contiguous
>>> blocks leading to updation of P1, P2 P3 (without causing any reads on
>>> devices 2 and 3 using XOR for the parity).
>>>
>>> In RAID4, IIUC data gets striped and all devices become a single block device.
>>>
>>>
>>> >
>>> >
>>> >>
>>> >> On 29 October 2014 14:55, Anshuman Aggarwal <anshuman.aggarwal@gmail.com> wrote:
>>> >> > Right on most counts but please see comments below.
>>> >> >
>>> >> > On 29 October 2014 14:35, NeilBrown <neilb@suse.de> wrote:
>>> >> >> Just to be sure I understand, you would have N + X devices. Each of the N
>>> >> >> devices contains an independent filesystem and could be accessed directly if
>>> >> >> needed. Each of the X devices contains some codes so that if at most X
>>> >> >> devices in total died, you would still be able to recover all of the data.
>>> >> >> If more than X devices failed, you would still get complete data from the
>>> >> >> working devices.
>>> >> >>
>>> >> >> Every update would only write to the particular N device on which it is
>>> >> >> relevant, and all of the X devices. So N needs to be quite a bit bigger
>>> >> >> than X for the spin-down to be really worth it.
>>> >> >>
>>> >> >> Am I right so far?
>>> >> >
>>> >> > Perfectly right so far. I typically have a N to X ratio of 4 (4
>>> >> > devices to 1 data) so spin down is totally worth it for data
>>> >> > protection but more on that below.
>>> >> >
>>> >> >>
>>> >> >> For some reason the writes to X are delayed... I don't really understand
>>> >> >> that part.
>>> >> >
>>> >> > This delay is basically designed around archival devices which are
>>> >> > rarely read from and even more rarely written to. By delaying writes
>>> >> > on 2 criteria ( designated cache buffer filling up or preset time
>>> >> > duration from last write expiring) we can significantly reduce the
>>> >> > writes on the parity device. This assumes that we are ok to lose a
>>> >> > movie or two in case the parity disk is not totally up to date but are
>>> >> > more interested in device longevity.
>>> >> >
>>> >> >>
>>> >> >> Sounds like multi-parity RAID6 with no parity rotation and
>>> >> >> chunksize == devicesize
>>> >> > RAID6 would present us with a joint device and currently only allows
>>> >> > writes to that directly, yes? Any writes will be striped.
>>> >
>>> > If the chunksize equals the device size, then you need a very large write for
>>> > it to be striped.
>>> >
>>> >> > In any case would md raid allow the underlying device to be written to
>>> >> > directly? Also how would it know that the device has been written to
>>> >> > and hence parity has to be updated? What about the superblock which
>>> >> > the FS would not know about?
>>> >
>>> > No, you wouldn't write to the underlying device. You would carefully
>>> > partition the RAID5 so each partition aligns exactly with an underlying
>>> > device. Then write to the partition.
>>> >
>>> >> >
>>> >> > Also except for the delayed checksum writing part which would be
>>> >> > significant if one of the objectives is to reduce the amount of
>>> >> > writes. Can we delay that in the code currently for RAID6? I
>>> >> > understand the objective of RAID6 is to ensure data recovery and we
>>> >> > are looking at a compromise in this case.
>>> >
>>> > "simple matter of programming"
>>> > Of course there would be a limit to how much data can be buffered in memory
>>> > before it has to be flushed out.
>>> > If you are mostly storing movies, then they are probably too large to
>>> > buffer. Why not just write them out straight away?
>>> >
>>> > NeilBrown
>>> >
>>> >
>>> >
>>> >> >
>>> >> > If feasible, this can be an enhancement to MD RAID as well where N
>>> >> > devices are presented instead of a single joint device in case of
>>> >> > raid6 (maybe the multi part device can be individual disks?)
>>> >> >
>>> >> > It will certainly solve my problem of where to store the metadata. I
>>> >> > was currently hoping to just store it as a configuration file to be
>>> >> > read by the initramfs since in this case worst case scenario the
>>> >> > checksum goes out of sync and is rebuilt from scratch.
>>> >> >
>>> >> >>
>>> >> >> I wouldn't use device-mapper myself, but you are unlikely to get an entirely
>>> >> >> impartial opinion from me on that topic.
>>> >> >
>>> >> > I haven't hacked around the kernel internals much so far so will have
>>> >> > to dig out that history. I will welcome any particular links/mail
>>> >> > threads I should look at for guidance (with both yours and opposing
>>> >> > points of view)
>>> >> --
>>> >> 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
>>> >
>>> --
>>> 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] dm space map metadata: fix sm_bootstrap_get_nr_blocks()
From: Joe Thornber @ 2014-12-01 13:56 UTC (permalink / raw)
To: Dan Carpenter
Cc: Alasdair Kergon, Mike Snitzer, dm-devel, Neil Brown, linux-raid,
Jörn Engel, kernel-janitors
In-Reply-To: <20141129125021.GD27251@mwanda>
Ack, thanks.
On Sat, Nov 29, 2014 at 03:50:21PM +0300, Dan Carpenter wrote:
> This function isn't right and it causes a static checker warning:
>
> drivers/md/dm-thin.c:3016 maybe_resize_data_dev()
> error: potentially using uninitialized 'sb_data_size'.
>
> It should set "*count" and return zero on success the same as the
> sm_metadata_get_nr_blocks() function does earlier.
>
> Fixes: 3241b1d3e0aa ('dm: add persistent data library')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Static checker stuff. Not tested.
>
> diff --git a/drivers/md/persistent-data/dm-space-map-metadata.c b/drivers/md/persistent-data/dm-space-map-metadata.c
> index 786b689..f4e22bc 100644
> --- a/drivers/md/persistent-data/dm-space-map-metadata.c
> +++ b/drivers/md/persistent-data/dm-space-map-metadata.c
> @@ -564,7 +564,9 @@ static int sm_bootstrap_get_nr_blocks(struct dm_space_map *sm, dm_block_t *count
> {
> struct sm_metadata *smm = container_of(sm, struct sm_metadata, sm);
>
> - return smm->ll.nr_blocks;
> + *count = smm->ll.nr_blocks;
> +
> + return 0;
> }
>
> static int sm_bootstrap_get_nr_free(struct dm_space_map *sm, dm_block_t *count)
^ permalink raw reply
* Re: upgrading a RAID array in-place with larger drives. request for review of my approach?
From: Phil Turmel @ 2014-12-01 13:47 UTC (permalink / raw)
To: terrygalant, John Stoffel; +Cc: linux-raid
In-Reply-To: <1417406691.1429321.197136309.39C9A098@webmail.messagingengine.com>
Good morning Terry,
On 11/30/2014 11:04 PM, terrygalant@mailbolt.com wrote:
> Hi John,
>
> On Sun, Nov 30, 2014, at 07:28 PM, John Stoffel wrote:
>> If you have the ability and the power and space in the chassis, i'd
>> just add in the four new drives, set them up in their RAID10 format,
>
> Unfortunately I don't. I have the 4 slots and thats it :-(
>
> If I did, it'd be pretty easy. But no. So that's why I'm trying to figure out how to do this right -- 'in place'.
You cannot --grow your array, as that isn't supported for the "far"
layout of raid10. Sorry. As you only have four slots, I recommend the
following convoluted procedure:
1) Get the new drives into the box w/ the existing array on the tail of
the space, as follows:
a) Partition new drive w/ 2T and 1T partitions, with the latter large
enough to serve as a member of the current array.
b) --fail and --remove the old disk.
c) Install the new disk, --add the 1T partition to your array.
d) Let it resync, then repeat for drives 2-4.
2) Create a new, growable array in the collection of 2T partitions.
With newer kernels, raid10,n2 should work. Experiment with that if you
aren't sure. Make sure you enable bitmaps.
3) Use pvcreate and vgextend to merge the new array into your existing
LVM setup.
4) Use pvmove to shift all of your volumes onto the new array.
5) Use vgreduce to drop the old array, then --stop it and destroy it.
6) Repartion each device to delete the 1T partitions and then resize the
2T over that space. Use --fail and --re-add to keep the array happy
with minimal disruption.
7) When all resyncing is done, --grow the array then use pvresize to
activate the space.
Enjoy!
Phil
^ permalink raw reply
* Re: upgrading a RAID array in-place with larger drives. request for review of my approach?
From: Wols Lists @ 2014-12-01 9:42 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <20141201090814.GA3772@cthulhu.home.robinhill.me.uk>
On 01/12/14 09:08, Robin Hill wrote:
> If it is doable (see comment above), it'll be simpler to just
> partition the disks to the final size (or skip partitioning at all)
> - md will quite happily accept larger devices added to an array
> (though it doesn't use the extra space). Otherwise, your initial
> steps are correct - though if you have a spare bay (or even a
> USB/SATA adapter), you can add the drive as a spare and then use
> "mdadm --replace" (you may need a newer version of mdadm for this)
> command to flag one of the existing array members for replacement.
> This will do a direct copy of the data from the existing disk to
> the new one and is quicker (and safer) than fail/add.
I upgraded a (raid 1) system by just adding the new, larger, disk. I
think I swapped a 500Gb for a 1TB, so replaced my 400Gb partitions
with 900Gb partitions. I then grew the array, followed by growing the
partition. Worked fine.
Cheers,
Wol
^ permalink raw reply
* Re: upgrading a RAID array in-place with larger drives. request for review of my approach?
From: Robin Hill @ 2014-12-01 9:08 UTC (permalink / raw)
To: terrygalant; +Cc: linux-raid
In-Reply-To: <1417402553.1412807.197119853.0D7A911E@webmail.messagingengine.com>
[-- Attachment #1: Type: text/plain, Size: 6742 bytes --]
On Sun Nov 30, 2014 at 06:55:53PM -0800, terrygalant@mailbolt.com wrote:
> Hi,
>
> I have a 4-drive RAID-10 array. I've been using mdadm for awhile to
> manage the array, and replace drives as they die without changing
> anything.
>
> Now, I want to increase its size in-place. I'd like to ask for some
> help with a review of my setup and plans on how to do it right.
>
> I'm really open to any advice that'll help me get there without
> blowing this all up!
>
> My array is
>
> cat /proc/mdstat
> ...
> md2 : active raid10 sdd1[1] sdc1[0] sde1[4] sdf1[3]
> 1953519616 blocks super 1.2 512K chunks 2 far-copies [4/4] [UUUU]
> bitmap: 0/466 pages [0KB], 2048KB chunk
> ...
>
A question was raised just recently about reshaping "far" RAID10 arrays.
Neil Brown (the md maintainer) said:
I recommend creating some loop-back block devices and experimenting.
But I'm fairly sure that "far" RAID10 arrays cannot be reshaped at all.
> it's comprised of 4 drives; each is 1TB physical size, partitioned
> with a single 'max size' partition, where that partition is formatted
> 'Linux raid autodetect'
>
> fdisk -l /dev/sd[cdef]
>
> Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00000000
>
> Device Boot Start End Sectors Size Id Type
> /dev/sdc1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
>
> Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00000000
>
> Device Boot Start End Sectors Size Id Type
> /dev/sdd1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
>
> Disk /dev/sde: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00000000
>
> Device Boot Start End Sectors Size Id Type
> /dev/sde1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
>
> Disk /dev/sdf: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00000000
>
> Device Boot Start End Sectors Size Id Type
> /dev/sdf1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
>
> the array contains only/multiple LVs, in a RAID-10 array size of 2TB,
>
> pvs /dev/md2
> PV VG Fmt Attr PSize PFree
> /dev/md2 VGBKUP lvm2 a-- 1.82t 45.56g
> vgs VGBKUP
> VG #PV #LV #SN Attr VSize VFree
> VGBKUP 1 8 0 wz--n- 1.82t 45.56g
> lvs VGBKUP
> LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
> LV001 VGBKUP -wi-ao--- 1.46t
> LV002 VGBKUP -wi-ao--- 300.00g
> LV003 VGBKUP -wi-ao--- 160.00m
> LV004 VGBKUP -wi-ao--- 12.00g
> LV005 VGBKUP -wi-ao--- 512.00m
> LV006 VGBKUP -wi-a---- 160.00m
> LV007 VGBKUP -wi-a---- 4.00g
> LV008 VGBKUP -wi-a---- 512.00m
>
> where, currently, ~45.56G of the phy dev is unused
>
> I've purchased 4 new 3TB drives.
>
> I want to upgrade the existing array of 4x1TB drives to 4x3TB drives.
>
> I want to end up with a single partition, @ max_size == ~ 3TB.
>
> I'd like to do this *in-place*, never bringing down the array.
>
> Iiuc, this IS doable.
>
> 1st, I think the following procedure starts the process correctly:
>
> (1) format each new 3TB drive, with one 1TB partition, as 'linux
> raid autodetect', making sure it's IDENTICAL to the partition layout
> on the current array's disks
>
> (2) with the current array up & running, mdadm FAIL one drive
>
> (3) mdadm remove the FAIL'd drive from the array
>
> (4) physically remove the FAIL'd drive
>
> (5) physically insert the new, pre-formatted 3TB drive
>
> (6) mdadm add the newly inserted drive
>
> (7) allow the array to rebuild, until 'cat /proc/mdstat' says it's done
>
> (8) repeat steps (2) - (7) for each of the three remaining drives.
>
> 2nd, I have to correctly/safely to, in 'some' order
>
> extend the physical partitions on all four drives, or of the array
> (not sure which)
> extend the volume group on the array
> expand, or add, the existing LVMs in the volume group.
>
> I'm really not sure about what steps, in what order to do *here*.
>
> Can anyone verify that my first part is right, and help me out with
> doing the 2nd part right?
>
If it is doable (see comment above), it'll be simpler to just partition
the disks to the final size (or skip partitioning at all) - md will
quite happily accept larger devices added to an array (though it doesn't
use the extra space). Otherwise, your initial steps are correct - though
if you have a spare bay (or even a USB/SATA adapter), you can add the
drive as a spare and then use "mdadm --replace" (you may need a newer
version of mdadm for this) command to flag one of the existing array
members for replacement. This will do a direct copy of the data from the
existing disk to the new one and is quicker (and safer) than fail/add.
You'll then need to grow the array, the volume group, then the LVMs.
As I say above, I think you're out of luck though. I'd recommend
connecting up one of the new drives (if you have a spare bay or can hook
it up externally, do so, otherwise you'll need to fail one of the array
members), then:
- Copy all the data over to the new disk
- Stop the old array
- Remove the old disks and insert the new ones
- Create a new array (with a missing member if you only have 4 bays)
- Copy the data off the single disk and onto the new array
- Add the single disk to the array as the final member
Cheers,
Robin
--
___
( ' } | Robin Hill <robin@robinhill.me.uk> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: upgrading a RAID array in-place with larger drives. request for review of my approach?
From: terrygalant @ 2014-12-01 4:04 UTC (permalink / raw)
To: John Stoffel; +Cc: linux-raid
In-Reply-To: <21627.57456.206853.819767@quad.stoffel.home>
Hi John,
On Sun, Nov 30, 2014, at 07:28 PM, John Stoffel wrote:
> If you have the ability and the power and space in the chassis, i'd
> just add in the four new drives, set them up in their RAID10 format,
Unfortunately I don't. I have the 4 slots and thats it :-(
If I did, it'd be pretty easy. But no. So that's why I'm trying to figure out how to do this right -- 'in place'.
Terry
^ permalink raw reply
* Re: upgrading a RAID array in-place with larger drives. request for review of my approach?
From: John Stoffel @ 2014-12-01 3:28 UTC (permalink / raw)
To: terrygalant; +Cc: linux-raid
In-Reply-To: <1417402553.1412807.197119853.0D7A911E@webmail.messagingengine.com>
Terry,
If you have the ability and the power and space in the chassis, i'd
just add in the four new drives, set them up in their RAID10 format,
then just do a 'pvmove' to migrate all our currently LVs from the old
1Tb RAID10 setup to the new one. No fuss, no muss and you can keep
the system online while doing it.
You will of course need to add in the new disks into the VG, but
that's simple to do. Once all the data is moved off the old disks,
you can then remove them from the VG and then shutdown the MD device
,and then remove the disks from the system.
Let me know if you need more details, I glossed over a bunch here.
John
^ permalink raw reply
* upgrading a RAID array in-place with larger drives. request for review of my approach?
From: terrygalant @ 2014-12-01 2:55 UTC (permalink / raw)
To: linux-raid
Hi,
I have a 4-drive RAID-10 array. I've been using mdadm for awhile to manage the array, and replace drives as they die without changing anything.
Now, I want to increase its size in-place. I'd like to ask for some help with a review of my setup and plans on how to do it right.
I'm really open to any advice that'll help me get there without blowing this all up!
My array is
cat /proc/mdstat
...
md2 : active raid10 sdd1[1] sdc1[0] sde1[4] sdf1[3]
1953519616 blocks super 1.2 512K chunks 2 far-copies [4/4] [UUUU]
bitmap: 0/466 pages [0KB], 2048KB chunk
...
it's comprised of 4 drives; each is 1TB physical size, partitioned with a single 'max size' partition, where that partition is formatted 'Linux raid autodetect'
fdisk -l /dev/sd[cdef]
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdc1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdd1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
Disk /dev/sde: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sde1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
Disk /dev/sdf: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdf1 63 1953520064 1953520002 931.5G fd Linux raid autodetect
the array contains only/multiple LVs, in a RAID-10 array size of 2TB,
pvs /dev/md2
PV VG Fmt Attr PSize PFree
/dev/md2 VGBKUP lvm2 a-- 1.82t 45.56g
vgs VGBKUP
VG #PV #LV #SN Attr VSize VFree
VGBKUP 1 8 0 wz--n- 1.82t 45.56g
lvs VGBKUP
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
LV001 VGBKUP -wi-ao--- 1.46t
LV002 VGBKUP -wi-ao--- 300.00g
LV003 VGBKUP -wi-ao--- 160.00m
LV004 VGBKUP -wi-ao--- 12.00g
LV005 VGBKUP -wi-ao--- 512.00m
LV006 VGBKUP -wi-a---- 160.00m
LV007 VGBKUP -wi-a---- 4.00g
LV008 VGBKUP -wi-a---- 512.00m
where, currently, ~45.56G of the phy dev is unused
I've purchased 4 new 3TB drives.
I want to upgrade the existing array of 4x1TB drives to 4x3TB drives.
I want to end up with a single partition, @ max_size == ~ 3TB.
I'd like to do this *in-place*, never bringing down the array.
Iiuc, this IS doable.
1st, I think the following procedure starts the process correctly:
(1) format each new 3TB drive, with one 1TB partition, as 'linux raid autodetect', making sure it's IDENTICAL to the partition layout on the current array's disks
(2) with the current array up & running, mdadm FAIL one drive
(3) mdadm remove the FAIL'd drive from the array
(4) physically remove the FAIL'd drive
(5) physically insert the new, pre-formatted 3TB drive
(6) mdadm add the newly inserted drive
(7) allow the array to rebuild, until 'cat /proc/mdstat' says it's done
(8) repeat steps (2) - (7) for each of the three remaining drives.
2nd, I have to correctly/safely to, in 'some' order
extend the physical partitions on all four drives, or of the array (not sure which)
extend the volume group on the array
expand, or add, the existing LVMs in the volume group.
I'm really not sure about what steps, in what order to do *here*.
Can anyone verify that my first part is right, and help me out with doing the 2nd part right?
Thanks a lot!
Terry
^ permalink raw reply
* [PATCH 5/8 v2] dm: replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 17:03 UTC (permalink / raw)
To: Alasdair Kergon
Cc: kernel-janitors, Mike Snitzer, dm-devel, Neil Brown, linux-raid,
linux-kernel
In-Reply-To: <1417367029-32762-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// </smpl>
This change was suggested by Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
v2: fixed email address
drivers/md/dm-crypt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index fc93b93..08981be 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -705,7 +705,7 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
for (i = 0; i < ((1 << SECTOR_SHIFT) / 8); i++)
crypto_xor(data + i * 8, buf, 8);
out:
- memset(buf, 0, sizeof(buf));
+ memzero_explicit(buf, sizeof(buf));
return r;
}
^ permalink raw reply related
* [PATCH 0/8] replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 17:03 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
sparclinux-u79uwXL29TY76Z2rM5mHXA,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)&x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)&x
... when any
when exists
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when != e
when strict
}
// ------------------------------------------------------------------------
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)&x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)&x
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when strict
}
// </smpl>
^ permalink raw reply
* [PATCH 5/8] dm: replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 16:59 UTC (permalink / raw)
To: Alasdair Kergon
Cc: dborkman, herbert, kernel-janitors, Mike Snitzer, dm-devel,
Neil Brown, linux-raid, linux-kernel, Julia Lawall
In-Reply-To: <1417366774-32412-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <julia@diku.dk>
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// </smpl>
This change was suggested by Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
drivers/md/dm-crypt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index fc93b93..08981be 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -705,7 +705,7 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
for (i = 0; i < ((1 << SECTOR_SHIFT) / 8); i++)
crypto_xor(data + i * 8, buf, 8);
out:
- memset(buf, 0, sizeof(buf));
+ memzero_explicit(buf, sizeof(buf));
return r;
}
^ permalink raw reply related
* [PATCH 0/8] replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 16:59 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: dborkman-H+wXaHxf7aLQT0dZR+AlfA,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
sparclinux-u79uwXL29TY76Z2rM5mHXA,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)&x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)&x
... when any
when exists
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when != e
when strict
}
// ------------------------------------------------------------------------
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)&x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)&x
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when strict
}
// </smpl>
^ permalink raw reply
* (unknown),
From: Mathias Burén @ 2014-11-30 13:54 UTC (permalink / raw)
To: Linux-RAID
Hi list,
Should I be worried? I'm not seeing this often, and ata6 seems to be
healthy. Message:
[236279.768693] INFO: task transmission-da:1050 blocked for more than
120 seconds.
[236279.768709] Not tainted 3.18.0-997-generic #201411142105
[236279.768720] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[236279.768735] transmission-da D f25fa780 0 1050 1 0x00000000
[236279.768738] f0717c78 00200086 00000000 f25fa780 00200246 aeadd839
0000d6b8 c15d1509
[236279.768741] f2584200 c1b532c0 f63b08c0 c1b532c0 f2584200 f6bcf2c0
efcae200 f3cbbd40
[236279.768744] f2d57200 f25fa780 f2d572a8 00200246 00000000 f0717c70
c160651f f0717c60
[236279.768747] Call Trace:
[236279.768753] [<c15d1509>] ? __dev_queue_xmit+0x1a9/0x480
[236279.768756] [<c160651f>] ? ip_finish_output+0x21f/0x4a0
[236279.768758] [<c1604430>] ? ip_forward_options+0x1f0/0x1f0
[236279.768762] [<c16cb173>] schedule+0x23/0x60
[236279.768765] [<c1256b57>] wait_transaction_locked+0x67/0x90
[236279.768768] [<c10976f0>] ? prepare_to_wait_event+0xd0/0xd0
[236279.768770] [<c1256cde>] add_transaction_credits+0x9e/0x1c0
[236279.768772] [<c1256fb7>] start_this_handle+0x117/0x280
[236279.768774] [<c12572a4>] ? jbd2__journal_start.part.7+0x24/0x180
[236279.768776] [<c12572f5>] jbd2__journal_start.part.7+0x75/0x180
[236279.768779] [<c114bef9>] ? get_page_from_freelist+0x1b9/0x3c0
[236279.768781] [<c1257463>] jbd2__journal_start+0x63/0x70
[236279.768784] [<c123f56c>] __ext4_journal_start_sb+0x5c/0xc0
[236279.768787] [<c1218624>] ? ext4_dirty_inode+0x34/0x60
[236279.768789] [<c1218624>] ext4_dirty_inode+0x34/0x60
[236279.768792] [<c11c7b25>] __mark_inode_dirty+0x35/0x270
[236279.768793] [<c114c23a>] ? __alloc_pages_nodemask+0x13a/0x910
[236279.768796] [<c11bb347>] update_time.part.13+0x57/0xa0
[236279.768798] [<c11bb3b5>] update_time+0x25/0x30
[236279.768799] [<c11bb439>] file_update_time+0x79/0xc0
[236279.768802] [<c1146a9a>] __generic_file_write_iter+0x17a/0x420
[236279.768805] [<c1199701>] ? memcg_check_events+0xb1/0xc0
[236279.768807] [<c120cc6d>] ext4_file_write_iter+0x11d/0x550
[236279.768810] [<c10bd339>] ? update_process_times+0x59/0x70
[236279.768813] [<c116e1a7>] ? __handle_mm_fault+0x1d7/0x290
[236279.768827] [<f920e560>] ? reada_start_machine_worker+0x10/0x130 [btrfs]
[236279.768829] [<c11a38ff>] new_sync_write+0x6f/0xb0
[236279.768830] [<c11a3890>] ? do_sync_readv_writev+0x90/0x90
[236279.768832] [<c11a42a6>] vfs_write+0xa6/0x1d0
[236279.768834] [<c11a47e3>] SyS_pwrite64+0x93/0xa0
[236279.768836] [<c16ce89f>] sysenter_do_call+0x12/0x12
[236279.768845] INFO: task md0_raid6:8494 blocked for more than 120 seconds.
[236279.768858] Not tainted 3.18.0-997-generic #201411142105
[236279.768869] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[236279.768883] md0_raid6 D 00000008 0 8494 2 0x00000000
[236279.768885] e78ade90 00000046 f6290000 00000008 e78ade30 d0750f81
0000d6b7 00000000
[236279.768888] f3733c17 c1b532c0 f63b08c0 c1b532c0 e78ade48 f6bbf2c0
e7b00620 c19daa40
[236279.768891] e7756010 f07c4600 e78ade90 c1563ad7 00000010 00000000
00001000 f70ee3e0
[236279.768894] Call Trace:
[236279.768897] [<c1563ad7>] ? write_sb_page+0x147/0x2c0
[236279.768899] [<c1097691>] ? prepare_to_wait_event+0x71/0xd0
[236279.768901] [<c16cb173>] schedule+0x23/0x60
[236279.768903] [<c155e79d>] md_super_wait+0x3d/0x70
[236279.768904] [<c10976f0>] ? prepare_to_wait_event+0xd0/0xd0
[236279.768907] [<c15657e7>] bitmap_unplug.part.24+0x117/0x120
[236279.768909] [<f89a6ff5>] ? __release_stripe+0x15/0x20 [raid456]
[236279.768911] [<c1565810>] bitmap_unplug+0x20/0x30
[236279.768914] [<f89b0b6d>] raid5d+0x9d/0x2a0 [raid456]
[236279.768915] [<c15587c4>] md_thread+0xe4/0x110
[236279.768917] [<c10976f0>] ? prepare_to_wait_event+0xd0/0xd0
[236279.768919] [<c15586e0>] ? md_rdev_init+0x100/0x100
[236279.768921] [<c107a76b>] kthread+0x9b/0xb0
[236279.768923] [<c16ce7c1>] ret_from_kernel_thread+0x21/0x30
[236279.768925] [<c107a6d0>] ? flush_kthread_worker+0x80/0x80
[236279.768926] INFO: task jbd2/md0-8:8521 blocked for more than 120 seconds.
[236279.768939] Not tainted 3.18.0-997-generic #201411142105
[236279.768950] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[236279.768964] jbd2/md0-8 D d0c8066c 0 8521 2 0x00000000
[236279.768966] e79d7e38 00000046 00000066 d0c8066c f6bcf308 f901623b
0000d6b7 e79d7de8
[236279.768968] c114e420 c1b532c0 f63b08c0 c1b532c0 43180010 f6bbf2c0
f0b34360 c19daa40
[236279.768971] 00000066 00000001 f6bcf308 003595ef 00000000 a6f6f9de
00000066 f6bcf308
[236279.768974] Call Trace:
[236279.768984] [<c114e420>] ? account_page_dirtied+0x90/0x100
[236279.768988] [<c108e406>] ? dequeue_task_fair+0x316/0x6b0
[236279.768990] [<c1088fcd>] ? sched_clock_cpu+0x10d/0x170
[236279.768992] [<c16cb173>] schedule+0x23/0x60
[236279.768994] [<c1259b41>] jbd2_journal_commit_transaction+0x1f1/0x1480
[236279.768996] [<c108c18f>] ? set_next_entity+0xbf/0xf0
[236279.768999] [<c100f95f>] ? __switch_to+0x10f/0x470
[236279.769001] [<c10976f0>] ? prepare_to_wait_event+0xd0/0xd0
[236279.769004] [<c125e0a0>] kjournald2+0xa0/0x210
[236279.769005] [<c10976f0>] ? prepare_to_wait_event+0xd0/0xd0
[236279.769007] [<c125e000>] ? commit_timeout+0x10/0x10
[236279.769009] [<c107a76b>] kthread+0x9b/0xb0
[236279.769010] [<c16ce7c1>] ret_from_kernel_thread+0x21/0x30
[236279.769012] [<c107a6d0>] ? flush_kthread_worker+0x80/0x80
[236279.769016] INFO: task kworker/u4:0:12352 blocked for more than 120 seconds.
[236279.769040] Not tainted 3.18.0-997-generic #201411142105
[236279.769063] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[236279.769100] kworker/u4:0 D 0b583c00 0 12352 2 0x00000000
[236279.769104] Workqueue: writeback bdi_writeback_workfn (flush-9:0)
[236279.769105] f07779b0 00000046 e78018d8 0b583c00 f0777948 d07347a2
0000d6b7 f89ac8d4
[236279.769108] f724a2e0 c1b532c0 f63b08c0 c1b532c0 f077797c f6bcf2c0
d0c80620 f25eee40
[236279.769110] c1564201 e7756000 c0055f48 f32f2600 f0777d34 f0777d44
f077799c f07779b0
[236279.769113] Call Trace:
[236279.769115] [<f89ac8d4>] ? raid5_unplug+0xc4/0x160 [raid456]
[236279.769117] [<c1564201>] ? bitmap_checkpage+0xb1/0x110
[236279.769120] [<c12fb623>] ? blk_flush_plug_list+0x83/0x1b0
[236279.769122] [<c16cb173>] schedule+0x23/0x60
[236279.769124] [<f89af45e>] get_active_stripe+0x24e/0x450 [raid456]
[236279.769126] [<f89accc6>] ? add_stripe_bio+0x356/0x410 [raid456]
[236279.769128] [<c10976f0>] ? prepare_to_wait_event+0xd0/0xd0
[236279.769130] [<f89b2631>] make_request+0x1a1/0x6a0 [raid456]
[236279.769132] [<c10976f0>] ? prepare_to_wait_event+0xd0/0xd0
[236279.769133] [<c1557a50>] md_make_request+0xc0/0x1e0
[236279.769136] [<c132a644>] ? radix_tree_lookup+0x14/0x20
[236279.769139] [<c12f6eb7>] generic_make_request.part.74+0x57/0x90
[236279.769141] [<c12f8edf>] generic_make_request+0x4f/0x60
[236279.769143] [<c12f8f5a>] submit_bio+0x6a/0x140
[236279.769145] [<c114d736>] ? account_page_writeback+0x26/0x30
[236279.769147] [<c1219470>] ext4_io_submit+0x20/0x40
[236279.769150] [<c12194c6>] io_submit_add_bh.isra.6+0x36/0x90
[236279.769152] [<c1219648>] ext4_bio_write_page+0xf8/0x1f0
[236279.769154] [<c1211dc9>] mpage_submit_page+0x89/0xc0
[236279.769156] [<c121225d>] mpage_map_and_submit_buffers+0x11d/0x200
[236279.769158] [<c121785d>] mpage_map_and_submit_extent+0x6d/0x290
[236279.769160] [<c1217f39>] ext4_writepages+0x4b9/0x6b0
[236279.769162] [<f89a6f1f>] ? do_release_stripe+0xaf/0x170 [raid456]
[236279.769165] [<c11c7385>] ? __writeback_single_inode+0x75/0x170
[236279.769167] [<c11c71b5>] ? write_inode+0x45/0xd0
[236279.769169] [<c114f261>] do_writepages+0x21/0x40
[236279.769171] [<c11c7348>] __writeback_single_inode+0x38/0x170
[236279.769173] [<c11c88a5>] writeback_sb_inodes+0x1c5/0x290
[236279.769175] [<c11c89e4>] __writeback_inodes_wb+0x74/0xa0
[236279.769178] [<c11c8c2a>] wb_writeback+0x21a/0x2b0
[236279.769180] [<c11c8e77>] wb_do_writeback+0x127/0x150
[236279.769182] [<c132f5fe>] ? vsnprintf+0x1be/0x3a0
[236279.769184] [<c11ca840>] bdi_writeback_workfn+0x70/0x1a0
[236279.769186] [<c10743d1>] ? pwq_dec_nr_in_flight+0x41/0x90
[236279.769187] [<c1075511>] process_one_work+0x121/0x3a0
[236279.769189] [<c1086da0>] ? default_wake_function+0x10/0x20
[236279.769191] [<c1075d20>] worker_thread+0xf0/0x370
[236279.769192] [<c109719f>] ? __wake_up_locked+0x1f/0x30
[236279.769194] [<c1075c30>] ? create_worker+0x1b0/0x1b0
[236279.769196] [<c107a76b>] kthread+0x9b/0xb0
[236279.769197] [<c16ce7c1>] ret_from_kernel_thread+0x21/0x30
[236279.769199] [<c107a6d0>] ? flush_kthread_worker+0x80/0x80
[236325.668648] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[236325.668688] ata6.00: failed command: FLUSH CACHE EXT
[236325.668711] ata6.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 26
[236325.668711] res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask
0x4 (timeout)
[236325.668771] ata6.00: status: { DRDY }
[236325.668792] ata6: hard resetting link
[236325.988624] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[236326.001713] ata6.00: configured for UDMA/133
[236326.001716] ata6.00: retrying FLUSH 0xea Emask 0x4
[236326.001775] ata6: EH complete
Details:
├scsi 6:0:0:0 ATA SAMSUNG HD204UI {S2H7JR0B501861}
│└sdc 1.82t [8:32] MD raid6 (6) inactive 'ion:md0'
{0ad2603e-e432-83ee-0218-077398e716ef}
│ ├sdc1 1.82t [8:33] MD raid6 (1/5) (w/ sda1,sdb1,sdd1,sde1) in_sync
'ion:0' {4cae433f-a40a-fcf5-f9ab-a91dd8217b69}
│ │└md0 5.45t [9:0] MD v1.2 raid6 (5) clean, 512k Chunk
{4cae433f:a40afcf5:f9aba91d:d8217b69}
│ │ ext4 '6TB_RAID6' {9e3c1fbe-8228-4b38-9047-66a5e2429e5f}
(unrelated, how do I clear old superblock off the block device without
messing with partitions or other superblocks?)
smartctl:
=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint F4 EG (AF)
Device Model: SAMSUNG HD204UI
Serial Number: S2H7JR0B501861
LU WWN Device Id: 5 0000f0 0500b6118
Firmware Version: 1AQ10001
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Sun Nov 30 13:54:40 2014 GMT
[....]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail
Always - 1
2 Throughput_Performance 0x0026 055 033 000 Old_age
Always - 19044
3 Spin_Up_Time 0x0023 067 065 025 Pre-fail
Always - 10188
4 Start_Stop_Count 0x0032 100 100 000 Old_age
Always - 76
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail
Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age
Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age
Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age
Always - 24173
10 Spin_Retry_Count 0x0032 252 252 051 Old_age
Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age
Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 68
181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age
Always - 3143559
191 G-Sense_Error_Rate 0x0022 252 252 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age
Always - 0
194 Temperature_Celsius 0x0002 064 052 000 Old_age
Always - 30 (Min/Max 12/48)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age
Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age
Always - 0
197 Current_Pending_Sector 0x0032 252 252 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age
Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age
Always - 6
223 Load_Retry_Count 0x0032 252 252 000 Old_age
Always - 0
225 Load_Cycle_Count 0x0032 100 100 000 Old_age
Always - 78
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 24089 -
# 2 Extended offline Completed without error 00% 24019 -
Regards
MAthias
--
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: LVM RAID1 syncing component
From: Peter Grandi @ 2014-11-29 15:26 UTC (permalink / raw)
To: Linux RAID
In-Reply-To: <20141127074158.2a3472f3@notabene.brown>
[ ... ]
> During a resync (after an unclean shutdown) the devices are
> indistinguishable. RAID1 reads all drives and if there is a
> difference it chooses one data block to write to the others -
> always the one with the lowest index number.
Uhhhhh "indistinguishable" and "lowest index number"?
Shouldn't that be "lowest index number among those with the
highest event count"?
Put another way, couldn't it happen that in a 5-way RAID1 for
example an unclean shutdown results in 2 drives with the same
highest event count and 3 drives with lower event counts, and
then the data page to write is that from the one of the 2 with
the lowest index number and is written only to the 3 with the
lower event count?
Also, in case of an «unclean shutdown» resulting in all members
of a RAID1 set having the same event count, is the resync still
done? Is it necessary? Or is «unclean shutdown» used here as an
alias for "not all event counts are the same".
I am asking as to what RAID1 actually does mostly, but also
perhaps as to what it ought to be doing.
--
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: Re:
From: Peter Grandi @ 2014-11-29 15:08 UTC (permalink / raw)
To: Linux RAID
In-Reply-To: <20141127074949.7d437769@notabene.brown>
>> I feel as though I must be missing something that I have had
>> no luck finding all morning.
Probably yes, ad the underlying insight is not explicitly
documented, it is left to the the reader of 'man mdadm.conf':
"spare-group= The value is a textual name for a group of
arrays. All arrays with the same spare-group name are
considered to be part of the same group.
The significance of a group of arrays is that mdadm will,
when monitoring the arrays, move a spare drive from one
array in a group to another array in that group if the first
array had a failed or missing drive but no spare."
>> When setting up arrays with spares in a spare-group, I'm
>> having no luck finding a way to get that information from
>> mdadm or mdstat. This becomes an issue when trying to write
>> out configs and the like,
> mdadm.conf is the primary location for spare-group
> information. When "mdadm --monitor" is run, it reads that
> file and uses that information.
A more detailed explanations is that MD RAID is divided in two
or arguably three components:
* MD kernel drivers: they *run* RAID sets, but not things like
*creating* them or *maintaining* them. The MD kernel drivers
only look at the MD member superblocks and do not look at
'mdadm.conf' or act of their own initiative in changing RAID
set membership, only the status of existing members listed in
the superblocks.
* User space command 'mdadm': this creates MD RAID sets by
writing "superblocks" that are recognized by the MD kernel
drivers, and can maintain them when the user does explicit
commands like '--add' or '--remove'. Options not provided on
the command line are taken from 'mdadm.conf'.
* User space daemon 'mdadm --monitor': this automatically issues
*some* 'mdadm' commands, based on the content of 'mdadm.conf'.
>> or simply trying to get a feel for how arrays are setup on a
>> system.
Specifically spare groups are not something that the MD kernel
drivers have any direct role in; the concept of "spare-group" is
only relevant to the 'mdadm --monitor' daemon.
Therefore as the reply above implies one cannot look at the
state of MD arrays as known to the kernel and figure out which
spares and MD arrays are in which spare group, it is something
that is handled entirely in user-space.
In recent version of MD RAID things get an additional dimension
of «how arrays are setup» in user-space as 'udev' too can be
configured to do things to MD RAID sets, which are described in
the 'POLICY' and related lines of 'mdadm.conf', and these too
are not recoverable from the information given by the MD kernel
drivers.
--
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
* [patch] dm space map metadata: fix sm_bootstrap_get_nr_blocks()
From: Dan Carpenter @ 2014-11-29 12:50 UTC (permalink / raw)
To: Alasdair Kergon, Joe Thornber
Cc: Mike Snitzer, dm-devel, Neil Brown, linux-raid, Jörn Engel,
kernel-janitors
This function isn't right and it causes a static checker warning:
drivers/md/dm-thin.c:3016 maybe_resize_data_dev()
error: potentially using uninitialized 'sb_data_size'.
It should set "*count" and return zero on success the same as the
sm_metadata_get_nr_blocks() function does earlier.
Fixes: 3241b1d3e0aa ('dm: add persistent data library')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Static checker stuff. Not tested.
diff --git a/drivers/md/persistent-data/dm-space-map-metadata.c b/drivers/md/persistent-data/dm-space-map-metadata.c
index 786b689..f4e22bc 100644
--- a/drivers/md/persistent-data/dm-space-map-metadata.c
+++ b/drivers/md/persistent-data/dm-space-map-metadata.c
@@ -564,7 +564,9 @@ static int sm_bootstrap_get_nr_blocks(struct dm_space_map *sm, dm_block_t *count
{
struct sm_metadata *smm = container_of(sm, struct sm_metadata, sm);
- return smm->ll.nr_blocks;
+ *count = smm->ll.nr_blocks;
+
+ return 0;
}
static int sm_bootstrap_get_nr_free(struct dm_space_map *sm, dm_block_t *count)
^ permalink raw reply related
* Re: mdadm raid5 single drive fail, single drive out of sync terror
From: Robison, Jon (CMG-Atlanta) @ 2014-11-28 17:00 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <20141126154922.GA12222@cthulhu.home.robinhill.me.uk>
Thanks Robin and Phil, mdadm 3.3.2 did allow successful forced
reassemble (had to run the command twice for whatever reason, first
execution said 4 aren't enough drives). I am updating my backup but
already retrieved the things of high value. I consider this mission
accomplished already.
Next steps I will take: backup -> fsck -> backup -> add missing disk ->
add more automation to main and backup -> profit
On 11/26/14 10:49 AM, Robin Hill wrote:
> On Wed Nov 26, 2014 at 10:08:12AM -0500, Jon Robison wrote:
>
>> Hi all!
>>
>> I upgraded to mdadm-3.3-7.fc20.x86_64, and my raid5 array would no
>> longer recognize /dev/sdb1 in my raid 5 array (which is normally
>> /dev/sd[b-f]1). I `mdadm --detail --scan`, which resulted in a degraded
>> array, then added /dev/sdb1, and it started rebuilding happily until 25%
>> or so, when another failure seemed to occur.
>>
>> I am convinced the data is fine on /dev/sd[c-f]1, and that somehow I
>> just need to inform mdadm about that, but they got out of sync and
>> /dev/sde1 thinks the array is AAAAA while the others think its AAA.. .
>> The drives also seem to think e is bad because f said e was bad or some
>> weird stuff, and sde1 is behind by ~50 events or so. That error hasn't
>> shown itself recently. I fear sdb is bad and sde is going to go soon.
>>
>> Results of `mdadm --examine /dev/sd[b-f]1` are here
>> http://dpaste.com/2Z7CPVY
>>
>> I'm scared and alone. Everything is off and sitting as above, though e
>> 50 events behind and out of synch. New drives coming Friday and backup
>> is of course a bit old. I'm petrified to execute `mdadm --create
>> --assume-clean --level=5 --raid-devices=5 /dev/md0 /dev/sdf1 /dev/sdd1
>> /dev/sdc1 /dev/sde1 missing`, but that seems my next option unless ya'll
>> know better. I tried `mdadm --assemble -f /dev/md0 /dev/sdf1 /dev/sdd1
>> /dev/sdc1 /dev/sde1` and it said something like can't start with only 3
>> devices (which I wouldn't expect because examine still shows 4, just
>> that they are out of sync and I thought that was -f's express purpose in
>> assemble mode). Anyone have any suggestions? Thanks!
> It looks like this is a bug in 3.3 (the checkin logs show something
> similar anyway). I'd advise getting 3.3.1 or 3.3.2 and retrying the
> forced assembly.
>
> If it failed during the rebuild, that would suggest there's an
> unreadable block on sde though, which means you'll hit the same issue
> again when you try to rebuild sdb. You'll need to:
> - image sde to a new disk (via ddrescue)
> - assemble the array
> - add another new disk in to rebuild
> - once the rebuild has completed, force a fsck on the array
> (fsck -f /dev/md0) as the unreadable block may have caused some
> filesystem corruption. It may also cause some file corruption, but
> that's not something that can be easily checked.
>
> These read errors can be picked up and fixed by running regular array
> checks (echo check > /sys/block/md0/md/sync_action). Most distributions
> have these set up in cron, so make sure that's in there and enabled.
>
> The failed disks may actually be okay (sde particularly), so I'd advise
> checking SMART stats and running full badblocks write tests on them. If
> the badblocks tests run okay and there's no increase in reallocated
> sectors reported in SMART, they should be perfectly okay for re-use.
>
> Cheers,
> Robin
^ permalink raw reply
* [PATCH] Grow: Fix wrong 'goto' in set_new_data_offset
From: Pawel Baldysiak @ 2014-11-27 11:35 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, pawel.baldysiak, artur.paszkiewicz
Commit a821c95f114724b38df1ea99b2858178e0ed28ce
besides introducing additional message, also changed
direct return to "goto" instruction.
'goto release' will cause routine to return with '-1',
when previously '1' was returned.
Described behaviour breaks e.g. IMSM reshape process.
This patch fixes this issue by changing 'goto' to proper one -
the one that returns '1'.
Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
---
Grow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Grow.c b/Grow.c
index a0f7526..6ff225a 100644
--- a/Grow.c
+++ b/Grow.c
@@ -2257,7 +2257,7 @@ static int set_new_data_offset(struct mdinfo *sra, struct supertype *st,
/* Metadata doesn't support data_offset changes */
pr_err("%s: Metadata version doesn't support"
" data_offset changes\n", devname);
- goto release;
+ goto fallback;
}
if (before > info2.space_before)
before = info2.space_before;
^ permalink raw reply related
* Re: One question about man mdadm
From: Xiao Ni @ 2014-11-27 7:52 UTC (permalink / raw)
To: Carsten Aulbert; +Cc: linux-raid
In-Reply-To: <5476D3C3.3000108@aei.mpg.de>
----- Original Message -----
> From: "Carsten Aulbert" <Carsten.Aulbert@aei.mpg.de>
> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
> Sent: Thursday, November 27, 2014 3:33:23 PM
> Subject: Re: One question about man mdadm
>
> Hi
>
> On 11/27/2014 08:27 AM, Xiao Ni wrote:
> > It says "See md(4) for more detail about ’near’, ’offset’, and
> > ’far’"
> > What's md(4) mean? Where can I find the detail information about this?
> >
>
> That's just the short form of, please see man-page about md from section
> 4. On the command line
>
> man 4 md
>
> and it should show something like
>
>
>
>
Yes. Thanks for the reply.
Xiao
--
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: One question about man mdadm
From: XiaoNi @ 2014-11-27 7:35 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1267277039.5310948.1417073236902.JavaMail.zimbra@redhat.com>
On 11/27/2014 03:27 PM, Xiao Ni wrote:
> Hi all
>
> I'm trying to learn about the layout about raid10. I read
> the man about mdadm.
>
> It says "See md(4) for more detail about ’near’, ’offset’, and ’far’"
> What's md(4) mean? Where can I find the detail information about this?
>
> Best Regards
> Xiao
> --
> 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
I got it. :)
it means man md 4
Xiao
--
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: One question about man mdadm
From: Carsten Aulbert @ 2014-11-27 7:33 UTC (permalink / raw)
To: Xiao Ni, linux-raid
In-Reply-To: <1267277039.5310948.1417073236902.JavaMail.zimbra@redhat.com>
Hi
On 11/27/2014 08:27 AM, Xiao Ni wrote:
> It says "See md(4) for more detail about ’near’, ’offset’, and ’far’"
> What's md(4) mean? Where can I find the detail information about this?
>
That's just the short form of, please see man-page about md from section
4. On the command line
man 4 md
and it should show something like
NAME
md - Multiple Device driver aka Linux Software RAID
SYNOPSIS
/dev/mdn
/dev/md/n
/dev/md/name
DESCRIPTION
The md driver provides virtual devices that are created from
one or more independent underlying devices. This array of devices often
contains redundancy and
the devices are often disk drives, hence the acronym RAID which
stands for a Redundant Array of Independent Disks.
[...]
Alternatively, first hit with most search engines:
http://linux.die.net/man/4/md
Cheers
Carsten
--
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
* One question about man mdadm
From: Xiao Ni @ 2014-11-27 7:27 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <2101015878.5310500.1417073140617.JavaMail.zimbra@redhat.com>
Hi all
I'm trying to learn about the layout about raid10. I read
the man about mdadm.
It says "See md(4) for more detail about ’near’, ’offset’, and ’far’"
What's md(4) mean? Where can I find the detail information about this?
Best Regards
Xiao
--
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
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