From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <chao2.yu@samsung.com>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/3] f2fs: support finding extents after isize
Date: Mon, 4 Jan 2016 19:29:53 -0800 [thread overview]
Message-ID: <20160105032953.GA863@jaegeuk> (raw)
In-Reply-To: <009801d14767$fba23410$f2e69c30$@samsung.com>
Hi,
...
> > > > Nope, what I'm talking about is *correctness* of our ->fiemap interface, but you're trying
> > to avoid it by saying "support more
> > > cases,
> > > > it's an improvement". That doesn't make any sense to me, since correctness issue still not
> > be fixed.
> > >
> > > I'm not sure what you mean by avoiding, I think the comment and reply I written has already
> > stated the issue and
> > > limitation of this patch.
> > > Now there are two suggestions:
> > > 1. support one more scenario, and all old scenarios are dealt like before, but it still can't
> > support discontinuous extent after
> > > isize.
> > > 2. support all scenarios, but sacrifice performance for lots of common scenarios by checking
> > about 10^9 blocks.
> >
> > IMO, we can think about #2 whether there is an efficient way.
> >
> > How many cases does this incur?
> > One is fallocate with keeping i_size, ana other?
>
> AFAIK, no more.
>
> >
> > How about adding FADVISE_OVER_ISIZE to represent inode has blocks beyond i_size?
> > Then, we can set this flag in fallocate and reset it in f2fs_truncate.
>
> Append write in such inode could destroy this convention, right?
Right, but we have another chance to reset the flag, when fiemap checks the end
of allocated space.
Thanks,
>
> Thanks,
>
> >
> > Thanks,
> >
> > >
> > > I think we can all agree both ideas have their flaws.
> > > The only divergence is that I vote the first, and you the second. I think the most important
> > thing is that it works fluently in most
> > > scenarios, and you think is that it works in every scenarios even it's very slow.
> > >
> > > I think my method is more pratical, but balance between performance and utility seems to be
> > an Eternal problem.
> > >
> > > >
> > > > >
> > > > > use max blocks as boundary would get us the precise result, but it
> > > > > also means after we reach the EOF, we still need to look up every
> > > > > block between the EOF and sb-> s_maxbytes to make sure the EOF is
> > > > > true, that's about 4TB or 10^9 blocks.
> > > > > And it affects all scenarios where the search range covers the last
> > > > > extent in the file, not just extents beyond isize. I think this price
> > > > > is too high to pay.
> > > >
> > > > That's another performance issue.
> > > >
> > > > >
> > > > > I was hoping that I can make f2fs_map_block return an EOF to solve
> > > > > this problem some time later, or anyone have a better idea?
> > > >
> > > > At least we can seek valid dnode block like the way llseek use.
> > > >
> > > > In addition, for most cases, few of i_nid[5] in f2fs_inode will be NULL, we could skip searching
> > all dnode block in such
> > > non-allocated
> > > > indirect node, instead of searching dnode block f2fs_map_block one by one.
> > > >
> > > > Thanks,
> > > >
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Fan li <fanofcode.li@samsung.com>
> > > > > > > ---
> > > > > > > fs/f2fs/data.c | 7 +------
> > > > > > > 1 file changed, 1 insertion(+), 6 deletions(-)
> > > > > > >
> > > > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index
> > > > > > > a9a4d89..f89cf07
> > > > > > > 100644
> > > > > > > --- a/fs/f2fs/data.c
> > > > > > > +++ b/fs/f2fs/data.c
> > > > > > > @@ -798,12 +798,6 @@ int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info
> > *fieinfo,
> > > > > > > isize = i_size_read(inode);
> > > > > > >
> > > > > > > mutex_lock(&inode->i_mutex);
> > > > > > > - if (start >= isize)
> > > > > > > - goto out;
> > > > > > > -
> > > > > > > - if (start + len > isize)
> > > > > > > - len = isize - start;
> > > > > > > -
> > > > > > > if (logical_to_blk(inode, len) == 0)
> > > > > > > len = blk_to_logical(inode, 1);
> > > > > > >
> > > > > > > @@ -829,6 +823,7 @@ next:
> > > > > > > * punch holes beyond isize and keep size unchanged.
> > > > > > > */
> > > > > > > flags |= FIEMAP_EXTENT_LAST;
> > > > > > > + last_blk = start_blk - 1;
> > > > > > > }
> > > > > > >
> > > > > > > if (size)
> > > > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------------
> > > > > -------- _______________________________________________
> > > > > Linux-f2fs-devel mailing list
> > > > > Linux-f2fs-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
------------------------------------------------------------------------------
next prev parent reply other threads:[~2016-01-05 3:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-30 9:17 [PATCH 2/3] f2fs: support finding extents after isize Fan Li
2015-12-30 13:27 ` Chao Yu
2015-12-31 3:37 ` Fan Li
2015-12-31 6:34 ` Chao Yu
2016-01-04 5:57 ` Fan Li
2016-01-04 6:55 ` Jaegeuk Kim
2016-01-04 11:13 ` Fan Li
2016-01-04 23:14 ` Jaegeuk Kim
2016-01-05 2:37 ` Fan Li
2016-01-05 3:08 ` Jaegeuk Kim
2016-01-05 7:22 ` Fan Li
2016-01-05 18:11 ` Jaegeuk Kim
2016-01-05 3:19 ` Chao Yu
2016-01-05 3:29 ` Jaegeuk Kim [this message]
2016-01-05 9:36 ` Chao Yu
2016-01-04 10:00 ` Chao Yu
2016-01-04 10:55 ` Fan Li
2016-01-05 3:48 ` Chao Yu
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=20160105032953.GA863@jaegeuk \
--to=jaegeuk@kernel.org \
--cc=chao2.yu@samsung.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/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.