* Re: Best option for SSD caching on a md raid array?
From: Pasi Kärkkäinen @ 2016-02-10 22:54 UTC (permalink / raw)
To: John Stoffel; +Cc: Thomas Fjellstrom, linux-raid
In-Reply-To: <22203.47103.654951.880508@quad.stoffel.home>
On Wed, Feb 10, 2016 at 05:21:51PM -0500, John Stoffel wrote:
> >>>>> "Pasi" == Pasi Kärkkäinen <pasik@iki.fi> writes:
>
> Pasi> On Mon, Feb 08, 2016 at 10:34:09AM -0500, John Stoffel wrote:
> >>
> Thomas> I'm planning on setting up a dual raid5 array for hosting vm's
> Thomas> off LVM, I would like to add an ssd cache to help with typical
> Thomas> server system loads, and some mixed read/write loads for game
> Thomas> servers.
> >>
> Thomas> I'm wondering what the "best" route for me to go is. There's a
> Thomas> few options that I know of, like flashcache, dm-cache, and
> Thomas> bcache. The question is which of those is better suited to my
> Thomas> use case?
> >>
> >> I looked into both bcache and lvmcache and went with lvmcache because
> >> it made more sense to me. But one restriction is that the cache LVs
> >> must be in the same VGs as the volume to cache. So you might need to
> >> partition your SSD(s) and put the partitions into seperate VGs so that
> >> you can cache one or more LVs.
> >>
> >> I'm using it at home to cache a RAID1 4tb VG, with a pair of mirrored
> >> SSDs. I'm a big believer in mirroring, esp for critical stuff like
> >> this.
> >>
> >> Unfortunately, I don't have a good performance measurements of how
> >> much help this actually gives me. It *feels* faster, but since I
> >> don't have before/after measurements, I could just have wasted a bunch
> >> of money.
> >>
> >> So I'd recommend lvmcache overall, since it does seem to help, but
> >> push for better performance metrics and measurement. Heh, maybe it's
> >> time for me to start writing up lvmcachetop to help measure things.
>
> Pasi> The other day I was benchmarking lvmcache (on CentOS 7.2), but I
> Pasi> couldn't get it to give much advantage for writeback caching use
> Pasi> case.. even when I was using fast nvme/pcie cache device.
>
> What were you using? I should spin up fio and see what I can
> find... or maybe even just some kernel compiles, image manipulation,
> etc.
>
Yeah I was benchmarking small random 4 kB writes, using fio.
iodepth=64 and jobs=12.
> Let's see what we can come up with for benchmarking, since it would be
> a big help! I'm running kernel 4.4-rc7 right now on a Debian Jessie system.
>
> Pasi> It just wouldn't cache writes properly for me. I tried both the
> Pasi> smq and mq, and played with all of the parameters.. it just
> Pasi> wouldn't help much for my use case.
>
> I have both mq and smq compiled into the kernel, so I can't figure out
> how to change between them to test.
>
Hmm, yeah, I think it was documented on the lvmcache man page.
I can't check my notes right now..
> John
-- Pasi
--
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: Best option for SSD caching on a md raid array?
From: John Stoffel @ 2016-02-10 22:21 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: John Stoffel, Thomas Fjellstrom, linux-raid
In-Reply-To: <20160210221345.GB2461@reaktio.net>
>>>>> "Pasi" == Pasi Kärkkäinen <pasik@iki.fi> writes:
Pasi> On Mon, Feb 08, 2016 at 10:34:09AM -0500, John Stoffel wrote:
>>
Thomas> I'm planning on setting up a dual raid5 array for hosting vm's
Thomas> off LVM, I would like to add an ssd cache to help with typical
Thomas> server system loads, and some mixed read/write loads for game
Thomas> servers.
>>
Thomas> I'm wondering what the "best" route for me to go is. There's a
Thomas> few options that I know of, like flashcache, dm-cache, and
Thomas> bcache. The question is which of those is better suited to my
Thomas> use case?
>>
>> I looked into both bcache and lvmcache and went with lvmcache because
>> it made more sense to me. But one restriction is that the cache LVs
>> must be in the same VGs as the volume to cache. So you might need to
>> partition your SSD(s) and put the partitions into seperate VGs so that
>> you can cache one or more LVs.
>>
>> I'm using it at home to cache a RAID1 4tb VG, with a pair of mirrored
>> SSDs. I'm a big believer in mirroring, esp for critical stuff like
>> this.
>>
>> Unfortunately, I don't have a good performance measurements of how
>> much help this actually gives me. It *feels* faster, but since I
>> don't have before/after measurements, I could just have wasted a bunch
>> of money.
>>
>> So I'd recommend lvmcache overall, since it does seem to help, but
>> push for better performance metrics and measurement. Heh, maybe it's
>> time for me to start writing up lvmcachetop to help measure things.
Pasi> The other day I was benchmarking lvmcache (on CentOS 7.2), but I
Pasi> couldn't get it to give much advantage for writeback caching use
Pasi> case.. even when I was using fast nvme/pcie cache device.
What were you using? I should spin up fio and see what I can
find... or maybe even just some kernel compiles, image manipulation,
etc.
Let's see what we can come up with for benchmarking, since it would be
a big help! I'm running kernel 4.4-rc7 right now on a Debian Jessie system.
Pasi> It just wouldn't cache writes properly for me. I tried both the
Pasi> smq and mq, and played with all of the parameters.. it just
Pasi> wouldn't help much for my use case.
I have both mq and smq compiled into the kernel, so I can't figure out
how to change between them to test.
John
--
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: Best option for SSD caching on a md raid array?
From: Pasi Kärkkäinen @ 2016-02-10 22:13 UTC (permalink / raw)
To: John Stoffel; +Cc: Thomas Fjellstrom, linux-raid
In-Reply-To: <22200.46449.482559.914441@quad.stoffel.home>
On Mon, Feb 08, 2016 at 10:34:09AM -0500, John Stoffel wrote:
>
> Thomas> I'm planning on setting up a dual raid5 array for hosting vm's
> Thomas> off LVM, I would like to add an ssd cache to help with typical
> Thomas> server system loads, and some mixed read/write loads for game
> Thomas> servers.
>
> Thomas> I'm wondering what the "best" route for me to go is. There's a
> Thomas> few options that I know of, like flashcache, dm-cache, and
> Thomas> bcache. The question is which of those is better suited to my
> Thomas> use case?
>
> I looked into both bcache and lvmcache and went with lvmcache because
> it made more sense to me. But one restriction is that the cache LVs
> must be in the same VGs as the volume to cache. So you might need to
> partition your SSD(s) and put the partitions into seperate VGs so that
> you can cache one or more LVs.
>
> I'm using it at home to cache a RAID1 4tb VG, with a pair of mirrored
> SSDs. I'm a big believer in mirroring, esp for critical stuff like
> this.
>
> Unfortunately, I don't have a good performance measurements of how
> much help this actually gives me. It *feels* faster, but since I
> don't have before/after measurements, I could just have wasted a bunch
> of money.
>
> So I'd recommend lvmcache overall, since it does seem to help, but
> push for better performance metrics and measurement. Heh, maybe it's
> time for me to start writing up lvmcachetop to help measure things.
>
The other day I was benchmarking lvmcache (on CentOS 7.2),
but I couldn't get it to give much advantage for writeback caching use case..
even when I was using fast nvme/pcie cache device.
It just wouldn't cache writes properly for me. I tried both the smq and mq,
and played with all of the parameters.. it just wouldn't help much for my use case.
YMMV.
> John
-- Pasi
^ permalink raw reply
* Re: [PATCH 2/3][mdadm] mdadm.h: bswap is already defined in uclibc
From: Jes Sorensen @ 2016-02-10 19:20 UTC (permalink / raw)
To: Maxin B. John; +Cc: linux-raid, Maxin B. John
In-Reply-To: <CAMhs6YwxytaKNJ-v9J714whBxgDxz_cQ9t8qi-wSp5Ho--vjfQ@mail.gmail.com>
"Maxin B. John" <maxin.john@gmail.com> writes:
> Hi Jes,
>
> On Mon, Feb 8, 2016 at 6:00 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> "Maxin B. John" <maxin.john@gmail.com> writes:
>>> From: "Maxin B. John" <maxin.john@intel.com>
>>>
>>> Fixes this build error:
>>>
>>> | In file included from mdadm.c:28:0:
>>> | mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
>>> | #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
>>> | ^
>>>
>>> Signed-off-by: Maxin B. John <maxin.john@intel.com>
>>> ---
>>> mdadm.h | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>
>> Hi Maxin,
>>
>> I am not opposed to this, but I would like to understand why you see
>> these duplicate defines. What defines it in your build environment?
>
>
> I get the below listed error message with uclibc builds:
<ship>
> | In file included from mdadm.c:28:0:
> | mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
> | #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
> | ^
> | In file included from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
> | from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
> | from mdadm.h:36,
> | from mdadm.c:28:
> | /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:29:0:
> note: this is the location of the previous definition
> | #define bswap_16(x) __bswap_16 (x)
> | ^
> | In file included from mdadm.c:28:0:
> | mdadm.h:144:0: error: "bswap_32" redefined [-Werror]
> | #define bswap_32(x) (((x) & 0x000000ffU) << 24 | \
> | ^
> | In file included from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
> | from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
> | from mdadm.h:36,
> | from mdadm.c:28:
> | /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:32:0:
> note: this is the location of the previous definition
> | #define bswap_32(x) __bswap_32 (x)
> | ^
> | In file included from mdadm.c:28:0:
> | mdadm.h:148:0: error: "bswap_64" redefined [-Werror]
> | #define bswap_64(x) (((x) & 0x00000000000000ffULL) << 56 | \
> | ^
> | In file included from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
> | from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
> | from mdadm.h:36,
> | from mdadm.c:28:
> | /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:36:0:
> note: this is the location of the previous definition
> | # define bswap_64(x) __bswap_64 (x)
> | ^
> | In file included from config.c:25:0:
> | mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
> | #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
> | ^
> | In file included from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
> | from
> /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
> | from mdadm.h:36,
> | from config.c:25:
> | /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:29:0:
> note: this is the location of the previous definition
> | #define bswap_16(x) __bswap_16 (x)
> | ^
> ......
Maxin,
I think it's actually wrong for uClibc to expose those macros with such
a common name, but rather than picking up outside macros randomly I
prefer to rename the mdadm ones to be sure we know what we are getting.
Instead of your patch, I applied this one instead. I hope that is fine
with you.
Cheers,
Jes
From dd47b4e0c45fd72b94a9a7d0f0a5046ef9c8d97b Mon Sep 17 00:00:00 2001
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Date: Wed, 10 Feb 2016 14:15:38 -0500
Subject: [PATCH] mdadm.h: rename bswap macros to avoid clash with uClibc
definitions
uClibc exposes it's own version of bswap_<X> macros. Rather than
pulling in random macros by change, rename the mdadm ones to make sure
we know what we are getting.
Reported-by: "Maxin B. John" <maxin.john@gmail.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
mdadm.h | 52 ++++++++++++++++++++++++++--------------------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/mdadm.h b/mdadm.h
index dd02be7..72888e2 100755
--- a/mdadm.h
+++ b/mdadm.h
@@ -139,20 +139,20 @@ struct dlm_lksb {
* and there is no standard conversion function so... */
/* And dietlibc doesn't think byteswap is ok, so.. */
/* #include <byteswap.h> */
-#define bswap_16(x) (((x) & 0x00ffU) << 8 | \
- ((x) & 0xff00U) >> 8)
-#define bswap_32(x) (((x) & 0x000000ffU) << 24 | \
- ((x) & 0xff000000U) >> 24 | \
- ((x) & 0x0000ff00U) << 8 | \
- ((x) & 0x00ff0000U) >> 8)
-#define bswap_64(x) (((x) & 0x00000000000000ffULL) << 56 | \
- ((x) & 0xff00000000000000ULL) >> 56 | \
- ((x) & 0x000000000000ff00ULL) << 40 | \
- ((x) & 0x00ff000000000000ULL) >> 40 | \
- ((x) & 0x0000000000ff0000ULL) << 24 | \
- ((x) & 0x0000ff0000000000ULL) >> 24 | \
- ((x) & 0x00000000ff000000ULL) << 8 | \
- ((x) & 0x000000ff00000000ULL) >> 8)
+#define __mdadm_bswap_16(x) (((x) & 0x00ffU) << 8 | \
+ ((x) & 0xff00U) >> 8)
+#define __mdadm_bswap_32(x) (((x) & 0x000000ffU) << 24 | \
+ ((x) & 0xff000000U) >> 24 | \
+ ((x) & 0x0000ff00U) << 8 | \
+ ((x) & 0x00ff0000U) >> 8)
+#define __mdadm_bswap_64(x) (((x) & 0x00000000000000ffULL) << 56 | \
+ ((x) & 0xff00000000000000ULL) >> 56 | \
+ ((x) & 0x000000000000ff00ULL) << 40 | \
+ ((x) & 0x00ff000000000000ULL) >> 40 | \
+ ((x) & 0x0000000000ff0000ULL) << 24 | \
+ ((x) & 0x0000ff0000000000ULL) >> 24 | \
+ ((x) & 0x00000000ff000000ULL) << 8 | \
+ ((x) & 0x000000ff00000000ULL) >> 8)
#if !defined(__KLIBC__)
#if BYTE_ORDER == LITTLE_ENDIAN
@@ -163,19 +163,19 @@ struct dlm_lksb {
#define __le32_to_cpu(_x) (unsigned int)(_x)
#define __le64_to_cpu(_x) (unsigned long long)(_x)
-#define __cpu_to_be16(_x) bswap_16(_x)
-#define __cpu_to_be32(_x) bswap_32(_x)
-#define __cpu_to_be64(_x) bswap_64(_x)
-#define __be16_to_cpu(_x) bswap_16(_x)
-#define __be32_to_cpu(_x) bswap_32(_x)
-#define __be64_to_cpu(_x) bswap_64(_x)
+#define __cpu_to_be16(_x) __mdadm_bswap_16(_x)
+#define __cpu_to_be32(_x) __mdadm_bswap_32(_x)
+#define __cpu_to_be64(_x) __mdadm_bswap_64(_x)
+#define __be16_to_cpu(_x) __mdadm_bswap_16(_x)
+#define __be32_to_cpu(_x) __mdadm_bswap_32(_x)
+#define __be64_to_cpu(_x) __mdadm_bswap_64(_x)
#elif BYTE_ORDER == BIG_ENDIAN
-#define __cpu_to_le16(_x) bswap_16(_x)
-#define __cpu_to_le32(_x) bswap_32(_x)
-#define __cpu_to_le64(_x) bswap_64(_x)
-#define __le16_to_cpu(_x) bswap_16(_x)
-#define __le32_to_cpu(_x) bswap_32(_x)
-#define __le64_to_cpu(_x) bswap_64(_x)
+#define __cpu_to_le16(_x) __mdadm_bswap_16(_x)
+#define __cpu_to_le32(_x) __mdadm_bswap_32(_x)
+#define __cpu_to_le64(_x) __mdadm_bswap_64(_x)
+#define __le16_to_cpu(_x) __mdadm_bswap_16(_x)
+#define __le32_to_cpu(_x) __mdadm_bswap_32(_x)
+#define __le64_to_cpu(_x) __mdadm_bswap_64(_x)
#define __cpu_to_be16(_x) (unsigned int)(_x)
#define __cpu_to_be32(_x) (unsigned int)(_x)
--
2.5.0
^ permalink raw reply related
* Good day
From: fu.zhongjun @ 2016-02-10 16:34 UTC (permalink / raw)
To: Recipients
Good day,
I need a foreign partner for a proposed mutual business, which refers to the transfer of a large sum of money to an account abroad, as the beneficiary of the funds. Everything about this operation, will be legally done without any bridge financial authority, both in my country and yours.I wil indulge you exercise the utmost discretion in all matters concerning this issue. If you are interested, please reply back through my private email address written down, I'll give you more information about myself with the financial institution I represented and the actual amounts involved about the project so I receive your positive response.
Private E-mail: fu.zhong@fuzhongjun.net
Friendly greeting,
Executive director.
^ permalink raw reply
* Re: [dm-devel] [patch] dm: check for kmalloc failure in dm_init_request_based_blk_mq_queue()
From: Johannes Thumshirn @ 2016-02-09 11:35 UTC (permalink / raw)
To: Dan Carpenter
Cc: Alasdair Kergon, Mike Snitzer, linux-raid, kernel-janitors,
dm-devel, Shaohua Li, linux-kernel
In-Reply-To: <20160209111440.GB23998@mwanda>
On Tue, Feb 09, 2016 at 02:14:40PM +0300, Dan Carpenter wrote:
> We can just return -ENOMEM if the kzalloc() fails.
>
> Fixes: 41b2facaf4ba ('dm: allocate blk_mq_tag_set rather than embed in mapped_device')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 6b7e80e..1a5f879 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -2736,6 +2736,8 @@ static int dm_init_request_based_blk_mq_queue(struct mapped_device *md,
> int err;
>
> md->tag_set = kzalloc(sizeof(struct blk_mq_tag_set), GFP_KERNEL);
> + if (!md->tag_set)
> + return -ENOMEM;
> md->tag_set->ops = &dm_mq_ops;
> md->tag_set->queue_depth = dm_get_blk_mq_queue_depth();
> md->tag_set->numa_node = NUMA_NO_NODE;
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
Good catch,
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [patch] dm: check for kmalloc failure in dm_init_request_based_blk_mq_queue()
From: Dan Carpenter @ 2016-02-09 11:14 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer
Cc: dm-devel, Shaohua Li, linux-raid, linux-kernel, kernel-janitors
We can just return -ENOMEM if the kzalloc() fails.
Fixes: 41b2facaf4ba ('dm: allocate blk_mq_tag_set rather than embed in mapped_device')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 6b7e80e..1a5f879 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2736,6 +2736,8 @@ static int dm_init_request_based_blk_mq_queue(struct mapped_device *md,
int err;
md->tag_set = kzalloc(sizeof(struct blk_mq_tag_set), GFP_KERNEL);
+ if (!md->tag_set)
+ return -ENOMEM;
md->tag_set->ops = &dm_mq_ops;
md->tag_set->queue_depth = dm_get_blk_mq_queue_depth();
md->tag_set->numa_node = NUMA_NO_NODE;
^ permalink raw reply related
* Re: Best option for SSD caching on a md raid array?
From: Thomas Fjellstrom @ 2016-02-08 20:21 UTC (permalink / raw)
To: David Brown; +Cc: linux-raid
In-Reply-To: <56B85390.9050505@hesbynett.no>
On Mon Feb 8 2016 09:36:32 AM you wrote:
> Hi,
>
> If the server is going to have reasonably long uptimes, then lots of ram
> could easily be a better choice than an SSD caching system. I don't
> know how you are planning your "dual raid5 array", nor what sort of VM's
> you are dealing with. But the key point of an SSD cache is to get fast
> access to common data with random access patterns, since a raid array
> will give you plenty of bandwidth for large serial accesses. And while
> an SSD is fast for random reads, having the data in the server's cache
> is even faster.
Basically I have two servers, one is an older single socket xeon e3 with 16GB
ram, that tops out at 32GB IIRC (if i can find reasonably priced non buffered
8GB ddr3 ecc DIMMs). And my other box is a dual socket 32 core (2x16) Opteron
box with about 120GB ram.
I'm planning on having each machine have a storage array that are synced using
DRBD or something similar. The idea is to allow online migration with little
fuss, not having to access storage over the network, and have what is
essentially a raid 1 on top of the raid5 on each machine.
The Xeon box has a fair bit less resources (except per core perf is probably
better), and may have issues caching things in ram.
The main use case of both machines is to host various services, like a couple
game servers, plex, gitlab, unifi controller, testing/staging instances for
various services for work. Also a couple windows vms.
So its a mix of things.
> On 08/02/16 06:14, Thomas Fjellstrom wrote:
> > Hi,
> >
> > I'm planning on setting up a dual raid5 array for hosting vm's off LVM, I
> > would like to add an ssd cache to help with typical server system loads,
> > and some mixed read/write loads for game servers.
> >
> > I'm wondering what the "best" route for me to go is. There's a few options
> > that I know of, like flashcache, dm-cache, and bcache. The question is
> > which of those is better suited to my use case?
> >
> > Also wondering which ones people here use, and what they use it for.
> >
> > Thanks!
>
> --
> 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 2/3][mdadm] mdadm.h: bswap is already defined in uclibc
From: Maxin B. John @ 2016-02-08 16:10 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-raid, Maxin B. John
In-Reply-To: <wrfjsi13dweh.fsf@redhat.com>
Hi Jes,
On Mon, Feb 8, 2016 at 6:00 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> "Maxin B. John" <maxin.john@gmail.com> writes:
>> From: "Maxin B. John" <maxin.john@intel.com>
>>
>> Fixes this build error:
>>
>> | In file included from mdadm.c:28:0:
>> | mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
>> | #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
>> | ^
>>
>> Signed-off-by: Maxin B. John <maxin.john@intel.com>
>> ---
>> mdadm.h | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>
> Hi Maxin,
>
> I am not opposed to this, but I would like to understand why you see
> these duplicate defines. What defines it in your build environment?
I get the below listed error message with uclibc builds:
| x86_64-poky-linux-uclibc-gcc -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/home/maxin/poky/build/tmp/sysroots/qemux86-64
-Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o mdadm.o mdadm.c
| x86_64-poky-linux-uclibc-gcc -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/home/maxin/poky/build/tmp/sysroots/qemux86-64
-Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o config.o config.c
| x86_64-poky-linux-uclibc-gcc -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/home/maxin/poky/build/tmp/sysroots/qemux86-64
-Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o policy.o policy.c
| x86_64-poky-linux-uclibc-gcc -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/home/maxin/poky/build/tmp/sysroots/qemux86-64
-Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o mdstat.o mdstat.c
| x86_64-poky-linux-uclibc-gcc -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/home/maxin/poky/build/tmp/sysroots/qemux86-64
-Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o ReadMe.o ReadMe.c
| x86_64-poky-linux-uclibc-gcc -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/home/maxin/poky/build/tmp/sysroots/qemux86-64
-Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o util.o util.c
| x86_64-poky-linux-uclibc-gcc -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/home/maxin/poky/build/tmp/sysroots/qemux86-64
-Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -O2
-pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\"
-DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\"
-DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\"
-DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM
-DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o maps.o maps.c
| In file included from mdadm.c:28:0:
| mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
| #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
| ^
| In file included from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
| from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
| from mdadm.h:36,
| from mdadm.c:28:
| /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:29:0:
note: this is the location of the previous definition
| #define bswap_16(x) __bswap_16 (x)
| ^
| In file included from mdadm.c:28:0:
| mdadm.h:144:0: error: "bswap_32" redefined [-Werror]
| #define bswap_32(x) (((x) & 0x000000ffU) << 24 | \
| ^
| In file included from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
| from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
| from mdadm.h:36,
| from mdadm.c:28:
| /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:32:0:
note: this is the location of the previous definition
| #define bswap_32(x) __bswap_32 (x)
| ^
| In file included from mdadm.c:28:0:
| mdadm.h:148:0: error: "bswap_64" redefined [-Werror]
| #define bswap_64(x) (((x) & 0x00000000000000ffULL) << 56 | \
| ^
| In file included from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
| from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
| from mdadm.h:36,
| from mdadm.c:28:
| /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:36:0:
note: this is the location of the previous definition
| # define bswap_64(x) __bswap_64 (x)
| ^
| In file included from config.c:25:0:
| mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
| #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
| ^
| In file included from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/endian.h:59:0,
| from
/home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/sys/types.h:216,
| from mdadm.h:36,
| from config.c:25:
| /home/maxin/poky/build/tmp/sysroots/qemux86-64/usr/include/byteswap.h:29:0:
note: this is the location of the previous definition
| #define bswap_16(x) __bswap_16 (x)
| ^
......
> Jes
Best Regards,
Maxin
>>
>> diff --git a/mdadm.h b/mdadm.h
>> index dd02be7..230e60f 100755
>> --- a/mdadm.h
>> +++ b/mdadm.h
>> @@ -139,12 +139,20 @@ struct dlm_lksb {
>> * and there is no standard conversion function so... */
>> /* And dietlibc doesn't think byteswap is ok, so.. */
>> /* #include <byteswap.h> */
>> +
>> +#ifndef bswap_16
>> #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
>> ((x) & 0xff00U) >> 8)
>> +#endif
>> +
>> +#ifndef bswap_32
>> #define bswap_32(x) (((x) & 0x000000ffU) << 24 | \
>> ((x) & 0xff000000U) >> 24 | \
>> ((x) & 0x0000ff00U) << 8 | \
>> ((x) & 0x00ff0000U) >> 8)
>> +#endif
>> +
>> +#ifndef bswap_64
>> #define bswap_64(x) (((x) & 0x00000000000000ffULL) << 56 | \
>> ((x) & 0xff00000000000000ULL) >> 56 | \
>> ((x) & 0x000000000000ff00ULL) << 40 | \
>> @@ -153,6 +161,7 @@ struct dlm_lksb {
>> ((x) & 0x0000ff0000000000ULL) >> 24 | \
>> ((x) & 0x00000000ff000000ULL) << 8 | \
>> ((x) & 0x000000ff00000000ULL) >> 8)
>> +#endif
>>
>> #if !defined(__KLIBC__)
>> #if BYTE_ORDER == LITTLE_ENDIAN
^ permalink raw reply
* Re: [PATCH 2/3][mdadm] mdadm.h: bswap is already defined in uclibc
From: Jes Sorensen @ 2016-02-08 16:00 UTC (permalink / raw)
To: Maxin B. John; +Cc: linux-raid, Maxin B. John
In-Reply-To: <1454711298-32524-2-git-send-email-maxin.john@gmail.com>
"Maxin B. John" <maxin.john@gmail.com> writes:
> From: "Maxin B. John" <maxin.john@intel.com>
>
> Fixes this build error:
>
> | In file included from mdadm.c:28:0:
> | mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
> | #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
> | ^
>
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
> mdadm.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
Hi Maxin,
I am not opposed to this, but I would like to understand why you see
these duplicate defines. What defines it in your build environment?
Cheers,
Jes
>
> diff --git a/mdadm.h b/mdadm.h
> index dd02be7..230e60f 100755
> --- a/mdadm.h
> +++ b/mdadm.h
> @@ -139,12 +139,20 @@ struct dlm_lksb {
> * and there is no standard conversion function so... */
> /* And dietlibc doesn't think byteswap is ok, so.. */
> /* #include <byteswap.h> */
> +
> +#ifndef bswap_16
> #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
> ((x) & 0xff00U) >> 8)
> +#endif
> +
> +#ifndef bswap_32
> #define bswap_32(x) (((x) & 0x000000ffU) << 24 | \
> ((x) & 0xff000000U) >> 24 | \
> ((x) & 0x0000ff00U) << 8 | \
> ((x) & 0x00ff0000U) >> 8)
> +#endif
> +
> +#ifndef bswap_64
> #define bswap_64(x) (((x) & 0x00000000000000ffULL) << 56 | \
> ((x) & 0xff00000000000000ULL) >> 56 | \
> ((x) & 0x000000000000ff00ULL) << 40 | \
> @@ -153,6 +161,7 @@ struct dlm_lksb {
> ((x) & 0x0000ff0000000000ULL) >> 24 | \
> ((x) & 0x00000000ff000000ULL) << 8 | \
> ((x) & 0x000000ff00000000ULL) >> 8)
> +#endif
>
> #if !defined(__KLIBC__)
> #if BYTE_ORDER == LITTLE_ENDIAN
^ permalink raw reply
* Re: [PATCH 1/3][mdadm] util.c: include poll.h instead of sys/poll.h
From: Jes Sorensen @ 2016-02-08 15:59 UTC (permalink / raw)
To: Maxin B. John; +Cc: linux-raid, Maxin B. John
In-Reply-To: <1454711298-32524-1-git-send-email-maxin.john@gmail.com>
"Maxin B. John" <maxin.john@gmail.com> writes:
> From: "Maxin B. John" <maxin.john@intel.com>
>
> This fixes a compile warning when building with musl:
>
> In file included from util.c:27:0:
> |
> qemux86-64/usr/include/sys/poll.h:1:2:
> error: #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
> [-Werror=cpp]
> | #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
> | ^
>
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
> util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied!
Thanks,
Jes
>
> diff --git a/util.c b/util.c
> index 970d484..3e6d293 100644
> --- a/util.c
> +++ b/util.c
> @@ -24,7 +24,6 @@
>
> #include "mdadm.h"
> #include "md_p.h"
> -#include <sys/poll.h>
> #include <sys/socket.h>
> #include <sys/utsname.h>
> #include <sys/wait.h>
> @@ -32,6 +31,7 @@
> #include <sys/resource.h>
> #include <sys/vfs.h>
> #include <linux/magic.h>
> +#include <poll.h>
> #include <ctype.h>
> #include <dirent.h>
> #include <signal.h>
^ permalink raw reply
* Re: [PATCH] Makefile: make the CC definition conditional
From: Jes Sorensen @ 2016-02-08 15:55 UTC (permalink / raw)
To: Maxin B. John; +Cc: linux-raid, Maxin B. John
In-Reply-To: <1454925569-6840-1-git-send-email-maxin.john@gmail.com>
"Maxin B. John" <maxin.john@gmail.com> writes:
> From: "Maxin B. John" <maxin.john@intel.com>
>
> By hardcoding CC's definition in the Makefile, all the external gcc
> parameters set by tune settings are lost. This causes compile failure
> with x32 toolchain
>
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied!
Thanks,
Jes
> diff --git a/Makefile b/Makefile
> index fd79cfb..5fd7f16 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -41,7 +41,7 @@ KLIBC=/home/src/klibc/klibc-0.77
>
> KLIBC_GCC = gcc -nostdinc -iwithprefix include
> -I$(KLIBC)/klibc/include -I$(KLIBC)/linux/include
> -I$(KLIBC)/klibc/arch/i386/include -I$(KLIBC)/klibc/include/bits32
>
> -CC = $(CROSS_COMPILE)gcc
> +CC ?= $(CROSS_COMPILE)gcc
> CXFLAGS ?= -ggdb
> CWFLAGS = -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> ifdef WARN_UNUSED
^ permalink raw reply
* Re: [mdadm PATCH 1/1] Fix some type comparison problems
From: Jes Sorensen @ 2016-02-08 15:51 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid, deepa.kernel, maxin.john
In-Reply-To: <1454721521-7118-1-git-send-email-xni@redhat.com>
Xiao Ni <xni@redhat.com> writes:
> As 26714713cd2bad9e0bf7f4669f6cc4659ceaab6c said, 32 bit signed
> timestamps will overflow in the year 2038. It already changed the
> utime and ctime in struct mdu_array_info_s from int to unsigned
> int. So we need to change the values that compared with them to
> unsigned int too.
>
> Signed-off-by : Xiao Ni <xni@redhat.com>
> ---
> Monitor.c | 2 +-
> util.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Applied!
Thanks,
Jes
> diff --git a/Monitor.c b/Monitor.c
> index f19c2e5..6df80f9 100644
> --- a/Monitor.c
> +++ b/Monitor.c
> @@ -33,7 +33,7 @@
> struct state {
> char *devname;
> char devnm[32]; /* to sync with mdstat info */
> - long utime;
> + unsigned int utime;
> int err;
> char *spare_group;
> int active, working, failed, spare, raid;
> diff --git a/util.c b/util.c
> index 970d484..6e7d3fb 100644
> --- a/util.c
> +++ b/util.c
> @@ -1267,7 +1267,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
> */
> struct superswitch *ss;
> struct supertype *st;
> - time_t besttime = 0;
> + unsigned int besttime = 0;
> int bestsuper = -1;
> int i;
^ permalink raw reply
* Re: Best option for SSD caching on a md raid array?
From: Jens-U. Mozdzen @ 2016-02-08 15:45 UTC (permalink / raw)
To: David Brown; +Cc: Thomas Fjellstrom, linux-raid
In-Reply-To: <56B85390.9050505@hesbynett.no>
Hi *,
Zitat von David Brown <david.brown@hesbynett.no>:
> Hi,
>
> If the server is going to have reasonably long uptimes, then lots of ram
> could easily be a better choice than an SSD caching system.
> [...] But the key point of an SSD cache is to get fast
> access to common data with random access patterns, since a raid array
> will give you plenty of bandwidth for large serial accesses. And while
> an SSD is fast for random reads, having the data in the server's cache
> is even faster.
to me, the key point of SSD caching was fast (persistent) writes and
optimization of expensive partial writes for RAID. Using memory
caching helped, but keeping that much dirty data in RAM wasn't my cup
of tea (it's what I had before moving to bcache).
Thomas, I decided to go the bcache route and am running two SAN/NAS
servers for months, serving a mix of NFS (i.e. for home directories
and large software compilation scenarios across multiple servers),
Samba (for a few SMB-dependent machines), iSCSI and Fibre Channel
(both via SCST) to serve various virtual disks to about 40 VMs, and a
vanishing amount of other services.
I have not further explored the other options you name - but up to
now, I've been sufficiently happy with bcache to see no need to run
intensive compares.
Mateusz named pros and cons - for bcache, the lack of maintainer got
somewhat resolved by others jumping in and i.e. SUSE putting an
up-to-date (patched) bcache version in their kernels. What I feel
missing in Mateusz' list is bcache's current lack of a live resizing
feature: Even if you live-resize the back-end storage (i.e. RAID),
you'll currently have to re-init the bcache device (i.e. by rebooting
the node) for it to recognize the changed back-end size. Not good for
your uptime.
Regards,
Jens
^ permalink raw reply
* Re: Best option for SSD caching on a md raid array?
From: John Stoffel @ 2016-02-08 15:34 UTC (permalink / raw)
To: Thomas Fjellstrom; +Cc: linux-raid
In-Reply-To: <1670804.QnHtKWfib8@nell>
Thomas> I'm planning on setting up a dual raid5 array for hosting vm's
Thomas> off LVM, I would like to add an ssd cache to help with typical
Thomas> server system loads, and some mixed read/write loads for game
Thomas> servers.
Thomas> I'm wondering what the "best" route for me to go is. There's a
Thomas> few options that I know of, like flashcache, dm-cache, and
Thomas> bcache. The question is which of those is better suited to my
Thomas> use case?
I looked into both bcache and lvmcache and went with lvmcache because
it made more sense to me. But one restriction is that the cache LVs
must be in the same VGs as the volume to cache. So you might need to
partition your SSD(s) and put the partitions into seperate VGs so that
you can cache one or more LVs.
I'm using it at home to cache a RAID1 4tb VG, with a pair of mirrored
SSDs. I'm a big believer in mirroring, esp for critical stuff like
this.
Unfortunately, I don't have a good performance measurements of how
much help this actually gives me. It *feels* faster, but since I
don't have before/after measurements, I could just have wasted a bunch
of money.
So I'd recommend lvmcache overall, since it does seem to help, but
push for better performance metrics and measurement. Heh, maybe it's
time for me to start writing up lvmcachetop to help measure things.
John
^ permalink raw reply
* [PATCH] Makefile: make the CC definition conditional
From: Maxin B. John @ 2016-02-08 9:59 UTC (permalink / raw)
To: linux-raid; +Cc: Maxin B. John
From: "Maxin B. John" <maxin.john@intel.com>
By hardcoding CC's definition in the Makefile, all the external gcc
parameters set by tune settings are lost. This causes compile failure
with x32 toolchain
Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index fd79cfb..5fd7f16 100644
--- a/Makefile
+++ b/Makefile
@@ -41,7 +41,7 @@ KLIBC=/home/src/klibc/klibc-0.77
KLIBC_GCC = gcc -nostdinc -iwithprefix include -I$(KLIBC)/klibc/include -I$(KLIBC)/linux/include -I$(KLIBC)/klibc/arch/i386/include -I$(KLIBC)/klibc/include/bits32
-CC = $(CROSS_COMPILE)gcc
+CC ?= $(CROSS_COMPILE)gcc
CXFLAGS ?= -ggdb
CWFLAGS = -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
ifdef WARN_UNUSED
--
2.1.4
^ permalink raw reply related
* Re: Best option for SSD caching on a md raid array?
From: Mateusz Korniak @ 2016-02-08 9:38 UTC (permalink / raw)
To: Thomas Fjellstrom; +Cc: linux-raid
In-Reply-To: <1670804.QnHtKWfib8@nell>
On Sunday 07 February 2016 22:14:08 Thomas Fjellstrom wrote:
> I'm wondering what the "best" route for me to go is. There's a few options
> that I know of, like flashcache, dm-cache, and bcache. The question is which
> of those is better suited to my use case?
bcache cons:
- no maintainer, bugs living years
- partition have to be formatted as bcache
lvmcache cons:
- in case of failure of caching device, whole cache volume stops working (data
is not lost though).
- cumbersome way of removing cache from LV when caching device is not
accessible/failed.
lvmcache pros:
- One can turn on/off caching for active/mounted LV.
We moved from bcache to lvmcache (knowing it's limitations) using write-
through mode and for more-reads-than-writes DB access patterns [1].
[1]: Examble postgresql load (sdc is caching SSD, over sda/b RAID10).
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz
avgqu-sz await r_await w_await svctm %util
sda 0.00 33.93 0.07 179.13 0.00 3.38 38.59
6.23 34.75 23.50 34.76 2.63 47.07
sdb 0.00 35.97 0.03 177.17 0.00 3.38 39.04
9.57 53.99 337.00 53.94 2.97 52.66
sdc 8.03 2.63 631.07 201.13 6.04 3.35 23.10
0.19 0.23 0.19 0.35 0.15 12.34
Regards,
--
Mateusz Korniak
"(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś,
krótko mówiąc - podpora społeczeństwa."
Nikos Kazantzakis - "Grek Zorba"
--
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: Best option for SSD caching on a md raid array?
From: David Brown @ 2016-02-08 8:36 UTC (permalink / raw)
To: Thomas Fjellstrom, linux-raid
In-Reply-To: <1670804.QnHtKWfib8@nell>
Hi,
If the server is going to have reasonably long uptimes, then lots of ram
could easily be a better choice than an SSD caching system. I don't
know how you are planning your "dual raid5 array", nor what sort of VM's
you are dealing with. But the key point of an SSD cache is to get fast
access to common data with random access patterns, since a raid array
will give you plenty of bandwidth for large serial accesses. And while
an SSD is fast for random reads, having the data in the server's cache
is even faster.
On 08/02/16 06:14, Thomas Fjellstrom wrote:
> Hi,
>
> I'm planning on setting up a dual raid5 array for hosting vm's off LVM, I would
> like to add an ssd cache to help with typical server system loads, and some
> mixed read/write loads for game servers.
>
> I'm wondering what the "best" route for me to go is. There's a few options
> that I know of, like flashcache, dm-cache, and bcache. The question is which of
> those is better suited to my use case?
>
> Also wondering which ones people here use, and what they use it for.
>
> Thanks!
>
^ permalink raw reply
* Best option for SSD caching on a md raid array?
From: Thomas Fjellstrom @ 2016-02-08 5:14 UTC (permalink / raw)
To: linux-raid
Hi,
I'm planning on setting up a dual raid5 array for hosting vm's off LVM, I would
like to add an ssd cache to help with typical server system loads, and some
mixed read/write loads for game servers.
I'm wondering what the "best" route for me to go is. There's a few options
that I know of, like flashcache, dm-cache, and bcache. The question is which of
those is better suited to my use case?
Also wondering which ones people here use, and what they use it for.
Thanks!
--
Thomas Fjellstrom
thomas@fjellstrom.ca
^ permalink raw reply
* Re: mdadm raid5 dropped 2 disks
From: Phil Turmel @ 2016-02-06 14:03 UTC (permalink / raw)
To: Wols Lists, André Teichert, linux-raid
In-Reply-To: <56B5DD2B.50307@youngman.org.uk>
Good morning André, Wol,
On 02/06/2016 06:46 AM, Wols Lists wrote:
> On 06/02/16 10:54, André Teichert wrote:
>> glad it worked. Will save lsdrv and hope never to use it. Create new
>> backupplan!
>
> Please DO use lsdrv. EVERY time you create or change the config of an
> array, run it and save the info somewhere safe.
Yes, lsdrv is intended to document a running system for later use when
not running. Especially serial numbers, device names, UUIDs, and layer
relationships. It is still helpful later, but naturally some info can
be missed.
> Neil has just stepped down as maintainer and Phil is now "one of the
> team",
That's a bit of a stretch. I'm not maintaining any code and I'm
volunteering on the list as I have in the past.
> he wrote that utility specifically to help in recovering crashed
> arrays. If anything goes wrong and you've got that data to hand, it'll
> make their lives much easier to help you.
Yes, array configuration documentation is critical to recovery.
Phil
--
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: mdadm raid5 dropped 2 disks
From: Wols Lists @ 2016-02-06 11:46 UTC (permalink / raw)
To: André Teichert, linux-raid
In-Reply-To: <56B5D103.8070908@gmx.de>
On 06/02/16 10:54, André Teichert wrote:
> glad it worked. Will save lsdrv and hope never to use it. Create new
> backupplan!
Please DO use lsdrv. EVERY time you create or change the config of an
array, run it and save the info somewhere safe.
Neil has just stepped down as maintainer and Phil is now "one of the
team", he wrote that utility specifically to help in recovering crashed
arrays. If anything goes wrong and you've got that data to hand, it'll
make their lives much easier to help you.
Cheers,
Wol
--
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: mdadm raid5 dropped 2 disks
From: André Teichert @ 2016-02-06 10:54 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <56B479DD.7070600@gmx.de>
Hi Wol,
the raid is save now. I didnt work on the disks itself only with images.
dd if=/dev/sd[abc]1 of=/mnt/image[123].dd bs=1
losetup /dev/loop1 /mnt/image1.dd
losetup /dev/loop2 /mnt/image2.dd
mdadm --create /dev/md0 --raid-devices=3 --level=5 --assume-clean
--size=976631296 --raid-devices=3 missing /dev/loop2 /dev/loop1
fsck without any errors. Data is back!
What I maybe did wrong in the first run?
1) I wrote the first backup of the disks to partitions, that were a
little bigger than the original one. These were fresh drives with no
data writen so far.
2) I did the create with the right order (missing loo2 loop1) from
mdadm -E "Device Role"
glad it worked. Will save lsdrv and hope never to use it. Create new
backupplan!
cheers
^ permalink raw reply
* Re: mdadm raid5 dropped 2 disks
From: Wols Lists @ 2016-02-06 9:45 UTC (permalink / raw)
To: André Teichert, linux-raid
In-Reply-To: <56B479DD.7070600@gmx.de>
On 05/02/16 10:30, André Teichert wrote:
> Should I try --create --assmume-clean sda1 sda2 missing?
> I try to stay calm and pray for help.
> thx a lot
Find and download lsdrv by Phil Turmel. You'll need Python 2.7 to run it
iirc.
DO NOT EVEN CONSIDER running "mdadm --create" until you've got all the
data you can out of the drive headers (lsdrv is intended to get this data).
Post the data from lsdrv to the list, and then someone else will chime
in and help you further.
(If you get --create wrong, you've probably just permanently lost the
contents of your array ...)
Cheers,
Wol
--
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 3/3][mdadm] Monitor.c: fix compiler error with x32 toolchain
From: Maxin B. John @ 2016-02-06 5:27 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid
In-Reply-To: <1290371608.15164091.1454721475169.JavaMail.zimbra@redhat.com>
Hi Xiao,
On Sat, Feb 6, 2016 at 3:17 AM, Xiao Ni <xni@redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Maxin B. John" <maxin.john@gmail.com>
>> To: linux-raid@vger.kernel.org
>> Cc: "Maxin B. John" <maxin.john@intel.com>
>> Sent: Saturday, February 6, 2016 6:28:18 AM
>> Subject: [PATCH 3/3][mdadm] Monitor.c: fix compiler error with x32 toolchain
>>
>> From: "Maxin B. John" <maxin.john@intel.com>
>>
>> With x32 toolchain, this code caused the below listed error:
>>
>> | Monitor.c: In function 'check_array':
>> | Monitor.c:545:16: error: comparison between signed and unsigned
>> integer expressions [-Werror=sign-compare]
>> | if (st->utime == array.utime &&
>>
>> Signed-off-by: Maxin B. John <maxin.john@intel.com>
>> ---
>> Monitor.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Monitor.c b/Monitor.c
>> index f19c2e5..748d61b 100644
>> --- a/Monitor.c
>> +++ b/Monitor.c
>> @@ -542,7 +542,7 @@ static int check_array(struct state *st, struct
>> mdstat_ent *mdstat,
>> alert("NewArray", st->devname, NULL, ainfo);
>> }
>>
>> - if (st->utime == array.utime &&
>> + if ((unsigned long)st->utime == array.utime &&
>> st->failed == array.failed_disks &&
>> st->working == array.working_disks &&
>> st->spare == array.spare_disks &&
>
> Hi Maxin
>
> I sent the patch some days ago and I think it's not what Jes wanted. You can
> see the mails in the list. I'll send the patch again.
>
Ah, I missed it. Thanks for fixing it.
> Best Regards
> Xiao
Thanks and Regards,
Maxin
^ permalink raw reply
* [mdadm PATCH 1/1] Fix some type comparison problems
From: Xiao Ni @ 2016-02-06 1:18 UTC (permalink / raw)
To: linux-raid; +Cc: Jes.Sorensen, deepa.kernel, maxin.john
As 26714713cd2bad9e0bf7f4669f6cc4659ceaab6c said, 32 bit signed
timestamps will overflow in the year 2038. It already changed the
utime and ctime in struct mdu_array_info_s from int to unsigned
int. So we need to change the values that compared with them to
unsigned int too.
Signed-off-by : Xiao Ni <xni@redhat.com>
---
Monitor.c | 2 +-
util.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Monitor.c b/Monitor.c
index f19c2e5..6df80f9 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -33,7 +33,7 @@
struct state {
char *devname;
char devnm[32]; /* to sync with mdstat info */
- long utime;
+ unsigned int utime;
int err;
char *spare_group;
int active, working, failed, spare, raid;
diff --git a/util.c b/util.c
index 970d484..6e7d3fb 100644
--- a/util.c
+++ b/util.c
@@ -1267,7 +1267,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
*/
struct superswitch *ss;
struct supertype *st;
- time_t besttime = 0;
+ unsigned int besttime = 0;
int bestsuper = -1;
int i;
--
2.4.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox