From: Eric Blake <eblake@redhat.com>
To: Sunil Mushran <sunil.mushran@oracle.com>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>,
Christoph Hellwig <hch@infradead.org>,
Josef Bacik <josef@toxicpanda.com>,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags
Date: Fri, 22 Apr 2011 11:03:45 -0600 [thread overview]
Message-ID: <4DB1B4F1.8070109@redhat.com> (raw)
In-Reply-To: <4DB1B37C.9070406@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
On 04/22/2011 10:57 AM, Sunil Mushran wrote:
> On 04/22/2011 09:40 AM, Eric Blake wrote:
>> On 04/22/2011 10:28 AM, Sunil Mushran wrote:
>>> while(1) {
>>> read(block);
>>> if (block_all_zeroes)
>>> lseek(SEEK_DATA);
>>> }
>>>
>>> What's wrong with the above? If this is the case, even SEEK_HOLE
>>> is not needed but should be added as it is already in Solaris.
>
> Holes are an implementation detail.
Nobody's arguing that. And on Solaris, a file system with no holes
support tells you that up front - lseek(fd, 0, SEEK_HOLE) returns the
end of the file (unless the file is 0 bytes, then it fails with ENXIO).
>
> cp can read whatever blocksize it chooses. If that block contains
> zero, it would signal cp that maybe it should SEEK_DATA and skip
> reading all those blocks. That's all. We are not trying to achieve
> perfection. We are just trying to reduce cpu waste.
>
> If the fs supports SEEK_*, then great. If it does not, then it is no
> worse than before.
But providing just SEEK_DATA _is_ worse than before if you don't provide
the correct SEEK_HOLE everywhere. Because then your algorithm of trying
lseek(SEEK_DATA) after every run of zeros in the hopes of an
optimization is a wasted syscall, since it will just return your current
offset every time, so you end up with more syscalls than if you had used
the single lseek(SEEK_DATA) that returns the end of the file up front,
and known that the remainder of the file has no holes to even try
seeking past.
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
next prev parent reply other threads:[~2011-04-22 17:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 19:42 [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags Josef Bacik
2011-04-21 19:42 ` [PATCH 2/2] Btrfs: implement our own ->llseek Josef Bacik
2011-04-21 20:45 ` [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags Theodore Tso
2011-04-21 21:29 ` Sunil Mushran
2011-04-22 3:23 ` Matthew Wilcox
2011-04-22 4:47 ` Christoph Hellwig
[not found] ` <loom.20110422T001650-760@post.gmane.org>
[not found] ` <BANLkTiknb+hzFAjpwESwMcqMVtkFc0HFQQ@mail.gmail.com>
2011-04-22 4:50 ` Christoph Hellwig
2011-04-22 11:28 ` Markus Trippelsdorf
2011-04-22 11:50 ` Eric Blake
2011-04-22 16:28 ` Sunil Mushran
2011-04-22 16:40 ` Eric Blake
2011-04-22 16:57 ` Sunil Mushran
2011-04-22 17:03 ` Eric Blake [this message]
2011-04-22 17:08 ` Sunil Mushran
2011-04-22 18:06 ` Andreas Dilger
2011-04-22 23:33 ` Sunil Mushran
2011-04-24 17:49 ` Jamie Lokier
2011-04-25 12:37 ` Eric Blake
2011-04-25 14:15 ` Jamie Lokier
[not found] ` <20110422112852.GB1627-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org>
2011-04-22 13:06 ` Eric Blake
2011-04-25 15:02 ` Nick Bowler
[not found] ` <20110425150227.GA10653-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
2011-04-25 15:48 ` Eric Blake
2011-04-22 20:10 ` Jonathan Nieder
2011-04-22 20:49 ` Sunil Mushran
2011-04-25 3:11 ` Valdis.Kletnieks
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=4DB1B4F1.8070109@redhat.com \
--to=eblake@redhat.com \
--cc=hch@infradead.org \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=sunil.mushran@oracle.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;
as well as URLs for NNTP newsgroup(s).