* [PATCH v5 0/3] Badblock tracking for gendisks
From: Vishal Verma @ 2015-12-25 2:20 UTC (permalink / raw)
To: linux-nvdimm
Cc: Vishal Verma, linux-block, linux-raid, linux-scsi, Jens Axboe,
NeilBrown, Jeff Moyer, Dan Williams
v5:
- Rebase to v4.4-rc6
- Revert back to using kzalloc from __get_free_page based on the discussion at:
http://thread.gmane.org/gmane.linux.kernel/2113292
v4:
- Rebase to v4.4-rc4
v3:
- Add kernel-doc style comments to all exported functions in badblocks.c (James)
- Make return values from badblocks functions consistent with themselves
and the kernel style. Change the polarity of badblocks_set, and update
all callers accordingly (James)
- In gendisk, don't unconditionally allocate badblocks, export the initializer.
This also allows the initializer to be a non-void return type, so that the
badblocks user can act upon failures better (James)
v2:
- In badblocks_free, make 'page' NULL (patch 1)
- Move the core badblocks code to a new .c file (patch 1) (Jens)
- Fix a sizeof usage in disk_alloc_badblocks (patch 2) (Dan)
- Since disk_alloc_badblocks can fail, check disk->bb for NULL in the
genhd wrappers (patch 2) (Jeff)
- Update the md conversion to also ise the badblocks init and free
functions (patch 3)
- Remove the BB_* macros from md.h as they are now in badblocks.h (patch 3)
Patch 1 copies badblock management code into a header of its own,
making it generally available. It follows common libraries of code
such as linked lists, where anyone may embed a core data structure
in another place, and use the provided accessor functions to
manipulate the data.
Patch 2 adds badblock tracking to gendisks (in preparation for use
by NVDIMM devices).
Patch 3 converts md over to use the new badblocks 'library'. I have
done some pretty simple testing on this - created a raid 1 device,
made sure the sysfs entries show up, and can be used to add and view
badblocks. A closer look by the md folks would be nice here.
Vishal Verma (3):
badblocks: Add core badblock management code
block: Add badblock management for gendisks
md: convert to use the generic badblocks code
block/Makefile | 2 +-
block/badblocks.c | 561 ++++++++++++++++++++++++++++++++++++++++++++++
block/genhd.c | 76 +++++++
drivers/md/md.c | 516 +++---------------------------------------
drivers/md/md.h | 40 +---
include/linux/badblocks.h | 53 +++++
include/linux/genhd.h | 7 +
7 files changed, 726 insertions(+), 529 deletions(-)
create mode 100644 block/badblocks.c
create mode 100644 include/linux/badblocks.h
--
2.5.0
^ permalink raw reply
* [GIT PULL REQUEST] one more md fix for 4.4-rc
From: NeilBrown @ 2015-12-24 3:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-raid, LKML, Xiao Ni
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
The following changes since commit 9f7e43278605a0daf4edf7025c52c25e9ace6875:
Merge tag 'rtc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux (2015-12-20 10:01:11 -0800)
are available in the git repository at:
git://neil.brown.name/md tags/md/4.4-rc6-fix
for you to fetch changes up to 312045eef985b61d74c28047ecd8eca6719d9516:
md: remove check for MD_RECOVERY_NEEDED in action_store. (2015-12-21 11:10:06 +1100)
----------------------------------------------------------------
One for md fix for 4.4-rc
Fix a regression which causes reshape to not start properly
sometimes.
----------------------------------------------------------------
NeilBrown (1):
md: remove check for MD_RECOVERY_NEEDED in action_store.
drivers/md/md.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] imsm: abort reshape if sync_action is not "reshape"
From: NeilBrown @ 2015-12-23 23:04 UTC (permalink / raw)
Cc: linux-raid, Artur Paszkiewicz
In-Reply-To: <1450871831-25452-2-git-send-email-artur.paszkiewicz@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
On Wed, Dec 23 2015, Artur Paszkiewicz wrote:
> When reshape was interrupted, an incorrect checkpoint would be saved in
> the migration record. Change wait_for_reshape_imsm() to return -1 when
> sync_action is not "reshape" to abort early in imsm_manage_reshape()
> without writing the migration record.
>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> super-intel.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/super-intel.c b/super-intel.c
> index e609e0c..c7efa98 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -10300,8 +10300,10 @@ int wait_for_reshape_imsm(struct mdinfo *sra, int ndata)
> sysfs_wait(fd, NULL);
> if (sysfs_get_str(sra, NULL, "sync_action",
> action, 20) > 0 &&
> - strncmp(action, "reshape", 7) != 0)
> - break;
> + strncmp(action, "reshape", 7) != 0) {
> + close(fd);
> + return -1;
> + }
> if (sysfs_fd_get_ll(fd, &completed) < 0) {
> dprintf("cannot read reshape_position (in loop)\n");
> close(fd);
> --
Applied, thanks.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Grow: close file descriptor earlier to avoid "still in use" when stopping
From: NeilBrown @ 2015-12-23 23:00 UTC (permalink / raw)
Cc: linux-raid, Artur Paszkiewicz, Pawel Baldysiak
In-Reply-To: <1450871831-25452-1-git-send-email-artur.paszkiewicz@intel.com>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Wed, Dec 23 2015, Artur Paszkiewicz wrote:
> Close fd2 as soon as it is no longer needed, before calling
> Grow_continue(). Otherwise, we won't be able to stop an array with
> external metadata during reshape, because mdadm running in background
> will be keeping it open.
>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
> ---
> Grow.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Grow.c b/Grow.c
> index 80d7b22..f65b36a 100644
> --- a/Grow.c
> +++ b/Grow.c
> @@ -4873,6 +4873,9 @@ int Grow_continue_command(char *devname, int fd,
>
> sysfs_init(content, fd2, mdstat->devnm);
>
> + close(fd2);
> + fd2 = -1;
> +
> /* start mdmon in case it is not running
> */
> if (!mdmon_running(container))
applied, thanks.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: RAID10 Write Performance
From: NeilBrown @ 2015-12-23 22:58 UTC (permalink / raw)
To: Marc Smith; +Cc: linux-raid
In-Reply-To: <CAHkw+LcTafoUeXbw8rdUwFi5a1oW=q-6uosa1uzaFjiYDYneaA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]
On Thu, Dec 24 2015, Marc Smith wrote:
> Okay, thanks, I'll turn it back on and try some different chunk sizes.
>
> For my own knowledge, why/what is taking place under the covers that
> causes this behavior? When testing with fio, it sometimes takes 1-2
> minutes of "ramp up time" before the performance numbers are
> good/expected (when the write-intent bitmap is enabled).
>
Whenever md needs to write to a region (a bitmap-chunk) of the array
that it hasn't written to recently, it needs to set a bit and write out
the bitmap first. It tries to gather multiple writes together and set
several bits at once, but a synchronous workload will defeat that.
Once the bit is set it will stay set until several seconds after the
last write. I think it defaults to 5 seconds.
mdadm -X /dev/some-component
will list it as 'daemon sleep'.
So the delay you are seeing is the time it takes to get all of those
bits set. 1 minute does sound like a long time, though it the writes
are synchronous that would easily explain it.
With a larger chunk size, there are fewer bits to set so fewer time that
the drives need to seek to the other end of the disk to write out the
bitmap.
If you run "watch -n 0.1 mdadm -X /dev/something" in a window it will
report how many bits are set moment by moment. That might give you some
feel for what is happening.
NeilBrown
>
> Thanks,
>
> Marc
>
>
> On Tue, Dec 22, 2015 at 9:20 PM, NeilBrown <neilb@suse.com> wrote:
>> On Wed, Dec 23 2015, Marc Smith wrote:
>>
>>> Solved... appears it was the write-intent bitmap that caused the
>>> performance issues. I discovered if I left the test running longer
>>> than 60 seconds, the performance would eventually climb to where I'd
>>> expect it. I ran 'mdadm --grow --bitmap=none /dev/md0' and now random
>>> write performance is high/good/stable right off the bat.
>>
>> Keeping a write-intent bitmap really is a good idea.
>> Using a larger bitmap chunk size can reduce the performance penalty and
>> preserve much of the value. It is easy enough to experiment with
>> different sizes.
>>
>> NeilBrown
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: raid5 async_xor: sleep in atomic
From: Dan Williams @ 2015-12-23 22:46 UTC (permalink / raw)
To: NeilBrown; +Cc: Stanislav Samsonov, linux-raid
In-Reply-To: <87d1tw23jk.fsf@notabene.neil.brown.name>
On Wed, Dec 23, 2015 at 2:39 PM, NeilBrown <neilb@suse.com> wrote:
> On Thu, Dec 24 2015, Dan Williams wrote:
>>> Changing the GFP_NOIO to GFP_ATOMIC in all the calls to
>>> dmaengine_get_unmap_data() in crypto/async_tx/ would probably fix the
>>> issue... or make it crash even worse :-)
>>>
>>> Dan: do you have any wisdom here? The xor is using the percpu data in
>>> raid5, so it cannot be sleep, but GFP_NOIO allows sleep.
>>> Does the code handle failure to get_unmap_data() safely? It looks like
>>> it probably does.
>>
>> Those GFP_NOIO should move to GFP_NOWAIT. We don't want GFP_ATOMIC
>> allocations to consume emergency reserves for a performance
>> optimization. Longer term async_tx needs to be merged into md
>> directly as we can allocate this unmap data statically per-stripe
>> rather than per request. This asyntc_tx re-write has been on the todo
>> list for years, but never seems to make it to the top.
>
> So the following maybe?
> If I could get an acked-by from you Dan, and a Tested-by: from you
> Slava, I'll submit upstream.
>
> Thanks,
> NeilBrown
>
> From: NeilBrown <neilb@suse.com>
> Date: Thu, 24 Dec 2015 09:35:18 +1100
> Subject: [PATCH] async_tx: use GFP_NOWAIT rather than GFP_IO
>
> These async_XX functions are called from md/raid5 in an atomic
> section, between get_cpu() and put_cpu(), so they must not sleep.
> So use GFP_NOWAIT rather than GFP_IO.
>
> Dan Williams writes: Longer term async_tx needs to be merged into md
> directly as we can allocate this unmap data statically per-stripe
> rather than per request.
>
> Reported-by: Stanislav Samsonov <slava@annapurnalabs.com>
> Signed-off-by: NeilBrown <neilb@suse.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
^ permalink raw reply
* Re: raid5 async_xor: sleep in atomic
From: NeilBrown @ 2015-12-23 22:39 UTC (permalink / raw)
To: Dan Williams; +Cc: Stanislav Samsonov, linux-raid
In-Reply-To: <CAPcyv4im63odabZ_gMF_ESuv=iZ7fyBYqLzXJDPe4cBRwtdG4g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4947 bytes --]
On Thu, Dec 24 2015, Dan Williams wrote:
>> Changing the GFP_NOIO to GFP_ATOMIC in all the calls to
>> dmaengine_get_unmap_data() in crypto/async_tx/ would probably fix the
>> issue... or make it crash even worse :-)
>>
>> Dan: do you have any wisdom here? The xor is using the percpu data in
>> raid5, so it cannot be sleep, but GFP_NOIO allows sleep.
>> Does the code handle failure to get_unmap_data() safely? It looks like
>> it probably does.
>
> Those GFP_NOIO should move to GFP_NOWAIT. We don't want GFP_ATOMIC
> allocations to consume emergency reserves for a performance
> optimization. Longer term async_tx needs to be merged into md
> directly as we can allocate this unmap data statically per-stripe
> rather than per request. This asyntc_tx re-write has been on the todo
> list for years, but never seems to make it to the top.
So the following maybe?
If I could get an acked-by from you Dan, and a Tested-by: from you
Slava, I'll submit upstream.
Thanks,
NeilBrown
From: NeilBrown <neilb@suse.com>
Date: Thu, 24 Dec 2015 09:35:18 +1100
Subject: [PATCH] async_tx: use GFP_NOWAIT rather than GFP_IO
These async_XX functions are called from md/raid5 in an atomic
section, between get_cpu() and put_cpu(), so they must not sleep.
So use GFP_NOWAIT rather than GFP_IO.
Dan Williams writes: Longer term async_tx needs to be merged into md
directly as we can allocate this unmap data statically per-stripe
rather than per request.
Reported-by: Stanislav Samsonov <slava@annapurnalabs.com>
Signed-off-by: NeilBrown <neilb@suse.com>
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index f8c0b8dbeb75..88bc8e6b2a54 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -53,7 +53,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
struct dmaengine_unmap_data *unmap = NULL;
if (device)
- unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
+ unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOWAIT);
if (unmap && is_dma_copy_aligned(device, src_offset, dest_offset, len)) {
unsigned long dma_prep_flags = 0;
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index 5d355e0c2633..c0748bbd4c08 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -188,7 +188,7 @@ async_gen_syndrome(struct page **blocks, unsigned int offset, int disks,
BUG_ON(disks > 255 || !(P(blocks, disks) || Q(blocks, disks)));
if (device)
- unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
+ unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOWAIT);
/* XORing P/Q is only implemented in software */
if (unmap && !(submit->flags & ASYNC_TX_PQ_XOR_DST) &&
@@ -307,7 +307,7 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
BUG_ON(disks < 4);
if (device)
- unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
+ unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOWAIT);
if (unmap && disks <= dma_maxpq(device, 0) &&
is_dma_pq_aligned(device, offset, 0, len)) {
diff --git a/crypto/async_tx/async_raid6_recov.c b/crypto/async_tx/async_raid6_recov.c
index 934a84981495..8fab6275ea1f 100644
--- a/crypto/async_tx/async_raid6_recov.c
+++ b/crypto/async_tx/async_raid6_recov.c
@@ -41,7 +41,7 @@ async_sum_product(struct page *dest, struct page **srcs, unsigned char *coef,
u8 *a, *b, *c;
if (dma)
- unmap = dmaengine_get_unmap_data(dma->dev, 3, GFP_NOIO);
+ unmap = dmaengine_get_unmap_data(dma->dev, 3, GFP_NOWAIT);
if (unmap) {
struct device *dev = dma->dev;
@@ -105,7 +105,7 @@ async_mult(struct page *dest, struct page *src, u8 coef, size_t len,
u8 *d, *s;
if (dma)
- unmap = dmaengine_get_unmap_data(dma->dev, 3, GFP_NOIO);
+ unmap = dmaengine_get_unmap_data(dma->dev, 3, GFP_NOWAIT);
if (unmap) {
dma_addr_t dma_dest[2];
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index e1bce26cd4f9..da75777f2b3f 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -182,7 +182,7 @@ async_xor(struct page *dest, struct page **src_list, unsigned int offset,
BUG_ON(src_cnt <= 1);
if (device)
- unmap = dmaengine_get_unmap_data(device->dev, src_cnt+1, GFP_NOIO);
+ unmap = dmaengine_get_unmap_data(device->dev, src_cnt+1, GFP_NOWAIT);
if (unmap && is_dma_xor_aligned(device, offset, 0, len)) {
struct dma_async_tx_descriptor *tx;
@@ -278,7 +278,7 @@ async_xor_val(struct page *dest, struct page **src_list, unsigned int offset,
BUG_ON(src_cnt <= 1);
if (device)
- unmap = dmaengine_get_unmap_data(device->dev, src_cnt, GFP_NOIO);
+ unmap = dmaengine_get_unmap_data(device->dev, src_cnt, GFP_NOWAIT);
if (unmap && src_cnt <= device->max_xor &&
is_dma_xor_aligned(device, offset, 0, len)) {
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply related
* Re: Create Lock to Eliminate RMW in RAID/456 when writing perfect stripes
From: Doug Dumitru @ 2015-12-23 20:37 UTC (permalink / raw)
To: Robert Kierski; +Cc: linux-raid
In-Reply-To: <F7761B9B1D11B64BBB666019E9378117FE6820@CFWEX01.americas.cray.com>
Bob,
In thinking about this, I suspect this is somewhat less of an edge
case than just the full stripe test. Even partial stripes probably
fire early increasing the amount of IO.
My issue with SSD wear is that my particular application stack
generates writes that are "perfect" and even very subtle deviations
from this can scramble some SSDs FTLs. Workloads that are more
typical will already push the SSDs into heavier wear amplification, so
this issue might be in the noise.
On Wed, Dec 23, 2015 at 12:28 PM, Robert Kierski <rkierski@cray.com> wrote:
> Hey Doug,
>
> I have a comment about the last line of your message -- 'Then again, if this is too much of an "edge case", I will just keep my patches in-house.'
>
> As the use of SSD's in RAID configurations becomes more common, and SSD's become faster, the case you're talking about will be a major issue preventing customers from getting all that they expect from the equipment they purchased. I would encourage you to continue pursuing better performance.
>
> Bob Kierski
> Senior Storage Performance Engineer
> Cray Inc.
> 380 Jackson Street
> Suite 210
> St. Paul, MN 55101
> Tele: 651-967-9590
> Fax: 651-605-9001
> Cell: 651-890-7461
>
--
Doug Dumitru
WildFire Storage
^ permalink raw reply
* RE: Create Lock to Eliminate RMW in RAID/456 when writing perfect stripes
From: Robert Kierski @ 2015-12-23 20:28 UTC (permalink / raw)
To: doug@easyco.com, linux-raid
In-Reply-To: <CAFx4rwR1gtLZUF6MUx71QTvw3hT5GKhsEMU2xcBpAz5wZWBUCw@mail.gmail.com>
Hey Doug,
I have a comment about the last line of your message -- 'Then again, if this is too much of an "edge case", I will just keep my patches in-house.'
As the use of SSD's in RAID configurations becomes more common, and SSD's become faster, the case you're talking about will be a major issue preventing customers from getting all that they expect from the equipment they purchased. I would encourage you to continue pursuing better performance.
Bob Kierski
Senior Storage Performance Engineer
Cray Inc.
380 Jackson Street
Suite 210
St. Paul, MN 55101
Tele: 651-967-9590
Fax: 651-605-9001
Cell: 651-890-7461
^ permalink raw reply
* Create Lock to Eliminate RMW in RAID/456 when writing perfect stripes
From: Doug Dumitru @ 2015-12-23 19:20 UTC (permalink / raw)
To: linux-raid
The issue:
The background thread in RAID-5 can wake up in the middle of a process
populating stripe cache entries with a long write. If the long write
contains a complete stripe, the background thread "should" be able to
process the require without doing any reads.
Sometimes the background thread is too quick at starting up a write
and schedules a RMW (Read Modify Write) even though the needed blocks
will soon be available.
Seeing this happen:
You can see this happen by creating an MD set with a small stripe size
and then doing DIRECT_IO writes that are exactly aligned on a stripe.
For example, with 4 disks and 64K stripes, write 192K blocks aligned
on 192K boundaries. You can do this from C or with 'dd' or 'fio'.
If you have this running, you can then run iostat and you should see
absolutely no read activity on the disks.
The probability of this happening goes up when there are more disks.
It may also go up the faster the disks are. My use case is 24 SSDs.
The problem with this:
There are really three issues.
1) The code does not need to work this way. It is not "broken" but
just seems wrong.
2) There is a performance penalty here.
3) There is a Flash wear penalty here.
It is 3) that most interests me.
The fix:
Create a waitq or semaphore based lock so that if a write includes a
complete stripe, the background thread will wait for the write to
completely populate the thread.
I would do this with a small array of locks. When a write includes a
complete stripe, it sets a lock (stripe_number % sizeof_lock_array).
This lock is released as soon as the write finishes populating the
stripe cache. The background thread checks this lock before it starts
a write. If the lock is set, it waits until the stripe cache is
completely populated which should eliminate the RMW.
If no writes are full stripes, then the lock never gets set, so most
code runs without any real overhead.
Implementing this:
I am happy to implement this. I have quite a bit of experience with
lock structures like this. I can also test on x86 and x86_64, but
will need help with other arch's.
Then again, if this is too much of an "edge case", I will just keep my
patches in-house.
--
Doug Dumitru
WildFire Storage
^ permalink raw reply
* Re: raid5 async_xor: sleep in atomic
From: Dan Williams @ 2015-12-23 17:35 UTC (permalink / raw)
To: NeilBrown; +Cc: Stanislav Samsonov, linux-raid
In-Reply-To: <87twn928qv.fsf@notabene.neil.brown.name>
On Tue, Dec 22, 2015 at 6:34 PM, NeilBrown <neilb@suse.com> wrote:
> On Tue, Dec 22 2015, Stanislav Samsonov wrote:
>
>> Hi,
>>
>> Kernel 4.1.3 : there is some troubling kernel message that shows up
>> after enabling CONFIG_DEBUG_ATOMIC_SLEEP and testing DMA XOR
>> acceleration for raid5:
>>
>> BUG: sleeping function called from invalid context at mm/mempool.c:320
>> in_atomic(): 1, irqs_disabled(): 0, pid: 1048, name: md127_raid5
>> INFO: lockdep is turned off.
>> CPU: 1 PID: 1048 Comm: md127_raid5 Not tainted 4.1.15.alpine.1-dirty #1
>> Hardware name: Annapurna Labs Alpine
>> [<c00169d8>] (unwind_backtrace) from [<c0012a78>] (show_stack+0x10/0x14)
>> [<c0012a78>] (show_stack) from [<c07462ec>] (dump_stack+0x80/0xb4)
>> [<c07462ec>] (dump_stack) from [<c00bf2f0>] (mempool_alloc+0x68/0x13c)
>> [<c00bf2f0>] (mempool_alloc) from [<c041c9b4>]
>> (dmaengine_get_unmap_data+0x24/0x4c)
>> [<c041c9b4>] (dmaengine_get_unmap_data) from [<c03a8084>]
>> (async_xor_val+0x60/0x3a0)
>> [<c03a8084>] (async_xor_val) from [<c058e4c0>] (raid_run_ops+0xb70/0x1248)
>> [<c058e4c0>] (raid_run_ops) from [<c05915d4>] (handle_stripe+0x1068/0x22a8)
>> [<c05915d4>] (handle_stripe) from [<c0592ae4>]
>> (handle_active_stripes+0x2d0/0x3dc)
>> [<c0592ae4>] (handle_active_stripes) from [<c059300c>] (raid5d+0x384/0x5b0)
>> [<c059300c>] (raid5d) from [<c059db6c>] (md_thread+0x114/0x138)
>> [<c059db6c>] (md_thread) from [<c0042d54>] (kthread+0xe4/0x104)
>> [<c0042d54>] (kthread) from [<c000f658>] (ret_from_fork+0x14/0x3c)
>>
>> The reason is that async_xor_val() in crypto/async_tx/async_xor.c is
>> called in atomic context (preemption disabled) by raid_run_ops(). Then
>> it calls dmaengine_get_unmap_data() an then mempool_alloc() with
>> GFP_NOIO flag - this allocation type might sleep under some condition.
>>
>> Checked latest kernel 4.3 and it has exactly same flow.
>>
>> Any advice regarding this issue?
>
> Changing the GFP_NOIO to GFP_ATOMIC in all the calls to
> dmaengine_get_unmap_data() in crypto/async_tx/ would probably fix the
> issue... or make it crash even worse :-)
>
> Dan: do you have any wisdom here? The xor is using the percpu data in
> raid5, so it cannot be sleep, but GFP_NOIO allows sleep.
> Does the code handle failure to get_unmap_data() safely? It looks like
> it probably does.
Those GFP_NOIO should move to GFP_NOWAIT. We don't want GFP_ATOMIC
allocations to consume emergency reserves for a performance
optimization. Longer term async_tx needs to be merged into md
directly as we can allocate this unmap data statically per-stripe
rather than per request. This asyntc_tx re-write has been on the todo
list for years, but never seems to make it to the top.
^ permalink raw reply
* Re: RAID10 Write Performance
From: Marc Smith @ 2015-12-23 13:59 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <87wps529dq.fsf@notabene.neil.brown.name>
Okay, thanks, I'll turn it back on and try some different chunk sizes.
For my own knowledge, why/what is taking place under the covers that
causes this behavior? When testing with fio, it sometimes takes 1-2
minutes of "ramp up time" before the performance numbers are
good/expected (when the write-intent bitmap is enabled).
Thanks,
Marc
On Tue, Dec 22, 2015 at 9:20 PM, NeilBrown <neilb@suse.com> wrote:
> On Wed, Dec 23 2015, Marc Smith wrote:
>
>> Solved... appears it was the write-intent bitmap that caused the
>> performance issues. I discovered if I left the test running longer
>> than 60 seconds, the performance would eventually climb to where I'd
>> expect it. I ran 'mdadm --grow --bitmap=none /dev/md0' and now random
>> write performance is high/good/stable right off the bat.
>
> Keeping a write-intent bitmap really is a good idea.
> Using a larger bitmap chunk size can reduce the performance penalty and
> preserve much of the value. It is easy enough to experiment with
> different sizes.
>
> NeilBrown
^ permalink raw reply
* [PATCH 2/2] imsm: abort reshape if sync_action is not "reshape"
From: Artur Paszkiewicz @ 2015-12-23 11:57 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, Artur Paszkiewicz
In-Reply-To: <1450871831-25452-1-git-send-email-artur.paszkiewicz@intel.com>
When reshape was interrupted, an incorrect checkpoint would be saved in
the migration record. Change wait_for_reshape_imsm() to return -1 when
sync_action is not "reshape" to abort early in imsm_manage_reshape()
without writing the migration record.
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
super-intel.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/super-intel.c b/super-intel.c
index e609e0c..c7efa98 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -10300,8 +10300,10 @@ int wait_for_reshape_imsm(struct mdinfo *sra, int ndata)
sysfs_wait(fd, NULL);
if (sysfs_get_str(sra, NULL, "sync_action",
action, 20) > 0 &&
- strncmp(action, "reshape", 7) != 0)
- break;
+ strncmp(action, "reshape", 7) != 0) {
+ close(fd);
+ return -1;
+ }
if (sysfs_fd_get_ll(fd, &completed) < 0) {
dprintf("cannot read reshape_position (in loop)\n");
close(fd);
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] Grow: close file descriptor earlier to avoid "still in use" when stopping
From: Artur Paszkiewicz @ 2015-12-23 11:57 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, Artur Paszkiewicz, Pawel Baldysiak
Close fd2 as soon as it is no longer needed, before calling
Grow_continue(). Otherwise, we won't be able to stop an array with
external metadata during reshape, because mdadm running in background
will be keeping it open.
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
---
Grow.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Grow.c b/Grow.c
index 80d7b22..f65b36a 100644
--- a/Grow.c
+++ b/Grow.c
@@ -4873,6 +4873,9 @@ int Grow_continue_command(char *devname, int fd,
sysfs_init(content, fd2, mdstat->devnm);
+ close(fd2);
+ fd2 = -1;
+
/* start mdmon in case it is not running
*/
if (!mdmon_running(container))
--
2.1.4
^ permalink raw reply related
* Recreating RAID-5 after SATA controller failure and botched auto-assemble
From: Wolfgang Draxinger @ 2015-12-23 9:58 UTC (permalink / raw)
To: linux-raid
Hi,
Just before anyone tells me off: I've got a Backup of my
important data; however there was a bunch of stuff on the RAID that I
didn't backup because it was not irreplaceable (mostly music, movies I
converted from DVDs, conference recordings, stuff like that), and I'd
like to save the hassle of procuring all that stuff again.
A little bit of backstory: Temperatures this summer were brutal. So
brutal that the controller hardware in my NAS experienced severe
failure (the HDDs of the RAID are apparently fine, at least there have
been no issues copying them onto a scratch disk, SMART doesn't show up
either). The main symptom is, that after connecting a disk it takes
only a couple of minutes before the SATA link will drop and the disk
get kicked from the set of block devices. Since there's a hotspare
the RAID would autorebuild on that, but the formerly dropped disk
would reappear. Then the spare might drop during autorebuild. And so
on. When I finally realized what was going on I pulled the plug hard,
but the damage was done.
That was 6 months ago. With the holidays being here I thought, I'd
finally have a look at the whole mess. First thing was to copy the
contents of 4 of the 5 drives to a single drive that could hold them
(it was short of 60MB to hold the last disk); but then I figured, that
for getting the whole thing into a read-only state that should suffice.
Here's the examine results for the superblocks (/dev/sdb is the large
disk to which I copied the original RAID disks, /dev/sdd is the one
original disk that didn't fit). Now the strange thing is, that these
are superblocks of two different arrays. I dimly remember, that back in
2008 I first created a test array to check the hardware before tearing
it down and creating the proper array. I've been using that 4 + 1 hot
spare configuration ever since, so the superblock UUID 42e59462... is
the one I'm probably after. However *all* of the disks participated in
that array, yet that other UUID superblock shows up.
Now I'd be only half surprised if the Creation or Update Time of the
UUID=13667845... superblock would say 2015, because then I'd blame the
botched attempts on rebuilding in that failure loop on it (you can see
that in the Update Time of the 42e59462) BTW.
What's going on there?
/dev/sdb1:
Magic : a92b4efc
Version : 0.90.00
UUID : 13667845:511c4be5:16e52af0:0ac6a895
Creation Time : Sat Oct 25 08:34:03 2008
Raid Level : raid5
Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
Array Size : 1953524992 (1863.03 GiB 2000.41 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Update Time : Sat Oct 25 08:34:17 2008
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Checksum : fbc116d1 - correct
Events : 3
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 0 8 0 0 active sync /dev/sda
0 0 8 0 0 active sync /dev/sda
1 1 8 32 1 active sync /dev/sdc
2 2 8 16 2 active sync /dev/sdb
/dev/sdb2:
Magic : a92b4efc
Version : 0.90.00
UUID : 42e59462:04b3a9b6:b1e97ac7:394f85ec
Creation Time : Sat Oct 25 08:52:56 2008
Raid Level : raid5
Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Update Time : Sat Jul 11 19:27:56 2015
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0
Checksum : b4e50c1d - correct
Events : 670769
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 2 8 0 2 active sync /dev/sda
0 0 0 0 0 removed
1 1 8 17 1 active sync /dev/sdb1
2 2 8 0 2 active sync /dev/sda
3 3 0 0 3 faulty removed
/dev/sdb3:
Magic : a92b4efc
Version : 0.90.00
UUID : 42e59462:04b3a9b6:b1e97ac7:394f85ec
Creation Time : Sat Oct 25 08:52:56 2008
Raid Level : raid5
Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Update Time : Sat Jul 11 18:29:02 2015
State : clean
Active Devices : 3
Working Devices : 4
Failed Devices : 0
Spare Devices : 1
Checksum : b4ef3a8f - correct
Events : 670757
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 3 8 48 3 active sync /dev/sdd
0 0 0 0 0 removed
1 1 8 17 1 active sync /dev/sdb1
2 2 8 0 2 active sync /dev/sda
3 3 8 48 3 active sync /dev/sdd
4 4 8 33 4 spare
/dev/sdb4:
Magic : a92b4efc
Version : 0.90.00
UUID : 13667845:511c4be5:16e52af0:0ac6a895
Creation Time : Sat Oct 25 08:34:03 2008
Raid Level : raid5
Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
Array Size : 1953524992 (1863.03 GiB 2000.41 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Update Time : Sat Oct 25 08:34:17 2008
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Checksum : fbc116e5 - correct
Events : 3
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 2 8 16 2 active sync /dev/sdb
0 0 8 0 0 active sync /dev/sda
1 1 8 32 1 active sync /dev/sdc
2 2 8 16 2 active sync /dev/sdb
/dev/sdd:
Magic : a92b4efc
Version : 0.90.00
UUID : 13667845:511c4be5:16e52af0:0ac6a895
Creation Time : Sat Oct 25 08:34:03 2008
Raid Level : raid5
Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
Array Size : 1953524992 (1863.03 GiB 2000.41 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Update Time : Sat Oct 25 08:34:17 2008
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Checksum : fbc116f3 - correct
Events : 3
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 1 8 32 1 active sync /dev/sdc
0 0 8 0 0 active sync /dev/sda
1 1 8 32 1 active sync /dev/sdc
2 2 8 16 2 active sync /dev/sdb
Anyway, I'd appreciate if anyone knew how I could read-only assemble
the disks into an array that resembles the 42e59462... configuration to
see if I can pull anything useful from it. There are a few things on
it (hopefully left) that I'd like to extract, if possible.
Cheers,
Wolfgang
^ permalink raw reply
* Re: raid5 async_xor: sleep in atomic
From: NeilBrown @ 2015-12-23 2:34 UTC (permalink / raw)
To: Stanislav Samsonov, linux-raid; +Cc: dan.j.williams
In-Reply-To: <CAFskJNhmU-N5_odOZV54x10Ku=7SSDnaMz5EtCbKddye+AGReg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
On Tue, Dec 22 2015, Stanislav Samsonov wrote:
> Hi,
>
> Kernel 4.1.3 : there is some troubling kernel message that shows up
> after enabling CONFIG_DEBUG_ATOMIC_SLEEP and testing DMA XOR
> acceleration for raid5:
>
> BUG: sleeping function called from invalid context at mm/mempool.c:320
> in_atomic(): 1, irqs_disabled(): 0, pid: 1048, name: md127_raid5
> INFO: lockdep is turned off.
> CPU: 1 PID: 1048 Comm: md127_raid5 Not tainted 4.1.15.alpine.1-dirty #1
> Hardware name: Annapurna Labs Alpine
> [<c00169d8>] (unwind_backtrace) from [<c0012a78>] (show_stack+0x10/0x14)
> [<c0012a78>] (show_stack) from [<c07462ec>] (dump_stack+0x80/0xb4)
> [<c07462ec>] (dump_stack) from [<c00bf2f0>] (mempool_alloc+0x68/0x13c)
> [<c00bf2f0>] (mempool_alloc) from [<c041c9b4>]
> (dmaengine_get_unmap_data+0x24/0x4c)
> [<c041c9b4>] (dmaengine_get_unmap_data) from [<c03a8084>]
> (async_xor_val+0x60/0x3a0)
> [<c03a8084>] (async_xor_val) from [<c058e4c0>] (raid_run_ops+0xb70/0x1248)
> [<c058e4c0>] (raid_run_ops) from [<c05915d4>] (handle_stripe+0x1068/0x22a8)
> [<c05915d4>] (handle_stripe) from [<c0592ae4>]
> (handle_active_stripes+0x2d0/0x3dc)
> [<c0592ae4>] (handle_active_stripes) from [<c059300c>] (raid5d+0x384/0x5b0)
> [<c059300c>] (raid5d) from [<c059db6c>] (md_thread+0x114/0x138)
> [<c059db6c>] (md_thread) from [<c0042d54>] (kthread+0xe4/0x104)
> [<c0042d54>] (kthread) from [<c000f658>] (ret_from_fork+0x14/0x3c)
>
> The reason is that async_xor_val() in crypto/async_tx/async_xor.c is
> called in atomic context (preemption disabled) by raid_run_ops(). Then
> it calls dmaengine_get_unmap_data() an then mempool_alloc() with
> GFP_NOIO flag - this allocation type might sleep under some condition.
>
> Checked latest kernel 4.3 and it has exactly same flow.
>
> Any advice regarding this issue?
Changing the GFP_NOIO to GFP_ATOMIC in all the calls to
dmaengine_get_unmap_data() in crypto/async_tx/ would probably fix the
issue... or make it crash even worse :-)
Dan: do you have any wisdom here? The xor is using the percpu data in
raid5, so it cannot be sleep, but GFP_NOIO allows sleep.
Does the code handle failure to get_unmap_data() safely? It looks like
it probably does.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: RAID10 Write Performance
From: NeilBrown @ 2015-12-23 2:20 UTC (permalink / raw)
To: Marc Smith, linux-raid
In-Reply-To: <CAHkw+LeVkGo8cOGMzQbq7sGtw5K9bc3CMOvurL0kjDf0ZWTfsA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
On Wed, Dec 23 2015, Marc Smith wrote:
> Solved... appears it was the write-intent bitmap that caused the
> performance issues. I discovered if I left the test running longer
> than 60 seconds, the performance would eventually climb to where I'd
> expect it. I ran 'mdadm --grow --bitmap=none /dev/md0' and now random
> write performance is high/good/stable right off the bat.
Keeping a write-intent bitmap really is a good idea.
Using a larger bitmap chunk size can reduce the performance penalty and
preserve much of the value. It is easy enough to experiment with
different sizes.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: RAID 6 "Failed to restore critical section for reshape, sorry." - recovery advice?
From: NeilBrown @ 2015-12-23 2:18 UTC (permalink / raw)
To: George Rapp; +Cc: Mikael Abrahamsson, Linux-RAID
In-Reply-To: <CAF-Kpga8toqetF+g6wYbUVHKngkRB8QMTyRy39Jnxn0P6w8ouQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]
On Wed, Dec 23 2015, George Rapp wrote:
>
>> The current state of the array is (I think) that it looks like a reshape
>> to reduce the number of devices in the array has very nearly completed.
>> Only the first stripe needs to be completed. Whether that first stripe
>> is still in the old "N+1" device layout or the new "N" device layout is
>> unknown to the kernel - this information is only in the backup file
>> (which doesn't exist).
>
> Hmmm. Maybe you're thinking of a different case. This is mine:
> http://marc.info/?l=linux-raid&m=143880359028232&w=2
>
> My problem was that I was *increasing* the number of devices from 5 to
> 6. Also, I don't believe the reshape actually got anywhere, per
> /proc/mdstat, which I was watching at the time, because the kernel was
> denied write access to my backup file by SELinux.
Yes, but then you did "--assemble --update=revert-reshape" didn't you?
So now it looks like it is being reduced in size.
> I was able to dump the metadata from the six component devices of the
> RAID 6 array with:
>
> # mdadm --dump=/home/gwr/c/dev-md4-mdadm-dump /dev/sdj1
> /dev/sdj1 saved as /home/gwr/c/dev-md4-mdadm-dump/sdj1.
> /dev/sdj1 also saved as
> /home/gwr/c/dev-md4-mdadm-dump/wwn-0x5000cca222d7b996-part1.
> /dev/sdj1 also saved as
> /home/gwr/c/dev-md4-mdadm-dump/wwn-0x13372914453769768960x-part1.
> /dev/sdj1 also saved as
> /home/gwr/c/dev-md4-mdadm-dump/ata-Hitachi_HUA722020ALA331_B9HP5Y2F-part1.
Oh, that's right - you give component device names to --dump, not the
array. Sorry.
>
> but after doing that, I have a whole bunch of huge (presumabily
> sparse) files in my output directory:
>
> [root@backend3 dev-md4-mdadm-dump]# ll
> total 192
> -rw-r--r-- 4 root root 1964963324416 Dec 22 20:42
> ata-Hitachi_HUA722020ALA331_B8HGR23Z-part1
...
> -rw-r--r-- 4 root root 1964963324416 Dec 22 20:42
> wwn-0x6368721060505866240x-part1
> -rw-r--r-- 4 root root 1964968599552 Dec 22 20:42
> wwn-0x7703416737422790657x-part4
>
> and "tar -c -v -z -f dev-md4-mdadm-dump.tar.gz dev-md4-mdadm-dump/"
> didn't produce a tiny file, but a huge one (15MB and growing in just
> 10 minutes), so I killed it.
>
> Any further thoughts about how to proceed? Thanks for your help.
Maybe add "-S" option to tar.
I don't do this often enough to remember the details. I though tar
auto-detected sparse files, but apparently not.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: RAID 6 "Failed to restore critical section for reshape, sorry." - recovery advice?
From: George Rapp @ 2015-12-23 2:04 UTC (permalink / raw)
To: NeilBrown; +Cc: Mikael Abrahamsson, Linux-RAID
In-Reply-To: <87d1u060sv.fsf@notabene.neil.brown.name>
On Sun, Dec 20, 2015 at 8:35 PM, NeilBrown <nfbrown@novell.com> wrote:
> On Fri, Dec 11 2015, George Rapp wrote:
>>
>> I appear to be too early in the reshape for auto-recovery, but too far
>> along to just say "never mind on that whole reshape business". Any
>> other thoughts?
>>
>
> What this means is that you've hit a corner case that was never thought
> through properly and isn't handled correctly.
Neil -
Thanks for the reply. Please see my comments inline below.
> The current state of the array is (I think) that it looks like a reshape
> to reduce the number of devices in the array has very nearly completed.
> Only the first stripe needs to be completed. Whether that first stripe
> is still in the old "N+1" device layout or the new "N" device layout is
> unknown to the kernel - this information is only in the backup file
> (which doesn't exist).
Hmmm. Maybe you're thinking of a different case. This is mine:
http://marc.info/?l=linux-raid&m=143880359028232&w=2
My problem was that I was *increasing* the number of devices from 5 to
6. Also, I don't believe the reshape actually got anywhere, per
/proc/mdstat, which I was watching at the time, because the kernel was
denied write access to my backup file by SELinux.
> By telling mdadm --invalid-backup, you effectively tell mdadm that there
> is nothing useful in the backup file so it should know that the reshape
> has actually completed. But it has no way to tell the kernel that.
> What it should do in this case is (I think) rewrite the metadata to
> record that the reshape is complete. But it doesn't.
IMHO, it'd be better in my case to revert to a 5-drive array and
rewrite the metadata to reflect that, since I don't believe the
reshape ever actually began. Once I have access to the array again and
have fsck'ed the filesystem, then I can re-try the "mdadm --grow
--raid-devices=6" command (with SELinux disabled, and watching from
the dunce chair in the opposite corner of the room ... 8^) later.
> I shouldn't be too hard to fix, but it isn't trivial either and I'm
> unlikely to get anywhere before the Christmas break.
>
> If you can get reshape to work at all (disable selinux?) you could try
> --update=revert-reshape and let the reshape to more devices progress for
> a while, and then revert it.
>
> If you cannot get anywhere, then use
> "mdadm --dump=/tmp/whatever /dev/mdthing"
>
> to create a copy of the metadata in some spares files.
> Then tar those up (a compressed tarchive should be tiny) and email them.
> Then I can try and see if I can make something work on exactly the array
> you have.
Since the array won't run, I can't obtain the metadata you're looking for:
# mdadm --dump=/home/gwr/c/dev-md4-mdadm-dump /dev/md4
mdadm: Cannot find RAID metadata on /dev/md4
# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md4 : inactive dm-2[5](S) dm-1[1](S) dm-4[8](S) dm-5[7](S) dm-0[0](S) dm-3[6](S)
11513452944 blocks super 1.2
(the funny member names are the overlay files I created to experiment
with various recovery operations nondestructively).
I was able to dump the metadata from the six component devices of the
RAID 6 array with:
# mdadm --dump=/home/gwr/c/dev-md4-mdadm-dump /dev/sdj1
/dev/sdj1 saved as /home/gwr/c/dev-md4-mdadm-dump/sdj1.
/dev/sdj1 also saved as
/home/gwr/c/dev-md4-mdadm-dump/wwn-0x5000cca222d7b996-part1.
/dev/sdj1 also saved as
/home/gwr/c/dev-md4-mdadm-dump/wwn-0x13372914453769768960x-part1.
/dev/sdj1 also saved as
/home/gwr/c/dev-md4-mdadm-dump/ata-Hitachi_HUA722020ALA331_B9HP5Y2F-part1.
but after doing that, I have a whole bunch of huge (presumabily
sparse) files in my output directory:
[root@backend3 dev-md4-mdadm-dump]# ll
total 192
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42
ata-Hitachi_HUA722020ALA331_B8HGR23Z-part1
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:42
ata-Hitachi_HUA722020ALA331_B9HP5Y2F-part1
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42
ata-ST2000DL003-9VT166_6YD0YXL1-part1
-rw-r--r-- 4 root root 1964963323392 Dec 22 20:42
ata-ST32000542AS_5XW29Z1K-part4
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:41
ata-ST32000542AS_5XW2D8GA-part4
-rw-r--r-- 4 root root 1964968599552 Dec 22 20:42
ata-TP02000GB_TPW140709340083-part4
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:41 sdc4
-rw-r--r-- 4 root root 1964963323392 Dec 22 20:42 sdd4
-rw-r--r-- 4 root root 1964968599552 Dec 22 20:42 sdg4
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42 sdh1
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42 sdi1
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:42 sdj1
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:42
wwn-0x13372914453769768960x-part1
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42
wwn-0x14378343057695330304x-part1
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:41
wwn-0x1508759625694990336x-part4
-rw-r--r-- 4 root root 1964963323392 Dec 22 20:42
wwn-0x4884205575019188224x-part4
-rw-r--r-- 4 root root 1964963323392 Dec 22 20:42 wwn-0x5000c5002f1743c8-part4
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:41 wwn-0x5000c50030e214f0-part4
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42 wwn-0x5000c5003e0f5862-part1
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42 wwn-0x5000cca222d4c78a-part1
-rw-r--r-- 4 root root 1964964405248 Dec 22 20:42 wwn-0x5000cca222d7b996-part1
-rw-r--r-- 4 root root 1964968599552 Dec 22 20:42 wwn-0x50014ee208b56ae8-part4
-rw-r--r-- 4 root root 1964963324416 Dec 22 20:42
wwn-0x6368721060505866240x-part1
-rw-r--r-- 4 root root 1964968599552 Dec 22 20:42
wwn-0x7703416737422790657x-part4
and "tar -c -v -z -f dev-md4-mdadm-dump.tar.gz dev-md4-mdadm-dump/"
didn't produce a tiny file, but a huge one (15MB and growing in just
10 minutes), so I killed it.
Any further thoughts about how to proceed? Thanks for your help.
George
--
George Rapp (Pataskala, OH) Home: george.rapp -- at -- gmail.com
LinkedIn profile: https://www.linkedin.com/in/georgerapp
Phone: +1 740 936 RAPP (740 936 7277)
^ permalink raw reply
* Re: [PATCH v2 1/3] badblocks: Add core badblock management code
From: Verma, Vishal L @ 2015-12-23 0:38 UTC (permalink / raw)
To: James.Bottomley@HansenPartnership.com, neilb@suse.com
Cc: linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-block@vger.kernel.org,
jmoyer@redhat.com, axboe@fb.com
In-Reply-To: <877fk62idp.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]
On Wed, 2015-12-23 at 10:06 +1100, NeilBrown wrote:
> On Wed, Dec 23 2015, Verma, Vishal L wrote:
>
> > On Tue, 2015-12-22 at 16:34 +1100, NeilBrown wrote:
> > > On Sat, Dec 05 2015, Verma, Vishal L wrote:
> > >
> > > > On Fri, 2015-12-04 at 15:30 -0800, James Bottomley wrote:
> > > > [...]
> > > > > > +ssize_t badblocks_store(struct badblocks *bb, const char
> > > > > > *page,
> > > > > > size_t len,
> > > > > > + int unack)
> > > > > [...]
> > > > > > +int badblocks_init(struct badblocks *bb, int enable)
> > > > > > +{
> > > > > > + bb->count = 0;
> > > > > > + if (enable)
> > > > > > + bb->shift = 0;
> > > > > > + else
> > > > > > + bb->shift = -1;
> > > > > > + bb->page = kmalloc(PAGE_SIZE, GFP_KERNEL);
> > > > >
> > > > > Why not __get_free_page(GFP_KERNEL)? The problem with kmalloc
> > > > > of
> > > > > an
> > > > > exactly known page sized quantity is that the slab tracker for
> > > > > this
> > > > > requires two contiguous pages for each page because of the
> > > > > overhead.
> > > >
> > > > Cool, I didn't know about __get_free_page - I can fix this up
> > > > too.
> > > >
> > >
> > > I was reminded of this just recently I thought I should clear up
> > > the
> > > misunderstanding.
> > >
> > > kmalloc(PAGE_SIZE) does *not* incur significant overhead and
> > > certainly
> > > does not require two contiguous free pages.
> > > If you "grep kmalloc-4096 /proc/slabinfo" you will note that both
> > > objperslab and pagesperslab are 1. So one page is used to store
> > > each
> > > 4096 byte allocation.
> > >
> > > To quote the email from Linus which reminded me about this
> > >
> > > > If you
> > > > want to allocate a page, and get a pointer, just use
> > > > "kmalloc()".
> > > > Boom, done!
> > >
> > > https://lkml.org/lkml/2015/12/21/605
> > >
> > > There probably is a small CPU overhead from using kmalloc, but no
> > > memory
> > > overhead.
> >
> > Thanks Neil.
> > I just read the rest of that thread - and I'm wondering if we should
> > change back to kzalloc here.
> >
> > The one thing __get_free_page gets us is PAGE_SIZE-aligned memory.
> > Do
> > you think that would be better for this use? (I can't think of any).
> > If
> > not, I can send out a new version reverting back to kzalloc.
>
> kzalloc(PAGE_SIZE) will also always return page-aligned memory.
> kzalloc returns a void*, __get_free_page returns unsigned long. For
> that reason alone I would prefer kzalloc.
>
> But I'm not necessarily suggesting you change the code. I just wanted
> to clarify a misunderstanding. You should produce the
> code that you are
> most happy with.
I agree, the typecasting with __get_free_page is pretty ugly. I'll
change it back to kzalloc.
Thanks,
-Vishal
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] badblocks: Add core badblock management code
From: NeilBrown @ 2015-12-22 23:06 UTC (permalink / raw)
To: Verma, Vishal L, James.Bottomley@HansenPartnership.com
Cc: linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-block@vger.kernel.org,
jmoyer@redhat.com, axboe@fb.com
In-Reply-To: <1450822398.5616.21.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]
On Wed, Dec 23 2015, Verma, Vishal L wrote:
> On Tue, 2015-12-22 at 16:34 +1100, NeilBrown wrote:
>> On Sat, Dec 05 2015, Verma, Vishal L wrote:
>>
>> > On Fri, 2015-12-04 at 15:30 -0800, James Bottomley wrote:
>> > [...]
>> > > > +ssize_t badblocks_store(struct badblocks *bb, const char *page,
>> > > > size_t len,
>> > > > + int unack)
>> > > [...]
>> > > > +int badblocks_init(struct badblocks *bb, int enable)
>> > > > +{
>> > > > + bb->count = 0;
>> > > > + if (enable)
>> > > > + bb->shift = 0;
>> > > > + else
>> > > > + bb->shift = -1;
>> > > > + bb->page = kmalloc(PAGE_SIZE, GFP_KERNEL);
>> > >
>> > > Why not __get_free_page(GFP_KERNEL)? The problem with kmalloc of
>> > > an
>> > > exactly known page sized quantity is that the slab tracker for
>> > > this
>> > > requires two contiguous pages for each page because of the
>> > > overhead.
>> >
>> > Cool, I didn't know about __get_free_page - I can fix this up too.
>> >
>>
>> I was reminded of this just recently I thought I should clear up the
>> misunderstanding.
>>
>> kmalloc(PAGE_SIZE) does *not* incur significant overhead and certainly
>> does not require two contiguous free pages.
>> If you "grep kmalloc-4096 /proc/slabinfo" you will note that both
>> objperslab and pagesperslab are 1. So one page is used to store each
>> 4096 byte allocation.
>>
>> To quote the email from Linus which reminded me about this
>>
>> > If you
>> > want to allocate a page, and get a pointer, just use "kmalloc()".
>> > Boom, done!
>>
>> https://lkml.org/lkml/2015/12/21/605
>>
>> There probably is a small CPU overhead from using kmalloc, but no
>> memory
>> overhead.
>
> Thanks Neil.
> I just read the rest of that thread - and I'm wondering if we should
> change back to kzalloc here.
>
> The one thing __get_free_page gets us is PAGE_SIZE-aligned memory. Do
> you think that would be better for this use? (I can't think of any). If
> not, I can send out a new version reverting back to kzalloc.
kzalloc(PAGE_SIZE) will also always return page-aligned memory.
kzalloc returns a void*, __get_free_page returns unsigned long. For
that reason alone I would prefer kzalloc.
But I'm not necessarily suggesting you change the code. I just wanted
to clarify a misunderstanding. You should produce the code that you are
most happy with.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] md: Replace get_seconds with ktime_get_seconds
From: Deepa Dinamani @ 2015-12-22 22:51 UTC (permalink / raw)
To: NeilBrown; +Cc: Shraddha Barke, linux-raid, Arnd Bergmann
In-Reply-To: <87io3q2jqt.fsf@notabene.neil.brown.name>
It should be real seconds.
You cannot use monotonic clock here since these are actual clock time timestamps. Monotonic time starts from 0 on every boot.
-Deepa
> On Dec 23, 2015, at 4:06 AM, NeilBrown <neilb@suse.com> wrote:
>
>> On Wed, Dec 23 2015, Shraddha Barke wrote:
>>
>> 32-bit systems using function get_seconds will break in year 2038,
>> in order to avoid that replace the code with more appropriate function
>> ktime_get_seconds which is y2038 safe. Function ktime_get_seconds use
>> monotonic instead of real time and therefore will not cause overflow
>>
>> Signed-off-by: Shraddha Barke <shraddha.6596@gmail.com>
>> ---
>> drivers/md/md.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>> index 807095f..8dd74bb 100644
>> --- a/drivers/md/md.c
>> +++ b/drivers/md/md.c
>> @@ -2333,7 +2333,7 @@ repeat:
>>
>> spin_lock(&mddev->lock);
>>
>> - mddev->utime = get_seconds();
>> + mddev->utime = ktime_get_seconds();
>>
>> if (test_and_clear_bit(MD_CHANGE_DEVS, &mddev->flags))
>> force_change = 1;
>> @@ -6347,13 +6347,13 @@ static int set_array_info(struct mddev *mddev, mdu_array_info_t *info)
>> /* ensure mddev_put doesn't delete this now that there
>> * is some minimal configuration.
>> */
>> - mddev->ctime = get_seconds();
>> + mddev->ctime = ktime_get_seconds();
>> return 0;
>> }
>> mddev->major_version = MD_MAJOR_VERSION;
>> mddev->minor_version = MD_MINOR_VERSION;
>> mddev->patch_version = MD_PATCHLEVEL_VERSION;
>> - mddev->ctime = get_seconds();
>> + mddev->ctime = ktime_get_seconds();
>>
>> mddev->level = info->level;
>> mddev->clevel[0] = 0;
>> --
>> 2.1.4
>
> Thanks for splitting this off.
> However I tried to apply it and it doesn't apply.
>
> I already have a patch (in linux-next) from
> Deepa Dinamani <deepa.kernel@gmail.com>
> which uses ktime_get_real_seconds().
>
> http://git.neil.brown.name/?p=md.git;a=commitdiff;h=195e0e2726a7f93295b28ebf277876d5a7c6cf2d
>
> Which should it be? ktime_get_seconds or ktime_get_real_seconds?
>
> Thanks,
> NeilBrown
^ permalink raw reply
* Re: [PATCH 2/2] md: Replace get_seconds with ktime_get_seconds
From: NeilBrown @ 2015-12-22 22:36 UTC (permalink / raw)
Cc: linux-raid, Arnd Bergmann, Shraddha Barke, Deepa Dinamani
In-Reply-To: <1450789602-31162-1-git-send-email-shraddha.6596@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On Wed, Dec 23 2015, Shraddha Barke wrote:
> 32-bit systems using function get_seconds will break in year 2038,
> in order to avoid that replace the code with more appropriate function
> ktime_get_seconds which is y2038 safe. Function ktime_get_seconds use
> monotonic instead of real time and therefore will not cause overflow
>
> Signed-off-by: Shraddha Barke <shraddha.6596@gmail.com>
> ---
> drivers/md/md.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 807095f..8dd74bb 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -2333,7 +2333,7 @@ repeat:
>
> spin_lock(&mddev->lock);
>
> - mddev->utime = get_seconds();
> + mddev->utime = ktime_get_seconds();
>
> if (test_and_clear_bit(MD_CHANGE_DEVS, &mddev->flags))
> force_change = 1;
> @@ -6347,13 +6347,13 @@ static int set_array_info(struct mddev *mddev, mdu_array_info_t *info)
> /* ensure mddev_put doesn't delete this now that there
> * is some minimal configuration.
> */
> - mddev->ctime = get_seconds();
> + mddev->ctime = ktime_get_seconds();
> return 0;
> }
> mddev->major_version = MD_MAJOR_VERSION;
> mddev->minor_version = MD_MINOR_VERSION;
> mddev->patch_version = MD_PATCHLEVEL_VERSION;
> - mddev->ctime = get_seconds();
> + mddev->ctime = ktime_get_seconds();
>
> mddev->level = info->level;
> mddev->clevel[0] = 0;
> --
> 2.1.4
Thanks for splitting this off.
However I tried to apply it and it doesn't apply.
I already have a patch (in linux-next) from
Deepa Dinamani <deepa.kernel@gmail.com>
which uses ktime_get_real_seconds().
http://git.neil.brown.name/?p=md.git;a=commitdiff;h=195e0e2726a7f93295b28ebf277876d5a7c6cf2d
Which should it be? ktime_get_seconds or ktime_get_real_seconds?
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] raid5: allow r5l_io_unit allocations to fail
From: NeilBrown @ 2015-12-22 22:29 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Shaohua Li, linux-raid
In-Reply-To: <20151222152050.GA28310@lst.de>
[-- Attachment #1: Type: text/plain, Size: 4745 bytes --]
On Wed, Dec 23 2015, Christoph Hellwig wrote:
>> I wonder if we should have a mempool for these io units too.
>> We would allocate with GFP_ATOMIC (or similar) so the allocation woult
>> fail instead of blocking, but we would then know that an allocation
>> could only fail if there was another request in flight. So the place
>> where we free an io_unit would be the obviously correct place to trigger
>> a retry of the delayed-due-to-mem-allocation-failure stripes.
>>
>> So I think I would prefer two lists, another mempool, and very well
>> defined places to retry the two lists. Is that over-engineering?
>
> How about the variant below (relative to md/for-next)? This implements
> the above and passes testing fine:
>
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 18de1fc..4fa9457 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -75,7 +75,10 @@ struct r5l_log {
> struct list_head finished_ios; /* io_units which settle down in log disk */
> struct bio flush_bio;
>
> + struct list_head no_mem_stripes; /* pending stripes, -ENOMEM */
> +
> struct kmem_cache *io_kc;
> + mempool_t *io_pool;
> struct bio_set *bs;
> mempool_t *meta_pool;
>
> @@ -287,9 +290,10 @@ static struct r5l_io_unit *r5l_new_meta(struct r5l_log *log)
> struct r5l_io_unit *io;
> struct r5l_meta_block *block;
>
> - io = kmem_cache_zalloc(log->io_kc, GFP_ATOMIC);
> + io = mempool_alloc(log->io_pool, GFP_ATOMIC);
> if (!io)
> return NULL;
> + memset(io, 0, sizeof(*io));
>
> io->log = log;
> INIT_LIST_HEAD(&io->log_sibling);
> @@ -490,24 +494,25 @@ int r5l_write_stripe(struct r5l_log *log, struct stripe_head *sh)
> mutex_lock(&log->io_mutex);
> /* meta + data */
> reserve = (1 + write_disks) << (PAGE_SHIFT - 9);
> - if (!r5l_has_free_space(log, reserve))
> - goto err_retry;
> + if (!r5l_has_free_space(log, reserve)) {
> + spin_lock(&log->no_space_stripes_lock);
> + list_add_tail(&sh->log_list, &log->no_space_stripes);
> + spin_unlock(&log->no_space_stripes_lock);
> +
> + r5l_wake_reclaim(log, reserve);
> + goto out_unlock;
> + }
>
> ret = r5l_log_stripe(log, sh, data_pages, parity_pages);
> - if (ret)
> - goto err_retry;
> + if (ret) {
> + spin_lock_irq(&log->io_list_lock);
> + list_add_tail(&sh->log_list, &log->no_mem_stripes);
> + spin_unlock_irq(&log->io_list_lock);
> + }
>
> out_unlock:
> mutex_unlock(&log->io_mutex);
> return 0;
> -
> -err_retry:
> - spin_lock(&log->no_space_stripes_lock);
> - list_add_tail(&sh->log_list, &log->no_space_stripes);
> - spin_unlock(&log->no_space_stripes_lock);
> -
> - r5l_wake_reclaim(log, reserve);
> - goto out_unlock;
> }
>
> void r5l_write_stripe_run(struct r5l_log *log)
> @@ -559,6 +564,21 @@ static sector_t r5l_reclaimable_space(struct r5l_log *log)
> log->next_checkpoint);
> }
>
> +static void r5l_run_no_mem_stripe(struct r5l_log *log)
> +{
> + struct stripe_head *sh;
> +
> + assert_spin_locked(&log->io_list_lock);
> +
> + if (!list_empty(&log->no_mem_stripes)) {
> + sh = list_first_entry(&log->no_mem_stripes,
> + struct stripe_head, log_list);
> + list_del_init(&sh->log_list);
> + set_bit(STRIPE_HANDLE, &sh->state);
> + raid5_release_stripe(sh);
> + }
> +}
> +
> static bool r5l_complete_finished_ios(struct r5l_log *log)
> {
> struct r5l_io_unit *io, *next;
> @@ -575,7 +595,8 @@ static bool r5l_complete_finished_ios(struct r5l_log *log)
> log->next_cp_seq = io->seq;
>
> list_del(&io->log_sibling);
> - kmem_cache_free(log->io_kc, io);
> + mempool_free(io, log->io_pool);
> + r5l_run_no_mem_stripe(log);
>
> found = true;
> }
> @@ -1189,6 +1210,10 @@ int r5l_init_log(struct r5conf *conf, struct md_rdev *rdev)
> if (!log->io_kc)
> goto io_kc;
>
> + log->io_pool = mempool_create_slab_pool(R5L_POOL_SIZE, log->io_kc);
> + if (!log->io_pool)
> + goto io_pool;
> +
> log->bs = bioset_create(R5L_POOL_SIZE, 0);
> if (!log->bs)
> goto io_bs;
> @@ -1203,6 +1228,8 @@ int r5l_init_log(struct r5conf *conf, struct md_rdev *rdev)
> goto reclaim_thread;
> init_waitqueue_head(&log->iounit_wait);
>
> + INIT_LIST_HEAD(&log->no_mem_stripes);
> +
> INIT_LIST_HEAD(&log->no_space_stripes);
> spin_lock_init(&log->no_space_stripes_lock);
>
> @@ -1219,6 +1246,8 @@ reclaim_thread:
> out_mempool:
> bioset_free(log->bs);
> io_bs:
> + mempool_destroy(log->io_pool);
> +io_pool:
> kmem_cache_destroy(log->io_kc);
> io_kc:
> kfree(log);
Yes, that looks just right - thanks.
I feel a lot more confident that this code won't deadlock.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] badblocks: Add core badblock management code
From: Verma, Vishal L @ 2015-12-22 22:13 UTC (permalink / raw)
To: James.Bottomley@HansenPartnership.com, neilb@suse.com
Cc: linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-block@vger.kernel.org,
jmoyer@redhat.com, axboe@fb.com
In-Reply-To: <87r3if2gij.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
On Tue, 2015-12-22 at 16:34 +1100, NeilBrown wrote:
> On Sat, Dec 05 2015, Verma, Vishal L wrote:
>
> > On Fri, 2015-12-04 at 15:30 -0800, James Bottomley wrote:
> > [...]
> > > > +ssize_t badblocks_store(struct badblocks *bb, const char *page,
> > > > size_t len,
> > > > + int unack)
> > > [...]
> > > > +int badblocks_init(struct badblocks *bb, int enable)
> > > > +{
> > > > + bb->count = 0;
> > > > + if (enable)
> > > > + bb->shift = 0;
> > > > + else
> > > > + bb->shift = -1;
> > > > + bb->page = kmalloc(PAGE_SIZE, GFP_KERNEL);
> > >
> > > Why not __get_free_page(GFP_KERNEL)? The problem with kmalloc of
> > > an
> > > exactly known page sized quantity is that the slab tracker for
> > > this
> > > requires two contiguous pages for each page because of the
> > > overhead.
> >
> > Cool, I didn't know about __get_free_page - I can fix this up too.
> >
>
> I was reminded of this just recently I thought I should clear up the
> misunderstanding.
>
> kmalloc(PAGE_SIZE) does *not* incur significant overhead and certainly
> does not require two contiguous free pages.
> If you "grep kmalloc-4096 /proc/slabinfo" you will note that both
> objperslab and pagesperslab are 1. So one page is used to store each
> 4096 byte allocation.
>
> To quote the email from Linus which reminded me about this
>
> > If you
> > want to allocate a page, and get a pointer, just use "kmalloc()".
> > Boom, done!
>
> https://lkml.org/lkml/2015/12/21/605
>
> There probably is a small CPU overhead from using kmalloc, but no
> memory
> overhead.
Thanks Neil.
I just read the rest of that thread - and I'm wondering if we should
change back to kzalloc here.
The one thing __get_free_page gets us is PAGE_SIZE-aligned memory. Do
you think that would be better for this use? (I can't think of any). If
not, I can send out a new version reverting back to kzalloc.
-Vishal
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox