From: Jeff Liu <jeff.liu@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: chris Mason <chris.mason@oracle.com>, xfs@oss.sgi.com
Subject: Re: [PATCH] Introduce SEEK_DATA/SEEK_HOLE support to XFS V4
Date: Thu, 05 Jan 2012 14:02:04 +0800 [thread overview]
Message-ID: <4F053CDC.6030007@oracle.com> (raw)
In-Reply-To: <20120104205255.GA1012@infradead.org>
Hi Christoph,
On 01/05/2012 04:52 AM, Christoph Hellwig wrote:
> Hi Jeff,
>
> thanks a lot for the patch, it looks good to except for some more
> nitpicks around the unwritten extent probing.
>
> The other issue is the patch description format - the version changelog
> should go below the --- line.
ok. :-P.
>
>> + do {
>> + unsigned int i;
>> + unsigned nr_pages;
>> + int want = min_t(pgoff_t, end - index,
>> + (pgoff_t)PAGEVEC_SIZE - 1) + 1;
>> + nr_pages = pagevec_lookup_tag(&pvec, inode->i_mapping,
>> + &index, tag, want);
>> + if (nr_pages == 0) {
>> + /*
>> + * Try to lookup pages in writeback mode from the
>> + * beginning if no more dirty page can be probed.
>> + */
>> +probe_done:
>> + if (tag == PAGECACHE_TAG_DIRTY) {
>> + tag = PAGECACHE_TAG_WRITEBACK;
>> + goto again;
>> + }
>> + break;
>
> The code flow here looks very confusing. Why not pass the tag as an
> argument to the function, then calling it twice and use the minimum?
> (that probably also wants a helper instead of duplication)
That's just because I was inclined to implement a helper rather than duplicating the probe function twice.
I have gone through the page lookup stuff, looks we can introduce a helper to wrap something like
radix_tree_gang_lookup_tag_slot()(maybe name it as radix_tree_gang_lookup_tags_slot()),
it can accept a tags array argument(dirty/unwritten), return those intertwined pages in ascending order based on offset.
Even that, I was still wondering if we can tweak the pages probing function a bit more generic to be a helper too.
Per Dave's comments in our another discussion, the reason why we can not do that is due to the different lock mechanism among FS(ext4, btrfs),
but looks those lock stuff are safe, i.e,
To probing pages, FS using mutex lock, will be something like:
mutex_lock(&inode->i_mutex);
---seek_data_or_hole()
-------probe_unwritten_buffer()
mutex_unlock(&inode->i_mutex);
For XFS, still using the shared lock.
For now, how about just calling it twice and use the minimum, and make the code tested more stable, then try to introduce a helper?
>
>
>> + * dirty data in the page cache it can be
>> + * identified by having BH_Unwritten set in
>> + * each buffer. Also, the buffer head state
>> + * might be in BH_Uptodate if the buffer
>> + * writeback procedure was fired, we need to
>> + * examine it too.
>> + */
>> + if (buffer_unwritten(bh) ||
>> + buffer_uptodate(bh)) {
>> + found = true;
>> + if (get_offset)
>> + *offset = XFS_FSB_TO_B(
>> + mp, last);
>
> Currently seek hole doesn't set get_offset we skip the whole extent.
> This seems a bit inconsistent - shouldn't we also return that offset
> for the hole case? if the dirty data only starts past the start block
> of the map the first blocks of it still are a hole.
Indeed, we can get a hole offset a bit more accurate than before in this way.
Thanks,
-Jeff
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2012-01-05 6:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-28 13:35 [PATCH] Introduce SEEK_DATA/SEEK_HOLE support to XFS V4 Jeff Liu
2012-01-04 20:52 ` Christoph Hellwig
2012-01-05 6:02 ` Jeff Liu [this message]
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=4F053CDC.6030007@oracle.com \
--to=jeff.liu@oracle.com \
--cc=chris.mason@oracle.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox