From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Fan Li <fanofcode.li@samsung.com>
Cc: ^[@jaegeuk-2.local, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/3] f2fs: support finding extents after isize
Date: Tue, 5 Jan 2016 10:11:14 -0800 [thread overview]
Message-ID: <20160105181114.GC2618@jaegeuk> (raw)
In-Reply-To: <000d01d14789$eb83f380$c28bda80$@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?
> > > > > >
> > > > > > 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.
> > > > >
> > > > > I have a similar idea that add an actual size which marks the end
> > > > > of last extent, so we can know if the current extent is the last one, even without searching for extents behind.
> > > >
> > > > Where do you want to store that size in disk?
> > >
> > > I'm still not very confident about this idea, so I didn't really think
> > > that through yet, inode may be a proper place.
> > > Or we just write a special function to find it, and call it only when
> > > fiemap is called and disk size isn't initiated yet. After all this isn't frequently-used.
> > >
> > > >
> > > > > But there is a problem I still can't figure out, after truncate
> > > > > an extent at the end of file beyond isize , how do I know where
> > > > > the new last extent ends or if there are still extents beyond isize? after all, the extents beyond isize could be
> discontinuous.
> > > >
> > > > So, that's why I proposed a flag instead of a kind of i_disksize.
> > > > We can just set the flag, only if a file *may* have a extent beyond i_size in fallocate, and unset it through f2fs_truncate.
> > > > Moreover, I don't expect that this happens so frequently.
> > >
> > > if flag could indicate "may", will i_disksize do a better job in the same way?
> > > let i_disksize be the end of the last extent that *may* exist beyond
> > > i_size, set it also in fallocate,when truncate, if the length is still
> > > beyond isize, we set the new length as i_disksize, so in worse scenario we won't have to search up to s_maxbytes.
> >
> > My real concern is that there no space for i_disksize.
>
> I see. How about combine both ideas, use flag as you propose, and if fiemap ever needs to
> look up the last extent beyond isize, we calculate i_disksize first and cache it in f2fs_inode_info,
> use it to determine the last extent.
>
> This way we don't have to look up all blocks up to s_maxbytes, and need no extra space in disk.
Looks good to me.
Thanks,
------------------------------------------------------------------------------
next prev parent reply other threads:[~2016-01-05 18:11 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 [this message]
2016-01-05 3:19 ` Chao Yu
2016-01-05 3:29 ` Jaegeuk Kim
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=20160105181114.GC2618@jaegeuk \
--to=jaegeuk@kernel.org \
--cc=fanofcode.li@samsung.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.