Re: PROBLEM: Recent raid10 block discard patchset causes filesystem corruption on fstrim

2021-02-02 Thread Xiao Ni
On 02/02/2021 11:42 AM, Matthew Ruffell wrote: Hi Xiao, On 24/12/20 11:18 pm, Xiao Ni wrote:> The root cause is found. Now we use a similar way with raid0 to handle discard request for raid10. Because the discard region is very big, we can calculate the start/end address for each d

Re: PROBLEM: Recent raid10 block discard patchset causes filesystem corruption on fstrim

2020-12-24 Thread Xiao Ni
is in the original patch? Merry Christmas Xiao commit 0d74ac66ed0ec5af70296545e26044723a14657c Author: Xiao Ni Date: Thu Dec 24 17:58:43 2020 +0800 fix diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index 3153183b7772..92182cf40d22 100644 --- a/drivers/md/raid10.c +++ b/drivers/m

Re: PROBLEM: Recent raid10 block discard patchset causes filesystem corruption on fstrim

2020-12-09 Thread Xiao Ni
On 12/09/2020 12:17 PM, Song Liu wrote: Hi Matthew, On Dec 8, 2020, at 7:46 PM, Matthew Ruffell wrote: Hello, I recently backported the following patches into the Ubuntu stable kernels: md: add md_submit_discard_bio() for submitting discard bio md/raid10: extend r10bio devs to raid disk

Re: [PATCH v2 0/3] md superblock write alignment on 512e devices

2020-11-04 Thread Xiao Ni
On 11/04/2020 04:12 AM, Chris Unkel wrote: Hi Xiao, Thanks for the excellent feedback. Since bitmap_offset appears to be a free-form field, it wasn't apparent to me that the bitmap never starts within 4K of the bitmap. I don't think it's worth worrying about a logical block size that's more

Re: [PATCH 0/3] mdraid sb and bitmap write alignment on 512e drives

2020-11-03 Thread Xiao Ni
On 11/03/2020 02:59 AM, Chris Unkel wrote: Hi Xiao, That particular array is super1.2. The block trace was captured on the disk underlying the partition device on which the md array member resides, not on the partition device itself. The partition starts 2048 sectors into the disk (1MB). S

Re: [PATCH 2/3] md: align superblock writes to physical blocks

2020-11-02 Thread Xiao Ni
On 10/30/2020 04:13 AM, Christopher Unkel wrote: Writes of the md superblock are aligned to the logical blocks of the containing device, but no attempt is made to align them to physical block boundaries. This means that on a "512e" device (4k physical, 512 logical) every superblock update hit

Re: [PATCH v2 0/3] md superblock write alignment on 512e devices

2020-11-01 Thread Xiao Ni
On 10/30/2020 04:13 AM, Christopher Unkel wrote: Hello, Thanks for the feedback on the previous patch series. A updated patch series with the same function as the first patch (https://lkml.org/lkml/2020/10/22/1058 "md: align superblock writes to physical blocks") follows. As suggested, it i

Re: [PATCH 0/3] mdraid sb and bitmap write alignment on 512e drives

2020-11-01 Thread Xiao Ni
On 10/23/2020 11:31 AM, Christopher Unkel wrote: Hello all, While investigating some performance issues on mdraid 10 volumes formed with "512e" disks (4k native/physical sector size but with 512 byte sector emulation), I've found two cases where mdraid will needlessly issue writes that start

Re: Shaohua Li

2019-01-03 Thread Xiao Ni
On 01/03/2019 10:38 AM, Guoqing Jiang wrote: On 1/3/19 1:13 AM, Jens Axboe wrote: Hi, I've got some very sad news to share with you - over Christmas, Shaohua Li passed away after battling cancer for most of last year. It is really a sad news and a big lost for the community consider Sha

Re: [PATCH] md: fix memleak for mempool

2018-10-19 Thread Xiao Ni
_stop, move the > mempool_destroy to __md_stop fixes the problem for me. > > The bug was introduced in 5a409b4f56d5, the fixes should go to > 4.18+ > > Cc: Xiao Ni > Fixes: 5a409b4f56d5 ("MD: fix lock contention for flush bios") > Signed-off-by: Jack Wang > --

Re: [LKP] [lkp-robot] [MD] 5a409b4f56: aim7.jobs-per-min -27.5% regression

2018-07-16 Thread Xiao Ni
Hi Aaron I have no update for this yet. I'll have a look this week and give response later. Regards Xiao - Original Message - > From: "Aaron Lu" > To: "Xiao Ni" > Cc: "kernel test robot" , "Stephen Rothwell" > , l...@01.org