On 2021/11/19 0:57, Benjamin Marzinski wrote:
> On Tue, Nov 16, 2021 at 10:01:15PM +0800, lixiaokeng wrote:
>> The update_map will frequently be called and there will be
>> unnecessary checks of reseravtion. We add prflag to path
>> to avoid this.
>>
>> The pp->state changes from others to up or
*** BLURB HERE ***
lixiaokeng (3):
Fix potential null pointer dereference
remove unnecessary memset
remove unnecessary free
libmultipath/discovery.c | 8 +---
libmultipath/foreign/nvme.c | 4 +++-
libmultipath/log.c | 1 -
libmultip
udev_device_* may return NULL, check it.
Signed-off-by: Lixiaokeng
---
libmultipath/discovery.c| 8 +---
libmultipath/foreign/nvme.c | 4 +++-
libmultipath/util.c | 10 +-
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/libmultipath/discovery.c b/libmult
MALLOC will set memory zero. memset is unnecessary.
Remove it.
Signed-off-by: Lixiaokeng
---
libmultipath/log.c | 1 -
multipathd/waiter.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/libmultipath/log.c b/libmultipath/log.c
index 10fa32cd..f41efb5b 100644
--- a/libmultipath/log.c
+++ b/
arg will be free by cleanup_charp. FREE(args)
is unnecessary before return. Remove it.
Signed-off-by: Lixiaokeng
---
libmultipath/prioritizers/weightedpath.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libmultipath/prioritizers/weightedpath.c
b/libmultipath/prioritizer
On 11/19/21 02:47, Kanchan Joshi wrote:
Given the multitude of things accumulated on this topic, Martin
suggested to have a table/matrix.
Some of those should go in the initial patchset, and the remaining are
to be staged for subsequent work.
Here is the attempt to split the stuff into two bucket
On Thu, Nov 18, 2021 at 10:56 PM Christoph Hellwig wrote:
>
> On Wed, Nov 17, 2021 at 09:44:25AM -0800, Dan Williams wrote:
> > On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
> > >
> > > dax_attribute_group is only used by the pmem driver, and can avoid the
> > > completely pointless lo
Hi!
A dm-era device created over a RAID5 array loses discard support.
Test script is attached.
If you run it on SSD you'll see something like:
loop0 4096
loop1 4096
loop2 4096
loop3 4096
md55 1048576
loop_test_era 0
I.e. mdadm device supports discard, but dm-era device started over it doesn't.
Even worse, dm-linear has the same problem.
dm-linear over mdadm RAID5 doesn't support discard while mdadm device itself
supports it.
> Hi!
>
> A dm-era device created over a RAID5 array loses discard support.
>
> Test script is attached.
>
> If you run it on SSD you'll see something like:
>
Hi
Just to note, the problem is solved by setting
raid456.devices_handle_discard_safely=Y in kernel command line.
It seems that dm-table.c checks for blk_queue_discard() of underlying devices
and RAID5 device has the QUEUE_FLAG_DISCARD unset and at the same time
discard_granularity != 0. So di
10 matches
Mail list logo
