All of lore.kernel.org
 help / color / mirror / Atom feed
From: yebin <yebin10@huawei.com>
To: Zhengyuan Liu <liuzhengyuang521@gmail.com>
Cc: "Jan Kara" <jack@suse.cz>,
	viro@zeniv.linux.org.uk,
	"Andrew Morton" <akpm@linux-foundation.org>,
	tytso@mit.edu, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-ext4@vger.kernel.org, 刘云 <liuyun01@kylinos.cn>,
	"Zhengyuan Liu" <liuzhengyuan@kylinos.cn>
Subject: Re: Problem with direct IO
Date: Fri, 29 Oct 2021 16:16:20 +0800	[thread overview]
Message-ID: <617BADD4.7030009@huawei.com> (raw)
In-Reply-To: <CAOOPZo4p8yWGc+ZsTE-cq=cjOxN_=_deb=ttTtmEup8MM6Kjrg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 19001 bytes --]



On 2021/10/21 20:20, Zhengyuan Liu wrote:
> On Thu, Oct 21, 2021 at 4:55 PM yebin <yebin10@huawei.com> wrote:
>>
>>
>> On 2021/10/21 16:03, Jan Kara wrote:
>>
>> On Thu 21-10-21 10:21:55, Zhengyuan Liu wrote:
>>
>> On Thu, Oct 21, 2021 at 1:37 AM Jan Kara <jack@suse.cz> wrote:
>>
>> On Wed 13-10-21 09:46:46, Zhengyuan Liu wrote:
>>
>> we are encounting following Mysql crash problem while importing tables :
>>
>>      2021-09-26T11:22:17.825250Z 0 [ERROR] [MY-013622] [InnoDB] [FATAL]
>>      fsync() returned EIO, aborting.
>>      2021-09-26T11:22:17.825315Z 0 [ERROR] [MY-013183] [InnoDB]
>>      Assertion failure: ut0ut.cc:555 thread 281472996733168
>>
>> At the same time , we found dmesg had following message:
>>
>>      [ 4328.838972] Page cache invalidation failure on direct I/O.
>>      Possible data corruption due to collision with buffered I/O!
>>      [ 4328.850234] File: /data/mysql/data/sysbench/sbtest53.ibd PID:
>>      625 Comm: kworker/42:1
>>
>> Firstly, we doubled Mysql has operating the file with direct IO and
>> buffered IO interlaced, but after some checking we found it did only
>> do direct IO using aio. The problem is exactly from direct-io
>> interface (__generic_file_write_iter) itself.
>>
>> ssize_t __generic_file_write_iter()
>> {
>> ...
>>          if (iocb->ki_flags & IOCB_DIRECT) {
>>                  loff_t pos, endbyte;
>>
>>                  written = generic_file_direct_write(iocb, from);
>>                  /*
>>                   * If the write stopped short of completing, fall back to
>>                   * buffered writes.  Some filesystems do this for writes to
>>                   * holes, for example.  For DAX files, a buffered write will
>>                   * not succeed (even if it did, DAX does not handle dirty
>>                   * page-cache pages correctly).
>>                   */
>>                  if (written < 0 || !iov_iter_count(from) || IS_DAX(inode))
>>                          goto out;
>>
>>                  status = generic_perform_write(file, from, pos = iocb->ki_pos);
>> ...
>> }
>>
>>  From above code snippet we can see that direct io could fall back to
>> buffered IO under certain conditions, so even Mysql only did direct IO
>> it could interleave with buffered IO when fall back occurred. I have
>> no idea why FS(ext3) failed the direct IO currently, but it is strange
>> __generic_file_write_iter make direct IO fall back to buffered IO, it
>> seems  breaking the semantics of direct IO.
>>
>> The reproduced  environment is:
>> Platform:  Kunpeng 920 (arm64)
>> Kernel: V5.15-rc
>> PAGESIZE: 64K
>> Mysql:  V8.0
>> Innodb_page_size: default(16K)
>>
>> Thanks for report. I agree this should not happen. How hard is this to
>> reproduce? Any idea whether the fallback to buffered IO happens because
>> iomap_dio_rw() returns -ENOTBLK or because it returns short write?
>>
>> It is easy to reproduce in my test environment, as I said in the previous
>> email replied to Andrew this problem is related to kernel page size.
>>
>> Ok, can you share a reproducer?
>>
>> Can you post output of "dumpe2fs -h <device>" for the filesystem where the
>> problem happens? Thanks!
>>
>> Sure, the output is:
>>
>> # dumpe2fs -h /dev/sda3
>> dumpe2fs 1.45.3 (14-Jul-2019)
>> Filesystem volume name:   <none>
>> Last mounted on:          /data
>> Filesystem UUID:          09a51146-b325-48bb-be63-c9df539a90a1
>> Filesystem magic number:  0xEF53
>> Filesystem revision #:    1 (dynamic)
>> Filesystem features:      has_journal ext_attr resize_inode dir_index
>> filetype needs_recovery sparse_super large_file
>>
>> Thanks for the data. OK, a filesystem without extents. Does your test by
>> any chance try to do direct IO to a hole in a file? Because that is not
>> (and never was) supported without extents. Also the fact that you don't see
>> the problem with ext4 (which means extents support) would be pointing in
>> that direction.
>>
>> Honza
>>
>>
>> I try to reprodeuce this issue as follows, maybe this is just one scenario :
>> step1:  Modify  kernel code, add delay in dio_complete and dio_bio_end_aio
>> step2:  mkfs.ext4 /dev/sda
>> step3:  mount /dev/sda  /home/test
>> step4:  fio -filename=/home/test/test  -direct=0 -buffered=1 -iodepth 1 -thread -rw=write -rwmixread=70 -ioengine=libaio -bs=4k -size=16k -numjobs=1 -name=test_r_w
>> step5:  fio -filename=/home/test/test  -direct=1 -buffered=0 -iodepth 1 -thread -rw=write -rwmixread=70 -ioengine=libaio -bs=4k -size=4k -numjobs=1 -name=test_r_w &
>> step6:  fio -filename=/home/test/test  -direct=0 -buffered=1 -iodepth 1 -thread -rw=write -rwmixread=70 -ioengine=libaio -bs=4k -size=16k -numjobs=1 -name=test_r_w
> Hi, yebin
>
> Thanks for your test case,  but it is not the same problem. The scenario you
> described here is some thing the kernel design for, since you are intending to
> interleave buffered IO and direct IO, please look at this two patch:
>
> 332391a (“fs: Fix page cache inconsistency when mixing buffered and AIO DIO”)
> 5a9d929 (“iomap: report collisions between directio and buffered
> writes to userspace”)
  Maybe we can reproduce your issue as follows:
1. mkfs.ext4  -b 1024 /dev/sdb        (PAGE_SIZE=4K)
2. mount /dev/sdb /home/test
3. fio -filename=/home/test/test  -direct=0 -buffered=1 -iodepth 1 
-thread -rw=write -rwmixread=70 -ioengine=libaio -bs=1k -size=4k 
-numjobs=1 -name=test_r_w
4. fio -filename=/home/test/test  -direct=1 -buffered=0 -iodepth 1 
-thread -rw=write -rwmixread=70 -ioengine=libaio -bs=1k -size=1k 
-numjobs=1 -name=test_r_w &
5. fio -filename=/home/test/test  -direct=0 -buffered=1 -iodepth 1 
-thread -rw=write -rwmixread=70 -ioengine=libaio -bs=1k -size=5k 
-offset=1024 -numjobs=1 -name=test_r_w

As file system block size is 1K,  there are 4  buffer_head per page.  So 
direct IO and buffer IO maybe  operate on the same page,
although it does not operate on the same logical block.

I add some debug information  into  kernel  as follows:
diff --git a/fs/direct-io.c b/fs/direct-io.c
index ec7c7d1c0329..aebc3e76f8ca 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -38,6 +38,8 @@
  #include <linux/atomic.h>
  #include <linux/prefetch.h>

+#include <linux/delay.h>
+
  /*
   * How many user pages to map in one call to get_user_pages(). This 
determines
   * the size of a structure in the slab cache
@@ -224,20 +226,20 @@ static inline struct page *dio_get_page(struct dio 
*dio,
   */
  void dio_warn_stale_pagecache(struct file *filp)
  {
-       static DEFINE_RATELIMIT_STATE(_rs, 86400 * HZ, 
DEFAULT_RATELIMIT_BURST);
+//     static DEFINE_RATELIMIT_STATE(_rs, 86400 * HZ, 
DEFAULT_RATELIMIT_BURST);
         char pathname[128];
         struct inode *inode = file_inode(filp);
         char *path;

         errseq_set(&inode->i_mapping->wb_err, -EIO);
-       if (__ratelimit(&_rs)) {
+//     if (__ratelimit(&_rs)) {
                 path = file_path(filp, pathname, sizeof(pathname));
                 if (IS_ERR(path))
                         path = "(unknown)";
                 pr_crit("Page cache invalidation failure on direct 
I/O.  Possible data corruption due to collision with buffered I/O!\n");
                 pr_crit("File: %s PID: %d Comm: %.20s\n", path, 
current->pid,
                         current->comm);
-       }
+//     }
  }

  /**
@@ -305,15 +307,20 @@ static ssize_t dio_complete(struct dio *dio, 
ssize_t ret, unsigned int flags)
          * end_io() when necessary, otherwise a racing buffer read 
would cache
          * zeros from unwritten extents.
          */
+       printk("%s: before invalidate page \n", __func__);
+       mdelay(10 * 1000);
         if (flags & DIO_COMPLETE_INVALIDATE &&
             ret > 0 && dio->op == REQ_OP_WRITE &&
             dio->inode->i_mapping->nrpages) {
+               printk("%s: start to call invalidate_inode_pages2_range 
nrpags=%lu\n",
+                       __func__, dio->inode->i_mapping->nrpages);
                 err = invalidate_inode_pages2_range(dio->inode->i_mapping,
                                         offset >> PAGE_SHIFT,
                                         (offset + ret - 1) >> PAGE_SHIFT);
                 if (err)
dio_warn_stale_pagecache(dio->iocb->ki_filp);
         }
+       printk("%s: end invalidate page \n", __func__);

         inode_dio_end(dio->inode);

diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 21b0fc0d6ffe..35d1a330437b 100644
--- a/fs/ext4/file.c
+       printk("%s: end invalidate page \n", __func__);

         inode_dio_end(dio->inode);

diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 21b0fc0d6ffe..35d1a330437b 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -241,6 +241,7 @@ ext4_file_write_iter(struct kiocb *iocb, struct 
iov_iter *from)
                 inode_lock(inode);
         }

