* Re: [PATCH 34/35] block: add QUEUE_FLAGs for flush and fua
From: Christoph Hellwig @ 2016-01-09 8:04 UTC (permalink / raw)
To: mchristi-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA, xfs-VZNHf3L845pBDgjK7y7TUQ,
ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
osd-dev-yNzVSZO3znNg9hUCZPvPmw,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA,
linux-btrfs-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <1452027218-32303-35-git-send-email-mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Jan 05, 2016 at 02:53:37PM -0600, mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org wrote:
> From: Mike Christie <mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> The last patch added a REQ_OP_FLUSH for request_fn drivers
> and the next patch renames REQ_FLUSH to REQ_PREFLUSH which
> will be used by file systems and make_request_fn drivers.
>
> This leaves REQ_FLUSH/REQ_FUA defined for drivers to tell
> the block layer if flush/fua is supported. The names are
> confusing and I bet will will accidentally be used by
> people to request flushes. To avoid that, this patch adds
> QUEUE_FLAGs for flush and fua which drivers will use to
> indicate what they support.
>
> Signed-off-by: Mike Christie <mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Yes, this was rather confusing before. Looks great fix the fix for th
kbuild complaint:
Reviewed-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 00/35 v2] separate operations from flags in the bio/request structs
From: Mike Snitzer @ 2016-01-08 23:07 UTC (permalink / raw)
To: Mike Christie
Cc: Christoph Hellwig, mchristi, linux-bcache, linux-block, xfs,
linux-scsi, konrad.wilk, linux-kernel, philipp.reisner,
linux-f2fs-devel, linux-raid, ocfs2-devel, dm-devel, target-devel,
linux-mtd, osd-dev, linux-fsdevel, lars.ellenberg, linux-ext4,
linux-btrfs, drbd-dev
In-Reply-To: <56902132.8080008@cs.wisc.edu>
On Fri, Jan 08 2016 at 3:50P -0500,
Mike Christie <michaelc@cs.wisc.edu> wrote:
> On 01/08/2016 07:32 AM, Christoph Hellwig wrote:
> > This looks good to me from a highlevel point of view.
> > Do you also have a git tree to take a look at all the changes in a
> > single big diff?
>
> I uploaded a git tree here:
>
> https://github.com/mikechristie/linux-kernel.git
>
> based off of linux-next today. The patches are just in the master branch.
Hi Mike,
I had a look at your DM changes. That sucked (but things looked good).
So much so that I want to thank you for tackling this task (and taking
one for the team).
I'll get this kernel built and tested (using the various DM testsuites:
lvm2, cryptsetup, device-mapper-test-suite for dm-thinp and dm-cache).
But I did make some changes during my review that I'd appreciate if
you'd fold in to wherever you think it appropriate in your series:
diff --git a/drivers/md/dm-stats.c b/drivers/md/dm-stats.c
index 96b5c1b..9e29dba 100644
--- a/drivers/md/dm-stats.c
+++ b/drivers/md/dm-stats.c
@@ -514,11 +514,10 @@ static void dm_stat_round(struct dm_stat *s, struct dm_stat_shared *shared,
}
static void dm_stat_for_entry(struct dm_stat *s, size_t entry,
- unsigned long bi_rw, sector_t len,
+ int idx, sector_t len,
struct dm_stats_aux *stats_aux, bool end,
unsigned long duration_jiffies)
{
- unsigned long idx = bi_rw;
struct dm_stat_shared *shared = &s->stat_shared[entry];
struct dm_stat_percpu *p;
@@ -584,7 +583,7 @@ static void dm_stat_for_entry(struct dm_stat *s, size_t entry,
#endif
}
-static void __dm_stat_bio(struct dm_stat *s, unsigned long bi_rw,
+static void __dm_stat_bio(struct dm_stat *s, int bi_rw,
sector_t bi_sector, sector_t end_sector,
bool end, unsigned long duration_jiffies,
struct dm_stats_aux *stats_aux)
@@ -622,7 +621,7 @@ static void __dm_stat_bio(struct dm_stat *s, unsigned long bi_rw,
} while (unlikely(todo != 0));
}
-void dm_stats_account_io(struct dm_stats *stats, unsigned long bi_rw,
+void dm_stats_account_io(struct dm_stats *stats, int bi_rw,
sector_t bi_sector, unsigned bi_sectors, bool end,
unsigned long duration_jiffies,
struct dm_stats_aux *stats_aux)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 5e940f7..9a4b3cb 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -1326,7 +1326,7 @@ static int device_fua_capable(struct dm_target *ti, struct dm_dev *dev,
}
static bool dm_table_supports_flush(struct dm_table *t,
- iterate_devices_callout_fn support_test)
+ iterate_devices_callout_fn callout_fn)
{
struct dm_target *ti;
unsigned i = 0;
@@ -1347,7 +1347,7 @@ static bool dm_table_supports_flush(struct dm_table *t,
return true;
if (ti->type->iterate_devices &&
- ti->type->iterate_devices(ti, support_test, NULL))
+ ti->type->iterate_devices(ti, callout_fn, NULL))
return true;
}
^ permalink raw reply related
* Re: [PATCH 00/35 v2] separate operations from flags in the bio/request structs
From: Mike Christie @ 2016-01-08 20:50 UTC (permalink / raw)
To: Christoph Hellwig, mchristi
Cc: linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <20160108133237.GA7663@infradead.org>
On 01/08/2016 07:32 AM, Christoph Hellwig wrote:
> This looks good to me from a highlevel point of view.
> Do you also have a git tree to take a look at all the changes in a
> single big diff?
I uploaded a git tree here:
https://github.com/mikechristie/linux-kernel.git
based off of linux-next today. The patches are just in the master branch.
^ permalink raw reply
* Re: [dm-devel] WANTED new maintainer for Linux/md (and mdadm)
From: Jes Sorensen @ 2016-01-08 20:28 UTC (permalink / raw)
To: NeilBrown
Cc: Brassow Jonathan, device-mapper development, linux-raid, LKML,
J. Bruce Fields, Phil Turmel, Linus Torvalds, Doug Ledford,
Xiao Ni
In-Reply-To: <878u40ak6u.fsf@notabene.neil.brown.name>
NeilBrown <neilb@suse.de> writes:
> On Thu, Jan 07 2016, Jes Sorensen wrote:
>
>> Brassow Jonathan <jbrassow@redhat.com> writes:
>>> Many thanks Neil for all the work you’ve done and the help you gave me
>>> while working on the DM/MD interactions bits. I’m happy you are
>>> sticking around for the raid1-cluster and raid5-journal bits and I’m
>>> interested to see what comes out of those.
>>>
>>> I know there are a number of folks around Red Hat who are capable and
>>> possibly interested to share the load. They should be back from PTO
>>> soon and we’ll make sure they know about the opportunity.
>>
>> Thanks Neil!
>>
>> I mentioned to Neil last year that I could probably be convinced,
>> bribed, shamed, into maintaining mdadm.
>
> I realise that is somewhat tongue-in-cheek, but I am certainly not
> looking for someone who needs to be convinced, bribed, or shamed. I'm
> hoping for someone who will weigh the pros and cons, decide this is a
> contribution they are willing (and maybe even eager) to make, and will
> step up and do so. And I suspect that behind that facade of
> reluctance, that is what you are really offering. Thanks.
>
> I propose to make one last release of mdadm either next week or the last
> week of January. I plan to call it "3.4" in acknowledgment of the new
> cluster and raid5-journal functionality.
> If you were to take it from there, I would be grateful.
Hi Neil,
I wouldn't have offered to take on mdadm if I hadn't meant it, even if I
like making the wording sound silly :) I feel I can do a decent job at
it and the task should be reasonable in scope. If someone is dying to
take it on, I am not going to stand in their way, but I feel mdadm needs
a maintainer and it's a worthy effort.
We'll have to figure out the logistics, and I'd like to coordinate with
who takes on drivers/md
Cheers,
Jes
>
> Thanks,
> NeilBrown
>
>>
>> The kernel MD stack I think really needs a team to run it. There is just
>> too much internal knowledge sitting in Neil's head and I personally am a
>> little scared of taking on that. Shaohua Li would be a good candidate
>> for that team IMHO.
>>
>> Cheers,
>> Jes
>>
>>
>>> thanks,
>>> brassow
>>>
>>>> On Dec 21, 2015, at 12:10 AM, NeilBrown <neilb@suse.com> wrote:
>>>>
>>>>
>>>> hi,
>>>> I became maintainer for md (Linux Software RAID) in late 2001 and on
>>>> the whole it has been fun and a valuable experience. But I have been
>>>> losing interest in recent years (https://lwn.net/Articles/511073/) and
>>>> as was mentioned at the kernel summit, I would like to resign. Some
>>>> years ago I managed to hand over nfsd to the excellent Bruce Fields,
>>>> but I do not seem to have the gift that Linus has of attracting
>>>> maintainers. While there are a number of people who know quite a bit
>>>> about md and/or have contributed to development, there is no obvious
>>>> candidate for replacement maintainer - no one who has already been
>>>> doing significant parts of the maintainer role.
>>>>
>>>> So I have decided to fall back on the mechanism by which I ended up
>>>> being maintainer in the first place. I will create a vacuum and hope
>>>> someone fills it (yes: I was sucked-in....). So as of 1st February
>>>> 2016 I will be resigning.
>>>>
>>>> At the kernel summit in October Linus talked about the value of
>>>> maintainership teams (https://lwn.net/Articles/662979/). I think it
>>>> would be great if a (small) team formed to continue to oversee md
>>>> rather than just a single individual (or maybe the dm team could extend
>>>> to include md??). If I had managed to be part of a team rather than
>>>> "going it alone" for so long, I might feel less tired of the whole
>>>> thing now.
>>>>
>>>> I don't see it as my place to appoint that team or any individuals, or
>>>> even to nominate any candidates. A very important attribute of a
>>>> maintainer is that they need to care about the code and the subsystem
>>>> and I cannot tell other people to care (or even know if they do). It
>>>> is really up to individuals to volunteer. A few people have been
>>>> mentioned to me in earlier less-public conversations. Any of them may
>>>> well be suitable, but I would rather they named themselves if
>>>> interested.
>>>>
>>>> So I'm hoping to get one or more volunteers to be maintainer:
>>>> - to gather and manage patches and outstanding issues,
>>>> - to review patches or get them reviewed
>>>> - to follow up bug reports and get them resolved
>>>> - to feed patches upstream, maybe directly to Linus,
>>>> maybe through some other maintainer, depending on what
>>>> relationships already exist or can be formed,
>>>> - to guide the longer term direction (saying "no" is important
>>>> sometimes),
>>>> - to care,
>>>> but also to be aware that maintainership takes real effort and time, as
>>>> does anything that is really worthwhile.
>>>>
>>>> This all applies to mdadm as well as md (except you would ultimately
>>>> *be* upstream for mdadm, not needing to send it anywhere). Even if a
>>>> clear team doesn't form it would be great if different people
>>>> maintained mdadm and md.
>>>>
>>>> One part of the job that I have put a lot of time in to is following
>>>> the linux-raid@vger.kernel.org list and providing support. This makes
>>>> people feel good about md and so more adventurous in using it.
>>>> Consequently I tend to hear about bugs and usability issues nice and
>>>> early (well before paying customers hit them in most cases) and that is
>>>> a big win.
>>>> In recent times I've been doing less of this and have been absolutely
>>>> thrilled that the gap has been more than filled by other very competent
>>>> community members. Not developers particular but a number of md users
>>>> have been providing excellent support. I'd particularly like to
>>>> high-light Phil Turmel who is very forthcoming with excellent advice,
>>>> but he is certainly not the only one who deserves a lot of thanks.
>>>> So "Thank you" to everyone who answers questions on linux-raid.
>>>>
>>>> This would be a good place for any future maintainer to hang out to
>>>> receive wisdom as well as to provide support.
>>>>
>>>> I will still be around. I can certainly help out in some sort of
>>>> mentor role, and can probably be convinced to review patches and
>>>> comment on designs. But I really want to head towards spending less
>>>> time on md (there are so many other interesting things to learn about).
>>>>
>>>> So: if anyone is interested - please announce yourself, ask questions
>>>> and start doing things. I have no clear idea about how a transition
>>>> will happen. That is really up to you (plural). Take the bull by the
>>>> horns and start *being* a maintainer(team). I won't get in your way
>>>> and I'll help where I can.
>>>>
>>>> Thanks,
>>>> NeilBrown
>>>>
>>>> P.S. I'm committed to continue to work with the raid5-journal effort
>>>> From Facebook and the raid1-cluster effort from SUSE and the
>>>> line-in-the-sand of 1st February won't affect my support for those.
>>>> --
>>>> dm-devel mailing list
>>>> dm-devel@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/dm-devel
>>>
>>> --
>>> 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 00/35 v2] separate operations from flags in the bio/request structs
From: Christoph Hellwig @ 2016-01-08 13:32 UTC (permalink / raw)
To: mchristi
Cc: linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <1452027218-32303-1-git-send-email-mchristi@redhat.com>
This looks good to me from a highlevel point of view.
Do you also have a git tree to take a look at all the changes in a
single big diff?
^ permalink raw reply
* Re: WANTED new maintainer for Linux/md (and mdadm)
From: NeilBrown @ 2016-01-08 2:38 UTC (permalink / raw)
To: Shaohua Li
Cc: linux-raid, dm-devel, LKML, Linus Torvalds, J. Bruce Fields,
Phil Turmel
In-Reply-To: <20160104182402.GA1541@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
On Tue, Jan 05 2016, Shaohua Li wrote:
>
> Hi Neil,
>
> Thanks for all the efforts! We will definitely miss you and fortunately you
> won't completely quit from MD :). I'm very interested in helping maintain MD. I
> have been working on MD for several years. My employer (facebook) supports me,
> so I have time being a maintainer too.
Hi Shaohua,
as you are one of the more active developers of MD at the moment, this
probably affects you more than many others and your willingness to
contribute more is certainly welcome.
The first question is where do you send your patches to get the
appropriate review and upstream acceptance. Alasdair or Mike (DM),
Jens (Block), Andrew Morton (anything) and Linus (everything) are all
defensible choices for upstreaming (I've submitted through Andrew in
the past, but through Linus exclusively once I figured out git). That
is really something you and they would need to negotiate though.
I plan to submit a pull request to Linus for the 4.5 merge window
and then stop queuing patches. I will still review your journaling
patches but will likely reply with "Reviewed-by" rather than "applied,
thanks".
My intention is to only look at other patches if they already have an
independent "Reviewed-by", but it remains to be seen how strongly I
stick to that intention.
If you have specific questions about anything (md internals, git
work-flows, whatever) do feel free to ask.
I am trying to write some comprehensive documentation on the internals
of MD - though it is slow going. Once that is mostly done I'll make it
available and it should at least serve as a good structure in which to
place answers to further questions.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [dm-devel] WANTED new maintainer for Linux/md (and mdadm)
From: NeilBrown @ 2016-01-08 2:17 UTC (permalink / raw)
To: Jes Sorensen, Brassow Jonathan
Cc: device-mapper development, linux-raid, LKML, J. Bruce Fields,
Phil Turmel, Linus Torvalds, Doug Ledford, Xiao Ni
In-Reply-To: <wrfja8oimyyk.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 7112 bytes --]
On Thu, Jan 07 2016, Jes Sorensen wrote:
> Brassow Jonathan <jbrassow@redhat.com> writes:
>> Many thanks Neil for all the work you’ve done and the help you gave me
>> while working on the DM/MD interactions bits. I’m happy you are
>> sticking around for the raid1-cluster and raid5-journal bits and I’m
>> interested to see what comes out of those.
>>
>> I know there are a number of folks around Red Hat who are capable and
>> possibly interested to share the load. They should be back from PTO
>> soon and we’ll make sure they know about the opportunity.
>
> Thanks Neil!
>
> I mentioned to Neil last year that I could probably be convinced,
> bribed, shamed, into maintaining mdadm.
I realise that is somewhat tongue-in-cheek, but I am certainly not
looking for someone who needs to be convinced, bribed, or shamed.
I'm hoping for someone who will weigh the pros and cons, decide this is
a contribution they are willing (and maybe even eager) to make, and will
step up and do so.
And I suspect that behind that facade of reluctance, that is what you
are really offering. Thanks.
I propose to make one last release of mdadm either next week or the last
week of January. I plan to call it "3.4" in acknowledgment of the new
cluster and raid5-journal functionality.
If you were to take it from there, I would be grateful.
Thanks,
NeilBrown
>
> The kernel MD stack I think really needs a team to run it. There is just
> too much internal knowledge sitting in Neil's head and I personally am a
> little scared of taking on that. Shaohua Li would be a good candidate
> for that team IMHO.
>
> Cheers,
> Jes
>
>
>> thanks,
>> brassow
>>
>>> On Dec 21, 2015, at 12:10 AM, NeilBrown <neilb@suse.com> wrote:
>>>
>>>
>>> hi,
>>> I became maintainer for md (Linux Software RAID) in late 2001 and on
>>> the whole it has been fun and a valuable experience. But I have been
>>> losing interest in recent years (https://lwn.net/Articles/511073/) and
>>> as was mentioned at the kernel summit, I would like to resign. Some
>>> years ago I managed to hand over nfsd to the excellent Bruce Fields,
>>> but I do not seem to have the gift that Linus has of attracting
>>> maintainers. While there are a number of people who know quite a bit
>>> about md and/or have contributed to development, there is no obvious
>>> candidate for replacement maintainer - no one who has already been
>>> doing significant parts of the maintainer role.
>>>
>>> So I have decided to fall back on the mechanism by which I ended up
>>> being maintainer in the first place. I will create a vacuum and hope
>>> someone fills it (yes: I was sucked-in....). So as of 1st February
>>> 2016 I will be resigning.
>>>
>>> At the kernel summit in October Linus talked about the value of
>>> maintainership teams (https://lwn.net/Articles/662979/). I think it
>>> would be great if a (small) team formed to continue to oversee md
>>> rather than just a single individual (or maybe the dm team could extend
>>> to include md??). If I had managed to be part of a team rather than
>>> "going it alone" for so long, I might feel less tired of the whole
>>> thing now.
>>>
>>> I don't see it as my place to appoint that team or any individuals, or
>>> even to nominate any candidates. A very important attribute of a
>>> maintainer is that they need to care about the code and the subsystem
>>> and I cannot tell other people to care (or even know if they do). It
>>> is really up to individuals to volunteer. A few people have been
>>> mentioned to me in earlier less-public conversations. Any of them may
>>> well be suitable, but I would rather they named themselves if
>>> interested.
>>>
>>> So I'm hoping to get one or more volunteers to be maintainer:
>>> - to gather and manage patches and outstanding issues,
>>> - to review patches or get them reviewed
>>> - to follow up bug reports and get them resolved
>>> - to feed patches upstream, maybe directly to Linus,
>>> maybe through some other maintainer, depending on what
>>> relationships already exist or can be formed,
>>> - to guide the longer term direction (saying "no" is important
>>> sometimes),
>>> - to care,
>>> but also to be aware that maintainership takes real effort and time, as
>>> does anything that is really worthwhile.
>>>
>>> This all applies to mdadm as well as md (except you would ultimately
>>> *be* upstream for mdadm, not needing to send it anywhere). Even if a
>>> clear team doesn't form it would be great if different people
>>> maintained mdadm and md.
>>>
>>> One part of the job that I have put a lot of time in to is following
>>> the linux-raid@vger.kernel.org list and providing support. This makes
>>> people feel good about md and so more adventurous in using it.
>>> Consequently I tend to hear about bugs and usability issues nice and
>>> early (well before paying customers hit them in most cases) and that is
>>> a big win.
>>> In recent times I've been doing less of this and have been absolutely
>>> thrilled that the gap has been more than filled by other very competent
>>> community members. Not developers particular but a number of md users
>>> have been providing excellent support. I'd particularly like to
>>> high-light Phil Turmel who is very forthcoming with excellent advice,
>>> but he is certainly not the only one who deserves a lot of thanks.
>>> So "Thank you" to everyone who answers questions on linux-raid.
>>>
>>> This would be a good place for any future maintainer to hang out to
>>> receive wisdom as well as to provide support.
>>>
>>> I will still be around. I can certainly help out in some sort of
>>> mentor role, and can probably be convinced to review patches and
>>> comment on designs. But I really want to head towards spending less
>>> time on md (there are so many other interesting things to learn about).
>>>
>>> So: if anyone is interested - please announce yourself, ask questions
>>> and start doing things. I have no clear idea about how a transition
>>> will happen. That is really up to you (plural). Take the bull by the
>>> horns and start *being* a maintainer(team). I won't get in your way
>>> and I'll help where I can.
>>>
>>> Thanks,
>>> NeilBrown
>>>
>>> P.S. I'm committed to continue to work with the raid5-journal effort
>>> From Facebook and the raid1-cluster effort from SUSE and the
>>> line-in-the-sand of 1st February won't affect my support for those.
>>> --
>>> dm-devel mailing list
>>> dm-devel@redhat.com
>>> https://www.redhat.com/mailman/listinfo/dm-devel
>>
>> --
>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: {Possible Spam} RE: stripe_cache_active always 0
From: Benjamin ESTRABAUD @ 2016-01-07 17:53 UTC (permalink / raw)
To: Robert Kierski, Adam Goryachev, linux-raid@vger.kernel.org
In-Reply-To: <F7761B9B1D11B64BBB666019E9378117FE848B@CFWEX01.americas.cray.com>
On 07/01/16 16:34, Robert Kierski wrote:
> Adam,
>
> stripe_cache_active is the value to indicate how many pages are currently in use in the stripe cache. I could be wrong about this... but I don’t think you can disable the stripe cache. You can shrink it to an unreasonable size, but the minimum you can set stripe_cache_size to is 17 (pages).
>
> Having said that, it may be that your RAID isn't using the stripe cache or that you're not checking the value frequently enough to see stripe cache activity.
>
> A file system that is properly tuned, and doing buffered IO will likely reduce the stripe cache usage. The stripe cache is basically where data gets put when the RAID is doing partial stripe IO's, calculating parity, or waiting for slow devices to complete their IO's. It's not intended to be yet another level of cache, so it gets purged when the RAID is done with it. So, unlike other caches that will hold onto data until there is memory pressure, the stripe cache is more likely to be empty.
>
> As far as adjusting stripe_cache_size... The stripe cache is dynamically allocated. It won't save any RAM by decreasing stripe_cache_size. Decreasing it too much will negatively impact performance as it's more likely you'll do Read-Modify-Write's when doing partial stripe writes.
>
I find that tuning it a bit higher (but not too high) has a very
positive impact on rebuild times (where we are therefore building
stripes). I can't remember exactly the values but we were setting it to
256 or 512 or even 1024 while building RAID5 or 6 with positive results.
Regards,
Ben.
> 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
>
> N�����r��y���b�X��ǧv�^�){.n�+����{�����{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!tml=
>
--
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: stripe_cache_active always 0
From: Roman Mamedov @ 2016-01-07 17:52 UTC (permalink / raw)
To: Robert Kierski; +Cc: Adam Goryachev, linux-raid@vger.kernel.org
In-Reply-To: <F7761B9B1D11B64BBB666019E9378117FE848B@CFWEX01.americas.cray.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On Thu, 7 Jan 2016 16:34:36 +0000
Robert Kierski <rkierski@cray.com> wrote:
> As far as adjusting stripe_cache_size... The stripe cache is dynamically allocated. It won't save any RAM by decreasing stripe_cache_size.
Since when?
# echo 512 > /sys/devices/virtual/block/md0/md/stripe_cache_size
# free
total used free shared buffers cached
Mem: 16159912 15672696 487216 12588 52 14484708
-/+ buffers/cache: 1187936 14971976
Swap: 0 0 0
# echo 32768 > /sys/devices/virtual/block/md0/md/stripe_cache_size
# free
total used free shared buffers cached
Mem: 16159912 15957880 202032 12588 52 14214952
-/+ buffers/cache: 1742876 14417036
Swap: 0 0 0
You can see that's not the case (on kernel 4.3.3 with four-member RAID5);
And it's quite easy to rapidly hit OOM issues on high-member-count arrays by
setting stripe_cache_size to larger values (not realizing that this is *in
pages* not kilobytes or sectors, and *per disk*).
As for the original question, try checking stripe_cache_active e.g. once
per second during heavy write load to the filesystem.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* RE: stripe_cache_active always 0
From: Robert Kierski @ 2016-01-07 16:34 UTC (permalink / raw)
To: Adam Goryachev, linux-raid@vger.kernel.org
In-Reply-To: <568DD6E6.6070107@websitemanagers.com.au>
Adam,
stripe_cache_active is the value to indicate how many pages are currently in use in the stripe cache. I could be wrong about this... but I don’t think you can disable the stripe cache. You can shrink it to an unreasonable size, but the minimum you can set stripe_cache_size to is 17 (pages).
Having said that, it may be that your RAID isn't using the stripe cache or that you're not checking the value frequently enough to see stripe cache activity.
A file system that is properly tuned, and doing buffered IO will likely reduce the stripe cache usage. The stripe cache is basically where data gets put when the RAID is doing partial stripe IO's, calculating parity, or waiting for slow devices to complete their IO's. It's not intended to be yet another level of cache, so it gets purged when the RAID is done with it. So, unlike other caches that will hold onto data until there is memory pressure, the stripe cache is more likely to be empty.
As far as adjusting stripe_cache_size... The stripe cache is dynamically allocated. It won't save any RAM by decreasing stripe_cache_size. Decreasing it too much will negatively impact performance as it's more likely you'll do Read-Modify-Write's when doing partial stripe writes.
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
* Hello linux
From: David Shine @ 2016-01-07 9:12 UTC (permalink / raw)
To: linux
Hi linux
http://www.livebyladybugs.com/wonderful.php?general=w1spfbe1mm531b
David Shine
^ permalink raw reply
* Re: [PATCH] async_tx: use GFP_NOWAIT rather than GFP_IO
From: Vinod Koul @ 2016-01-07 5:39 UTC (permalink / raw)
To: NeilBrown
Cc: Dan Williams, Stanislav Samsonov, linux-raid,
dmaengine@vger.kernel.org
In-Reply-To: <87k2nm9rz9.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]
On Thu, Jan 07, 2016 at 11:02:34AM +1100, NeilBrown wrote:
>
> 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.
>
> Fixed: 7476bd79fc01 ("async_pq: convert to dmaengine_unmap_data")
> Cc: stable@vger.kernel.org (v3.13+)
> Reported-and-tested-by: Stanislav Samsonov <slava@annapurnalabs.com>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
>
> Thanks for taking this Vinod.
> It is currently in linux-next from my md tree, but I've just de-staged
> it so the next linux-next won't have it from me.
Okay this is not in dmaengine. But since we all agreed, I have picked and
will send to Linus later today. If anyone has any objections please speak up
Thanks
--
~Vinod
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 00/35 v2] separate operations from flags in the bio/request structs
From: Dave Chinner @ 2016-01-07 3:13 UTC (permalink / raw)
To: Martin K. Petersen
Cc: mchristi, linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <yq14meqi2va.fsf@sermon.lab.mkp.net>
On Wed, Jan 06, 2016 at 08:40:09PM -0500, Martin K. Petersen wrote:
> >>>>> "Mike" == mchristi <mchristi@redhat.com> writes:
>
> Mike> The following patches begin to cleanup the request->cmd_flags and
> bio-> bi_rw mess. We currently use cmd_flags to specify the operation,
> Mike> attributes and state of the request. For bi_rw we use it for
> Mike> similar info and also the priority but then also have another
> Mike> bi_flags field for state. At some point, we abused them so much we
> Mike> just made cmd_flags 64 bits, so we could add more.
>
> Mike> The following patches seperate the operation (read, write discard,
> Mike> flush, etc) from cmd_flags/bi_rw.
>
> Mike> This patchset was made against linux-next from today Jan 5 2016.
> Mike> (git tag next-20160105).
>
> Very nice work. Thanks for doing this!
>
> I think it's a much needed cleanup. I focused mainly on the core block,
> discard, write same and sd.c pieces and everything looks sensible to me.
>
> I wonder what the best approach is to move a patch set with this many
> stakeholders forward? Set a "speak now or forever hold your peace"
> review deadline?
I say just ask Linus to pull it immediately after the next merge
window closes....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 13/35] xfs: set bi_op to REQ_OP
From: Dave Chinner @ 2016-01-07 3:11 UTC (permalink / raw)
To: mchristi
Cc: linux-bcache, linux-block, xfs, ocfs2-devel, linux-scsi,
konrad.wilk, linux-kernel, philipp.reisner, linux-f2fs-devel,
linux-raid, dm-devel, target-devel, linux-mtd, osd-dev,
linux-fsdevel, lars.ellenberg, linux-ext4, linux-btrfs, drbd-dev
In-Reply-To: <1452027218-32303-14-git-send-email-mchristi@redhat.com>
On Tue, Jan 05, 2016 at 02:53:16PM -0600, mchristi@redhat.com wrote:
> From: Mike Christie <mchristi@redhat.com>
>
> This patch has xfs set the bio bi_op to a REQ_OP, and
> rq_flag_bits to bi_rw.
>
> Note:
> I have run xfs tests on these btrfs patches. There were some failures
> with and without the patches. I have not had time to track down why
> xfstest fails without the patches.
>
> Signed-off-by: Mike Christie <mchristi@redhat.com>
> ---
> fs/xfs/xfs_aops.c | 3 ++-
> fs/xfs/xfs_buf.c | 27 +++++++++++++++------------
> 2 files changed, 17 insertions(+), 13 deletions(-)
Not sure which patches your note is refering to here.
The XFS change here looks fine.
Acked-by: Dave Chinner <dchinner@redhat.com>
-Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* stripe_cache_active always 0
From: Adam Goryachev @ 2016-01-07 3:09 UTC (permalink / raw)
To: linux-raid
I remember some years ago when I was building my storage servers I spent
a lot of time optimising performance, and eventually got some really
good stats and more importantly, good enough performance that users
stopped complaining, and things "just work".
However, when comparing config with another server, I noticed one of the
values I configured was stripe_cache_size, and I was setting this to
4096 (which was the peak performance compared to higher/lower numbers at
the time).
In any case, I'm looking at a "in use" system, and looking at
stripe_cache_active and it is always 0. I'm trying to find some docs on
what this value means?
Is the stripe cache disabled?
Are there just no stripes in the cache?
If it is always 0, then does it mean I don't need to adjust the
stripe_cache_size (I presume worst case is I am wasting RAM which is not
really important anyway).
Thanks,
Adam
--
Adam Goryachev
Website Managers
P: +61 2 8304 0000 adam@websitemanagers.com.au
F: +61 2 8304 0001 www.websitemanagers.com.au
^ permalink raw reply
* Re: [PATCH 00/35 v2] separate operations from flags in the bio/request structs
From: Martin K. Petersen @ 2016-01-07 1:40 UTC (permalink / raw)
To: mchristi-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA, xfs-VZNHf3L845pBDgjK7y7TUQ,
ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
osd-dev-yNzVSZO3znNg9hUCZPvPmw,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA,
linux-btrfs-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <1452027218-32303-1-git-send-email-mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>> "Mike" == mchristi <mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
Mike> The following patches begin to cleanup the request->cmd_flags and
bio-> bi_rw mess. We currently use cmd_flags to specify the operation,
Mike> attributes and state of the request. For bi_rw we use it for
Mike> similar info and also the priority but then also have another
Mike> bi_flags field for state. At some point, we abused them so much we
Mike> just made cmd_flags 64 bits, so we could add more.
Mike> The following patches seperate the operation (read, write discard,
Mike> flush, etc) from cmd_flags/bi_rw.
Mike> This patchset was made against linux-next from today Jan 5 2016.
Mike> (git tag next-20160105).
Very nice work. Thanks for doing this!
I think it's a much needed cleanup. I focused mainly on the core block,
discard, write same and sd.c pieces and everything looks sensible to me.
I wonder what the best approach is to move a patch set with this many
stakeholders forward? Set a "speak now or forever hold your peace"
review deadline?
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH 1/3] md: set MD_HAS_JOURNAL in correct places
From: NeilBrown @ 2016-01-07 0:28 UTC (permalink / raw)
To: Shaohua Li, linux-raid; +Cc: Kernel-team, songliubraving
In-Reply-To: <55aef157bf27c1de417577f02b69944a277a0141.1452119479.git.shli@fb.com>
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
On Thu, Jan 07 2016, Shaohua Li wrote:
> Set MD_HAS_JOURNAL when a array is loaded or journal is initialized.
> This is to avoid the flags set too early in journal disk hotadd.
>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> drivers/md/md.c | 8 ++++----
> drivers/md/raid5-cache.c | 1 +
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index c0c3e6d..e896320 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1607,6 +1607,10 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *rdev)
> mddev->new_chunk_sectors = mddev->chunk_sectors;
> }
>
> + if (mddev->recovery_cp == MaxSector)
> + set_bit(MD_JOURNAL_CLEAN, &mddev->flags);
> + if (le32_to_cpu(sb->feature_map) & MD_FEATURE_JOURNAL)
> + set_bit(MD_HAS_JOURNAL, &mddev->flags);
This looks wrong. I don't think it is safe to set MD_JOURNAL_CLEAR if
MD_HAS_JOURNAL is not set.
So I rearranged the code to:
if (le32_to_cpu(sb->feature_map) & MD_FEATURE_JOURNAL) {
set_bit(MD_HAS_JOURNAL, &mddev->flags);
if (mddev->recovery_cp == MaxSector)
set_bit(MD_JOURNAL_CLEAN, &mddev->flags);
}
Please say if you disagree.
I've applied this and the other two patches - thanks.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] imsm: use timeout when waiting for reshape progress
From: NeilBrown @ 2016-01-07 0:11 UTC (permalink / raw)
To: Artur Paszkiewicz, linux-raid
In-Reply-To: <1452010576-10733-1-git-send-email-artur.paszkiewicz@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
On Wed, Jan 06 2016, Artur Paszkiewicz wrote:
> Waiting for reshape progress is done by using select() on sync_completed
> to block until an exception condition is signalled on the
> filedescriptor. This happens when the attribute's value is updated by
> the kernel, but if the array is stopped when mdadm is blocked on
> select() this will never happen, because this attribute is then removed
> and apparently the kernel doesn't do sysfs_notify() when removing a
> sysfs attribute. So set a 3 second timeout for the sysfs_wait() call.
I wonder if we should fix that in the kernel somehow...
I've applied this patch and the following one - thanks.
NeilBrown
>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> super-intel.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/super-intel.c b/super-intel.c
> index 98fe835..68cc8d6 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -10297,7 +10297,8 @@ int wait_for_reshape_imsm(struct mdinfo *sra, int ndata)
>
> do {
> char action[20];
> - sysfs_wait(fd, NULL);
> + int timeout = 3000;
> + sysfs_wait(fd, &timeout);
> if (sysfs_get_str(sra, NULL, "sync_action",
> action, 20) > 0 &&
> strncmp(action, "reshape", 7) != 0) {
> --
> 2.1.4
>
> --
> 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
* [PATCH] async_tx: use GFP_NOWAIT rather than GFP_IO
From: NeilBrown @ 2016-01-07 0:02 UTC (permalink / raw)
To: Vinod Koul, Dan Williams
Cc: Stanislav Samsonov, linux-raid, dmaengine@vger.kernel.org
In-Reply-To: <20160106090811.GO2940@localhost>
[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]
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.
Fixed: 7476bd79fc01 ("async_pq: convert to dmaengine_unmap_data")
Cc: stable@vger.kernel.org (v3.13+)
Reported-and-tested-by: Stanislav Samsonov <slava@annapurnalabs.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.com>
---
Thanks for taking this Vinod.
It is currently in linux-next from my md tree, but I've just de-staged
it so the next linux-next won't have it from me.
NeilBrown
crypto/async_tx/async_memcpy.c | 2 +-
crypto/async_tx/async_pq.c | 4 ++--
crypto/async_tx/async_raid6_recov.c | 4 ++--
crypto/async_tx/async_xor.c | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
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)) {
--
2.6.4
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply related
* Re: [PATCH 02/35] block: add REQ_OP definitions and bi_op/op fields
From: Martin K. Petersen @ 2016-01-06 23:17 UTC (permalink / raw)
To: mchristi-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA, xfs-VZNHf3L845pBDgjK7y7TUQ,
ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
osd-dev-yNzVSZO3znNg9hUCZPvPmw,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA,
linux-btrfs-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <1452027218-32303-3-git-send-email-mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>> "Mike" == mchristi <mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
+enum req_op {
+ REQ_OP_READ,
+ REQ_OP_WRITE = REQ_WRITE,
+ REQ_OP_DISCARD = REQ_DISCARD,
+ REQ_OP_WRITE_SAME = REQ_WRITE_SAME,
+};
+
I have been irked by the REQ_ prefix in bios since the flags were
consolidated a while back. When I attempted to fix the READ/WRITE mess I
used a BLK_ prefix as a result.
Anyway. Just bikeshedding...
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [PATCH 3/3] raid5-cache: handle journal hotadd in quiesce
From: Shaohua Li @ 2016-01-06 22:37 UTC (permalink / raw)
To: linux-raid; +Cc: Kernel-team, songliubraving, neilb
In-Reply-To: <55aef157bf27c1de417577f02b69944a277a0141.1452119479.git.shli@fb.com>
Handle journal hotadd in quiesce to avoid creating duplicated threads.
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/md/raid5-cache.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 16cf876..4e36eec 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -834,6 +834,13 @@ void r5l_quiesce(struct r5conf *conf, int state)
return;
if (state == 0) {
log->in_teardown = 0;
+ /*
+ * This is a special case for hotadd. In suspend, the array has
+ * no journal. In resume, journal is initialized as well as the
+ * reclaim thread.
+ */
+ if (log->reclaim_thread)
+ return;
log->reclaim_thread = md_register_thread(r5l_reclaim_thread,
log->rdev->mddev, "reclaim");
} else if (state == 1) {
--
2.4.6
^ permalink raw reply related
* [PATCH 2/3] MD: add journal with array suspended
From: Shaohua Li @ 2016-01-06 22:37 UTC (permalink / raw)
To: linux-raid; +Cc: Kernel-team, songliubraving, neilb
In-Reply-To: <55aef157bf27c1de417577f02b69944a277a0141.1452119479.git.shli@fb.com>
Hot add journal disk in recovery thread context brings a lot of trouble
as IO could be running. Unlike spare disk hot add, adding journal disk
with array suspended makes more sense and implmentation is much easier.
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/md/md.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index e896320..dad9a25 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2464,15 +2464,20 @@ static int add_bound_rdev(struct md_rdev *rdev)
{
struct mddev *mddev = rdev->mddev;
int err = 0;
+ bool add_journal = test_bit(Journal, &rdev->flags);
- if (!mddev->pers->hot_remove_disk) {
+ if (!mddev->pers->hot_remove_disk || add_journal) {
/* If there is hot_add_disk but no hot_remove_disk
* then added disks for geometry changes,
* and should be added immediately.
*/
super_types[mddev->major_version].
validate_super(mddev, rdev);
+ if (add_journal)
+ mddev_suspend(mddev);
err = mddev->pers->hot_add_disk(mddev, rdev);
+ if (add_journal)
+ mddev_resume(mddev);
if (err) {
unbind_rdev_from_array(rdev);
export_rdev(rdev);
--
2.4.6
^ permalink raw reply related
* [PATCH 1/3] md: set MD_HAS_JOURNAL in correct places
From: Shaohua Li @ 2016-01-06 22:37 UTC (permalink / raw)
To: linux-raid; +Cc: Kernel-team, songliubraving, neilb
Set MD_HAS_JOURNAL when a array is loaded or journal is initialized.
This is to avoid the flags set too early in journal disk hotadd.
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/md/md.c | 8 ++++----
drivers/md/raid5-cache.c | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index c0c3e6d..e896320 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -1607,6 +1607,10 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *rdev)
mddev->new_chunk_sectors = mddev->chunk_sectors;
}
+ if (mddev->recovery_cp == MaxSector)
+ set_bit(MD_JOURNAL_CLEAN, &mddev->flags);
+ if (le32_to_cpu(sb->feature_map) & MD_FEATURE_JOURNAL)
+ set_bit(MD_HAS_JOURNAL, &mddev->flags);
} else if (mddev->pers == NULL) {
/* Insist of good event counter while assembling, except for
* spares (which don't need an event count) */
@@ -1653,8 +1657,6 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *rdev)
}
set_bit(Journal, &rdev->flags);
rdev->journal_tail = le64_to_cpu(sb->journal_tail);
- if (mddev->recovery_cp == MaxSector)
- set_bit(MD_JOURNAL_CLEAN, &mddev->flags);
rdev->raid_disk = 0;
break;
default:
@@ -1674,8 +1676,6 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *rdev)
set_bit(WriteMostly, &rdev->flags);
if (le32_to_cpu(sb->feature_map) & MD_FEATURE_REPLACEMENT)
set_bit(Replacement, &rdev->flags);
- if (le32_to_cpu(sb->feature_map) & MD_FEATURE_JOURNAL)
- set_bit(MD_HAS_JOURNAL, &mddev->flags);
} else /* MULTIPATH are always insync */
set_bit(In_sync, &rdev->flags);
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 31e0fad..16cf876 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -1242,6 +1242,7 @@ int r5l_init_log(struct r5conf *conf, struct md_rdev *rdev)
goto error;
rcu_assign_pointer(conf->log, log);
+ set_bit(MD_HAS_JOURNAL, &conf->mddev->flags);
return 0;
error:
--
2.4.6
^ permalink raw reply related
* Re: [PATCH 25/35] target: set bi_op to REQ_OP
From: Nicholas A. Bellinger @ 2016-01-06 19:06 UTC (permalink / raw)
To: mchristi
Cc: linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <1452027218-32303-26-git-send-email-mchristi@redhat.com>
Hi Mike,
On Tue, 2016-01-05 at 14:53 -0600, mchristi@redhat.com wrote:
> From: Mike Christie <mchristi@redhat.com>
>
> This patch has the target modules set the bio bi_op to a REQ_OP, and
> rq_flag_bits to bi_rw.
>
> This patch is compile tested only.
>
> Signed-off-by: Mike Christie <mchristi@redhat.com>
> ---
> drivers/target/target_core_iblock.c | 38 ++++++++++++++++++++++---------------
> drivers/target/target_core_pscsi.c | 2 +-
> 2 files changed, 24 insertions(+), 16 deletions(-)
>
Nice work to clean this long standing abuse. ;)
For the target/iblock bit:
Acked-by: Nicholas Bellinger <nab@linux-iscsi.org>
^ permalink raw reply
* Re: [dm-devel] WANTED new maintainer for Linux/md (and mdadm)
From: Jes Sorensen @ 2016-01-06 16:53 UTC (permalink / raw)
To: Brassow Jonathan
Cc: device-mapper development, linux-raid, LKML, J. Bruce Fields,
Phil Turmel, Linus Torvalds, Doug Ledford, NeilBrown, Xiao Ni
In-Reply-To: <0AAF8A3C-BE70-4510-A8EA-F64B2F4A0B4D@redhat.com>
Brassow Jonathan <jbrassow@redhat.com> writes:
> Many thanks Neil for all the work you’ve done and the help you gave me
> while working on the DM/MD interactions bits. I’m happy you are
> sticking around for the raid1-cluster and raid5-journal bits and I’m
> interested to see what comes out of those.
>
> I know there are a number of folks around Red Hat who are capable and
> possibly interested to share the load. They should be back from PTO
> soon and we’ll make sure they know about the opportunity.
Thanks Neil!
I mentioned to Neil last year that I could probably be convinced,
bribed, shamed, into maintaining mdadm.
The kernel MD stack I think really needs a team to run it. There is just
too much internal knowledge sitting in Neil's head and I personally am a
little scared of taking on that. Shaohua Li would be a good candidate
for that team IMHO.
Cheers,
Jes
> thanks,
> brassow
>
>> On Dec 21, 2015, at 12:10 AM, NeilBrown <neilb@suse.com> wrote:
>>
>>
>> hi,
>> I became maintainer for md (Linux Software RAID) in late 2001 and on
>> the whole it has been fun and a valuable experience. But I have been
>> losing interest in recent years (https://lwn.net/Articles/511073/) and
>> as was mentioned at the kernel summit, I would like to resign. Some
>> years ago I managed to hand over nfsd to the excellent Bruce Fields,
>> but I do not seem to have the gift that Linus has of attracting
>> maintainers. While there are a number of people who know quite a bit
>> about md and/or have contributed to development, there is no obvious
>> candidate for replacement maintainer - no one who has already been
>> doing significant parts of the maintainer role.
>>
>> So I have decided to fall back on the mechanism by which I ended up
>> being maintainer in the first place. I will create a vacuum and hope
>> someone fills it (yes: I was sucked-in....). So as of 1st February
>> 2016 I will be resigning.
>>
>> At the kernel summit in October Linus talked about the value of
>> maintainership teams (https://lwn.net/Articles/662979/). I think it
>> would be great if a (small) team formed to continue to oversee md
>> rather than just a single individual (or maybe the dm team could extend
>> to include md??). If I had managed to be part of a team rather than
>> "going it alone" for so long, I might feel less tired of the whole
>> thing now.
>>
>> I don't see it as my place to appoint that team or any individuals, or
>> even to nominate any candidates. A very important attribute of a
>> maintainer is that they need to care about the code and the subsystem
>> and I cannot tell other people to care (or even know if they do). It
>> is really up to individuals to volunteer. A few people have been
>> mentioned to me in earlier less-public conversations. Any of them may
>> well be suitable, but I would rather they named themselves if
>> interested.
>>
>> So I'm hoping to get one or more volunteers to be maintainer:
>> - to gather and manage patches and outstanding issues,
>> - to review patches or get them reviewed
>> - to follow up bug reports and get them resolved
>> - to feed patches upstream, maybe directly to Linus,
>> maybe through some other maintainer, depending on what
>> relationships already exist or can be formed,
>> - to guide the longer term direction (saying "no" is important
>> sometimes),
>> - to care,
>> but also to be aware that maintainership takes real effort and time, as
>> does anything that is really worthwhile.
>>
>> This all applies to mdadm as well as md (except you would ultimately
>> *be* upstream for mdadm, not needing to send it anywhere). Even if a
>> clear team doesn't form it would be great if different people
>> maintained mdadm and md.
>>
>> One part of the job that I have put a lot of time in to is following
>> the linux-raid@vger.kernel.org list and providing support. This makes
>> people feel good about md and so more adventurous in using it.
>> Consequently I tend to hear about bugs and usability issues nice and
>> early (well before paying customers hit them in most cases) and that is
>> a big win.
>> In recent times I've been doing less of this and have been absolutely
>> thrilled that the gap has been more than filled by other very competent
>> community members. Not developers particular but a number of md users
>> have been providing excellent support. I'd particularly like to
>> high-light Phil Turmel who is very forthcoming with excellent advice,
>> but he is certainly not the only one who deserves a lot of thanks.
>> So "Thank you" to everyone who answers questions on linux-raid.
>>
>> This would be a good place for any future maintainer to hang out to
>> receive wisdom as well as to provide support.
>>
>> I will still be around. I can certainly help out in some sort of
>> mentor role, and can probably be convinced to review patches and
>> comment on designs. But I really want to head towards spending less
>> time on md (there are so many other interesting things to learn about).
>>
>> So: if anyone is interested - please announce yourself, ask questions
>> and start doing things. I have no clear idea about how a transition
>> will happen. That is really up to you (plural). Take the bull by the
>> horns and start *being* a maintainer(team). I won't get in your way
>> and I'll help where I can.
>>
>> Thanks,
>> NeilBrown
>>
>> P.S. I'm committed to continue to work with the raid5-journal effort
>> From Facebook and the raid1-cluster effort from SUSE and the
>> line-in-the-sand of 1st February won't affect my support for those.
>> --
>> dm-devel mailing list
>> dm-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/dm-devel
>
> --
> 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