All of lore.kernel.org
 help / color / mirror / Atom feed
From: majianpeng <majianpeng@gmail.com>
To: "Yan, Zheng" <ukernel@gmail.com>
Cc: sage <sage@inktank.com>, ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: Re: question about striped_read
Date: Wed, 31 Jul 2013 13:46:52 +0800	[thread overview]
Message-ID: <2013073113222469570311@gmail.com> (raw)
In-Reply-To: CAAM7YAnGaXcQm1LcaCUGL71FGRV5zfNx1iRObFkvXsyVpu91Ag@mail.gmail.com

>On Wed, Jul 31, 2013 at 9:36 AM, majianpeng <majianpeng@gmail.com> wrote:
>> [snip]
>> I think this patch can do work:
>> Those case which i tested
>> A: filesize=0,  buffer=1M
>> B:  data[2M] | hole| data[2M], bs= 6M/7M
>
>I don't think your zero buffer change is correct for this test case.
>
dd if=/dev/urandom of=file bs=1M count=2  oflag=direct
dd if=/dev/urandom of=file bs=1M count=2 seek=4  oflag=direct
ls file
-rw-r--r-- 1 root root  6291456 Jul 31 12:46 file

debug message:
[78370.408220] ceph:           file.c:355  : striped_read 0~7340032 (read 0) got 2097152 HITSTRIPE SHORT
[78370.409179] ceph:           file.c:355  : striped_read 2097152~5242880 (read 2097152) got 0 HITSTRIPE HITHOLE
[78370.409182] ceph:           file.c:362  :  zero hole 2097152 to 4194304
[78370.431289] ceph:           file.c:355  : striped_read 4194304~3145728 (read 4194304) got 2097152 SHORT
[78370.431294] ceph:           file.c:399  : striped_read returns 6291456

Am i missing something?