+       printk("%s: start lock inode offset=%llu \n", __func__, 
iocb->ki_pos);
         ret = ext4_write_checks(iocb, from);
         if (ret <= 0)
                 goto out;
@@ -278,7 +279,7 @@ ext4_file_write_iter(struct kiocb *iocb, struct 
iov_iter *from)
         if (ret == -EIOCBQUEUED && unaligned_aio)
                 ext4_unwritten_wait(inode);
         inode_unlock(inode);
-
+       printk("%s: unlock inode\n", __func__);
         if (ret > 0)
                 ret = generic_write_sync(iocb, ret);

diff --git a/mm/truncate.c b/mm/truncate.c
index 43c73db17a0a..9b1ffedf831b 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -677,6 +677,7 @@ int invalidate_inode_pages2_range(struct 
address_space *mapping,
         int ret2 = 0;
         int did_range_unmap = 0;

+       printk("%s: start=%lu end=%lu pages=%lu\n", __func__, start, 
end, mapping->nrpages);
         if (mapping->nrpages == 0 && mapping->nrexceptional == 0)
                 goto out;

@@ -690,6 +691,7 @@ int invalidate_inode_pages2_range(struct 
address_space *mapping,

                         /* We rely upon deletion not changing 
page->index */
                         index = indices[i];
+                       printk("%s: index=%lu\n", __func__, index);
                         if (index > end)
                                 break;

>> Kernel modification base on v4.19:
>> diff --git a/fs/direct-io.c b/fs/direct-io.c
>> +#include <linux/delay.h>
>>
>> /**
>> @@ -305,6 +307,8 @@ static ssize_t dio_complete(struct dio *dio, ssize_t ret, unsigned int flags)
>>           * end_io() when necessary, otherwise a racing buffer read would cache
>>           * zeros from unwritten extents.
>>           */
>> +       printk("%s: before invalidate page \n", __func__);
>> +       mdelay(10 * 1000);
>>          if (flags & DIO_COMPLETE_INVALIDATE &&
>>              ret > 0 && dio->op == REQ_OP_WRITE &&
>>              dio->inode->i_mapping->nrpages) {
>> @@ -314,6 +318,7 @@ static ssize_t dio_complete(struct dio *dio, ssize_t ret, unsigned int flags)
>>                  if (err)
>>                          dio_warn_stale_pagecache(dio->iocb->ki_filp);
>>          }
>> +       printk("%s: end invalidate page \n", __func__);
>>
>>          inode_dio_end(dio->inode);
>>
>> @@ -371,10 +378,17 @@ static void dio_bio_end_aio(struct bio *bio)
>>                   * went in between AIO submission and completion into the
>>                   * same region.
>>                   */
>> +               printk("%s:start to  sleep 5s.... \n", __func__);
>> +               mdelay(10 * 1000);
>> +               printk("%s: endto  sleep, defer_completion=%d op=%d nrpages=%d\n",
>> +                       __func__,dio->defer_completion, dio->op, dio->inode->i_mapping->nrpages);
>> +
>>                  if (dio->result)
>>                          defer_completion = dio->defer_completion ||
>>                                             (dio->op == REQ_OP_WRITE &&
>>                                              dio->inode->i_mapping->nrpages);
>> +               printk("%s: dio=%px defer_completion=%d\n",
>> +                       __func__, dio, defer_completion);
>>                  if (defer_completion) {
>>                          INIT_WORK(&dio->complete_work, dio_aio_complete_work);
>>                          queue_work(dio->inode->i_sb->s_dio_done_wq,
>>
>>
>> Reproduce result :
>> s=1 -name=test_r_w=write -rwmixread=70 -ioengine=libaio -bs=4k -size=16k -numjob
>> test_r_w: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
>> fio-3.7
>> Starting 1 thread
>> test_r_w: (groupid=0, jobs=1): err= 0: pid=2083: Sun Sep 26 03:18:06 2021
>>    write: IOPS=444, BW=1778KiB/s (1820kB/s)(16.0KiB/9msec)
>>      slat (usec): min=1294, max=3789, avg=2007.88, stdev=1191.07
>>      clat (nsec): min=2304, max=28645, avg=9918.75, stdev=12574.80
>>       lat (usec): min=1298, max=3824, avg=2020.36, stdev=1206.00
>>      clat percentiles (nsec):
>>       |  1.00th=[ 2320],  5.00th=[ 2320], 10.00th=[ 2320], 20.00th=[ 2320],
>>       | 30.00th=[ 2960], 40.00th=[ 2960], 50.00th=[ 2960], 60.00th=[ 5792],
>>       | 70.00th=[ 5792], 80.00th=[28544], 90.00th=[28544], 95.00th=[28544],
>>       | 99.00th=[28544], 99.50th=[28544], 99.90th=[28544], 99.95th=[28544],
>>       | 99.99th=[28544]
>>    lat (usec)   : 4=50.00%, 10=25.00%, 50=25.00%
>>    cpu          : usr=0.00%, sys=87.50%, ctx=0, majf=0, minf=1
>>    IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
>>       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
>>       complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
>>       issued rwts: total=0,4,0,0 short=0,0,0,0 dropped=0,0,0,0
>>       latency   : target=0, window=0, percentile=100.00%, depth=1
>>
>> Run status group 0 (all jobs):
>>    WRITE: bw=1778KiB/s (1820kB/s), 1778KiB/s-1778KiB/s (1820kB/s-1820kB/s), io=16.0KiB (16.4kB), run=9-9msec
>>
>> Disk stats (read/write):
>>    sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
>> =1 -name=test_r_w &write -rwmixread=70 -ioengine=libaio -bs=4k -size=4k -numjobs
>> [1] 2087
>> [root@localhost home]# test_r_w: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
>> fio-3.7
>> Starting 1 thread
>>
>> [root@localhost home]# [ 1475.286928] ext4_file_write_iter: start lock inode
>> [ 1475.288807] ext4_file_write_iter: unlock inode
>> [ 1475.290402] dio_bio_end_aio:start to  sleep 5s....
>>
>> s=1 -name=test_r_w=write -rwmixread=70 -ioengine=libaio -bs=4k -size=16k -numjob
>> test_r_w: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
>> fio-3.7
>> Starting 1 thread
>> Jobs: 1 (f=0): [f(1)][-.-%][r=0KiB/s,w=0KiB/s][r=0,w=0 IOPS][eta 00m:00s]
>> Jobs: 1 (f=0): [f(1)][-.-%][r=0KiB/s,w=0KiB/s][r=0,w=0 IOPS][eta 00m:00s]
>> [ 1485.292939] dio_bio_end_aio: endto  sleep, defer_completion=0 op=1 nrpages=4
>> [ 1485.293888] dio_bio_end_aio: dio=ffff88839aff5200 defer_completion=1
>> [ 1485.294821] dio_aio_complete_work: dio=ffff88839aff5200...
>> Jobs: 1 (f=1): [W(1)][-.-%][r=0KiB/s,w=0KiB/s][r[ 1485.296539] dio_complete: before invalidate page
>> [ 1495.298472] Page cache invalidation failure on direct I/O.  Possible data corruption due to collision with buffered I/O!     -->detect  buffer io and direct io conflict.
>> [ 1495.302746] File: /home/test/test PID: 493 Comm: kworker/3:2
>> [ 1495.303508] CPU: 3 PID: 493 Comm: kworker/3:2 Not tainted 4.19.90-dirty #96
>> [ 1495.304386] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
>> Jobs: 1 (f=1): [[ 1495.306050] Workqueue: dio/sda dio_aio_complete_work
>> W(1)][-.-%][r=0K
>> [ 1495.316879] dio_complete: end invalidate page
>> test_r_w: (groupid=0, jobs=1): err= 0: pid=2092: Sun Sep 26 03:18:37 2021
>>    write: IOPS=266, BW=1067KiB/s (1092kB/s)(16.0KiB/15msec)
>>      slat (usec): min=2001, max=3101, avg=2691.97, stdev=480.07
>>      clat (nsec): min=2058, max=12337, avg=5999.50, stdev=4456.54
>>       lat (usec): min=2004, max=3116, avg=2700.11, stdev=484.22
>>      clat percentiles (nsec):
>>       |  1.00th=[ 2064],  5.00th=[ 2064], 10.00th=[ 2064], 20.00th=[ 2064],
>>       | 30.00th=[ 4080], 40.00th=[ 4080], 50.00th=[ 4080], 60.00th=[ 5536],
>>       | 70.00th=[ 5536], 80.00th=[12352], 90.00th=[12352], 95.00th=[12352],
>>       | 99.00th=[12352], 99.50th=[12352], 99.90th=[12352], 99.95th=[12352],
>>       | 99.99th=[12352]
>>    lat (usec)   : 4=25.00%, 10=50.00%, 20=25.00%
>>    cpu          : usr=0.00%, sys=100.00%, ctx=1, majf=0, minf=1
>>    IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
>>       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
>>       complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
>>       issued rwts: total=0,4,0,0 short=0,0,0,0 dropped=0,0,0,0
>>       latency   : target=0, window=0, percentile=100.00%, depth=1
>>
>> Run status group 0 (all jobs):
>>    WRITE: bw=1067KiB/s (1092kB/s), 1067KiB/s-1067KiB/s (1092kB/s-1092kB/s), io=16.0KiB (16.4kB), run=15-15msec
>>
>> Disk stats (read/write):
>>    sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
>>
>> test_r_w: (groupid=0, jobs=1): err= 0: pid=2089: Sun Sep 26 03:18:37 2021
>>    write: IOPS=0, BW=204B/s (204B/s)(4096B/20033msec)
>>      slat (nsec): min=3358.7k, max=3358.7k, avg=3358748.00, stdev= 0.00
>>      clat (nsec): min=20027M, max=20027M, avg=20027265355.00, stdev= 0.00
>>       lat (nsec): min=20031M, max=20031M, avg=20030627283.00, stdev= 0.00
>>      clat percentiles (msec):
>>       |  1.00th=[17113],  5.00th=[17113], 10.00th=[17113], 20.00th=[17113],
>>       | 30.00th=[17113], 40.00th=[17113], 50.00th=[17113], 60.00th=[17113],
>>       | 70.00th=[17113], 80.00th=[17113], 90.00th=[17113], 95.00th=[17113],
>>       | 99.00th=[17113], 99.50th=[17113], 99.90th=[17113], 99.95th=[17113],
>>       | 99.99th=[17113]
>>    cpu          : usr=0.00%, sys=0.02%, ctx=2, majf=0, minf=1
>>    IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
>>       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
>>       complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
>>       issued rwts: total=0,1,0,0 short=0,0,0,0 dropped=0,0,0,0
>>       latency   : target=0, window=0, percentile=100.00%, depth=1
>>
>> Run status group 0 (all jobs):
>>    WRITE: bw=204B/s (204B/s), 204B/s-204B/s (204B/s-204B/s), io=4096B (4096B), run=20033-20033msec
>>
>> Disk stats (read/write):
>>    sda: ios=0/5, merge=0/1, ticks=0/10018, in_queue=10015, util=36.98%
>>
>>
>>
> .
>


[-- Attachment #2: Type: text/html, Size: 23412 bytes --]

  reply	other threads:[~2021-10-29  8:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13  1:46 Problem with direct IO Zhengyuan Liu
2021-10-18  1:09 ` Zhengyuan Liu
2021-10-18 18:43   ` Andrew Morton
2021-10-19  3:39     ` Zhengyuan Liu
2021-10-20 17:37 ` Jan Kara
2021-10-21  2:21   ` Zhengyuan Liu
2021-10-21  8:03     ` Jan Kara
2021-10-21  8:55       ` yebin
2021-10-21 12:20         ` Zhengyuan Liu
2021-10-29  8:16           ` yebin [this message]
2021-10-21 12:11       ` Zhengyuan Liu
2021-10-22  9:31         ` Jan Kara
2021-10-23  2:06           ` Zhengyuan Liu
2021-10-25 15:57             ` Jan Kara
2021-10-28 15:02               ` Zhengyuan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=617BADD4.7030009@huawei.com \
    --to=yebin10@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuyun01@kylinos.cn \
    --cc=liuzhengyuan@kylinos.cn \
    --cc=liuzhengyuang521@gmail.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.