From: Josef Bacik <josef@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2 v2] fs: add SEEK_HOLE and SEEK_DATA flags
Date: Wed, 04 May 2011 15:33:28 -0400 [thread overview]
Message-ID: <4DC1AA08.7000502@redhat.com> (raw)
In-Reply-To: <16735.1304537498@localhost>
On 05/04/2011 03:31 PM, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:
>
>> +#define SEEK_HOLE 3 /* seek to the closest hole */
>> +#define SEEK_DATA 4 /* seek to the closest data */
>
> Comments here need nearest/next fixing as well - otherwise the ext[34] crew may
> actually implement the commented semantics. ;)
>
Balls, thanks I'll fix that.
> Other than that, patch 1/2 looks OK to me (not that there's much code to
> review), and 2/2 *seems* sane and implement the "next" semantics, though I only
> examined the while/if structure and am assuming the btrfs innards are done
> correctly. In particular, that 'while (1)' looks like it can be painful for a
> sufficiently large and fragmented file (think a gigabyte file in 4K chunks,
> producing a million extents), but I'll let a btrfs expert analyse that
> performance issue ;)
>
Heh well we do while (1) in btrfs _everywhere_, so this isn't anything
new, tho I should probably throw a cond_resched() in there. Thanks,
Josef
next prev parent reply other threads:[~2011-05-04 19:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 17:58 [PATCH 1/2 v2] fs: add SEEK_HOLE and SEEK_DATA flags Josef Bacik
2011-05-04 17:58 ` [PATCH 2/2 v2] Btrfs: implement our own ->llseek Josef Bacik
2011-05-04 19:04 ` [PATCH 1/2 v2] fs: add SEEK_HOLE and SEEK_DATA flags Valdis.Kletnieks
2011-05-04 19:10 ` Josef Bacik
2011-05-04 19:20 ` Valdis.Kletnieks
2011-05-04 19:22 ` Josef Bacik
2011-05-04 21:54 ` Dave Kleikamp
2011-05-04 21:55 ` Dave Kleikamp
2011-05-04 19:31 ` Valdis.Kletnieks
2011-05-04 19:33 ` Josef Bacik [this message]
2011-05-05 18:54 ` Marco Stornelli
2011-05-05 19:01 ` Josef Bacik
2011-05-05 18:58 ` Marco Stornelli
2011-05-05 19:19 ` Marco Stornelli
2011-05-05 19:35 ` Josef Bacik
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=4DC1AA08.7000502@redhat.com \
--to=josef@redhat.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.