>> C: data[4m] | hole | hole |data[2M]  bs=16M/18M
>>
>> Are there some case ignore?
>> Thanks!
>> Jianpeng Ma
>>
>>
>> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
>> index 2ddf061..96ce893 100644
>> --- a/fs/ceph/file.c
>> +++ b/fs/ceph/file.c
>> @@ -319,7 +319,7 @@ static int striped_read(struct inode *inode,
>>         int read;
>>         struct page **page_pos;
>>         int ret;
>> -       bool hit_stripe, was_short;
>> +       bool hit_stripe, was_short, hit_hole = false;
>>
>>         /*
>>          * we may need to do multiple reads.  not atomic, unfortunately.
>> @@ -342,21 +342,30 @@ more:
>>                                   ci->i_truncate_seq,
>>                                   ci->i_truncate_size,
>>                                   page_pos, pages_left, page_align);
>> -       if (ret == -ENOENT)
>> +
>> +       if ((ret == 0  || ret == -ENOENT) && pos < inode->i_size)
>> +               hit_hole = true;
>
>why do we need 'hit_hole', it's essential the same as was_short. The code
>is already so messy.
>I don't think adding 'hit_hole' make it more readable.
>
hit_hole means return value are ENOENT or zero.
But the short-read contain EOF beside above two case.
>> +       else if (ret == -ENOENT)
>>                 ret = 0;
>> +
>>         hit_stripe = this_len < left;
>> -       was_short = ret >= 0 && ret < this_len;
>> -       dout("striped_read %llu~%u (read %u) got %d%s%s\n", pos, left,
>read,
>> -            ret, hit_stripe ? " HITSTRIPE" : "", was_short ? " SHORT" :
>"");
>> -
>> -       if (ret > 0) {
>> -               int didpages = (page_align + ret) >> PAGE_CACHE_SHIFT;
>> -
>> -               if (read < pos - off) {
>> -                       dout(" zero gap %llu to %llu\n", off + read, pos);
>> -                       ceph_zero_page_vector_range(page_align + read,
>> -                                                   pos - off - read,
>pages);
>> +       was_short = ret > 0 && ret < this_len;
>> +       dout("striped_read %llu~%u (read %u) got %d%s%s%s\n", pos, left,
>read,
>> +            ret, hit_stripe ? " HITSTRIPE" : "", was_short ? " SHORT" :
>"",
>> +            hit_hole ? " HITHOLE" : "");
>> +
>> +       if (ret > 0 || hit_hole) {
>> +               int didpages;
>> +
>> +               if (hit_hole) {
>> +                       ret = this_len;
>> +                       dout(" zero hole %llu to %llu\n", pos , pos +
>ret);
>> +                       ceph_zero_page_vector_range(page_align + read,
>> +                                                       ret, pages);
>> +                       hit_hole = false;
>this is incorrect for the 'ret > 0' and 'ret = -ENOENT' cases.
>
For the ret > 0, it can't do those.
For the ret = -ENOENT and  pos + this_len > i_size mean , can you give me a example ?

Jianpeng Ma
>Besides, if 'pos + this_len >= i_size'. we should do nothing here. let the
>'zero trailing bytes'
>code do the job.
>
>Yan, Zheng
>
>>                 }
>> +               didpages = (page_align + ret) >> PAGE_CACHE_SHIFT;
>> +
>>                 pos += ret;
>>                 read = pos - off;
>>                 left -= ret;
>
Thanks!
Jianpeng Ma
>On Wed, Jul 31, 2013 at 9:36 AM, majianpeng <majianpeng@gmail.com> wrote:
>> [snip]
>> I think this patch can do work:
>> Those case which i tested
>> A: filesize=0,  buffer=1M
>> B:  data[2M] | hole| data[2M], bs= 6M/7M
>
>I don't think your zero buffer change is correct for this test case.
>
>> C: data[4m] | hole | hole |data[2M]  bs=16M/18M
>>
>> Are there some case ignore?
>> Thanks!
>> Jianpeng Ma
>>
>>
>> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
>> index 2ddf061..96ce893 100644
>> --- a/fs/ceph/file.c
>> +++ b/fs/ceph/file.c
>> @@ -319,7 +319,7 @@ static int striped_read(struct inode *inode,
>>         int read;
>>         struct page **page_pos;
>>         int ret;
>> -       bool hit_stripe, was_short;
>> +       bool hit_stripe, was_short, hit_hole = false;
>>
>>         /*
>>          * we may need to do multiple reads.  not atomic, unfortunately.
>> @@ -342,21 +342,30 @@ more:
>>                                   ci->i_truncate_seq,
>>                                   ci->i_truncate_size,
>>                                   page_pos, pages_left, page_align);
>> -       if (ret == -ENOENT)
>> +
>> +       if ((ret == 0  || ret == -ENOENT) && pos < inode->i_size)
>> +               hit_hole = true;
>
>why do we need 'hit_hole', it's essential the same as was_short. The code
>is already so messy.
>I don't think adding 'hit_hole' make it more readable.
>
>> +       else if (ret == -ENOENT)
>>                 ret = 0;
>> +
>>         hit_stripe = this_len < left;
>> -       was_short = ret >= 0 && ret < this_len;
>> -       dout("striped_read %llu~%u (read %u) got %d%s%s\n", pos, left,
>read,
>> -            ret, hit_stripe ? " HITSTRIPE" : "", was_short ? " SHORT" :
>"");
>> -
>> -       if (ret > 0) {
>> -               int didpages = (page_align + ret) >> PAGE_CACHE_SHIFT;
>> -
>> -               if (read < pos - off) {
>> -                       dout(" zero gap %llu to %llu\n", off + read, pos);
>> -                       ceph_zero_page_vector_range(page_align + read,
>> -                                                   pos - off - read,
>pages);
>> +       was_short = ret > 0 && ret < this_len;
>> +       dout("striped_read %llu~%u (read %u) got %d%s%s%s\n", pos, left,
>read,
>> +            ret, hit_stripe ? " HITSTRIPE" : "", was_short ? " SHORT" :
>"",
>> +            hit_hole ? " HITHOLE" : "");
>> +
>> +       if (ret > 0 || hit_hole) {
>> +               int didpages;
>> +
>> +               if (hit_hole) {
>> +                       ret = this_len;
>> +                       dout(" zero hole %llu to %llu\n", pos , pos +
>ret);
>> +                       ceph_zero_page_vector_range(page_align + read,
>> +                                                       ret, pages);
>> +                       hit_hole = false;
>this is incorrect for the 'ret > 0' and 'ret = -ENOENT' cases.
>
>Besides, if 'pos + this_len >= i_size'. we should do nothing here. let the
>'zero trailing bytes'
>code do the job.
>
>Yan, Zheng
>
>>                 }
>> +               didpages = (page_align + ret) >> PAGE_CACHE_SHIFT;
>> +
>>                 pos += ret;
>>                 read = pos - off;
>>                 left -= ret;
>

  parent reply	other threads:[~2013-07-31  5:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25  0:52 question about striped_read majianpeng
2013-07-25  5:54 ` Sage Weil
2013-07-25  6:55   ` majianpeng
2013-07-25 12:27     ` Yan, Zheng
2013-07-25 15:50       ` Sage Weil
2013-07-26  0:48         ` majianpeng
2013-07-26  1:14           ` Yan, Zheng
2013-07-26  1:22             ` majianpeng
2013-07-26  1:36               ` Yan, Zheng
2013-07-26  1:38                 ` majianpeng
2013-07-26  1:59                   ` Yan, Zheng
2013-07-26  2:07                     ` majianpeng
     [not found]                       ` <CAAM7YAkNQA5PqVr15CXRQ5xPLk42VCCb3kf3U8ic9f6n3d9SGg@mail.gmail.com>
2013-07-29  3:00                         ` majianpeng
2013-07-29  5:02                           ` Yan, Zheng
2013-07-30  2:08                             ` majianpeng
2013-07-30  2:56                               ` Yan, Zheng
2013-07-30 11:01                             ` majianpeng
2013-07-30 11:14                               ` Yan, Zheng
2013-07-30 11:20                                 ` majianpeng
2013-07-30 11:41                                 ` majianpeng
2013-07-30 12:25                                   ` Yan, Zheng
2013-07-31  0:27                                     ` majianpeng
2013-07-31  0:40                                       ` Sage Weil
2013-07-31  0:44                                         ` majianpeng
2013-07-31  0:47                                           ` Sage Weil
2013-07-31  1:36                                             ` majianpeng
     [not found]                                               ` <CAAM7YAnGaXcQm1LcaCUGL71FGRV5zfNx1iRObFkvXsyVpu91Ag@mail.gmail.com>
2013-07-31  5:46                                                 ` majianpeng [this message]
     [not found]                                                   ` <CAAM7YAmv6Ar_oTdYG31YSHnQwyUUYSNq3Zj_4fHcwMoOvno7Sw@mail.gmail.com>
2013-07-31  7:32                                                     ` majianpeng
2013-07-31  8:26                                                       ` Yan, Zheng
2013-08-01  1:45                                                         ` majianpeng
2013-08-01  3:29                                                           ` Yan, Zheng
2013-08-01  6:30                                                             ` majianpeng
2013-08-01  7:19                                                               ` Yan, Zheng

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=2013073113222469570311@gmail.com \
    --to=majianpeng@gmail.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=sage@inktank.com \
    --cc=ukernel@gmail.com \
    /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.