From: Sunil Mushran <sunil.mushran@oracle.com>
To: Paul Eggert <eggert@CS.UCLA.EDU>
Cc: "jeff.liu" <jeff.liu@oracle.com>, Jim Meyering <jim@meyering.net>,
Tao Ma <tao.ma@oracle.com>,
bug-coreutils@gnu.org, Joel Becker <Joel.Becker@oracle.com>,
Chris Mason <chris.mason@oracle.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Thu, 10 Jun 2010 17:31:57 -0700 [thread overview]
Message-ID: <4C1183FD.9010502@oracle.com> (raw)
In-Reply-To: <4C11798B.6090500@cs.ucla.edu>
On 06/10/2010 04:47 PM, Paul Eggert wrote:
> On 06/09/2010 11:56 PM, jeff.liu wrote:
>
>> Yeah, I just realized that the behaviour I observed is caused by the delay allocation mechanism of
>> the particular FS.
>>
> If the file system is using delayed allocation, then can
> the fiemap ioctl tell us that a file contains a hole (because nothing has been
> allocated there), but read() would tell us that the file contains nonzero data at the same location
> (because it's sitting in a buffer somewhere)? If so, we'd need to do something like invoke
> fdatasync() on the file before issuing the fiemap ioctl, to force allocation; or perhaps
> there's another ioctl that will do the allocation without having to actually do a sync.
>
I guess we'll have to use FIEMAP_FLAG_SYNC.
> There's also the issue of copying from a file at the same time that some other process
> is writing to it, but that is allowed to produce ill-defined behavior. I'm more worried
> about the case where some other process writes to the source file just before 'cp' starts.
>
cp's behavior with active files is undefined. But we know it reads from
offset 0 to MAX. With fiemap it will continue to do the same with the
exception that it will skip reads (and thus writes) depending on the extent
map it gets at the very beginning.
> (Sorry, I haven't had time yet to dive into the proposed change; I'm still trying to understand
> the environment.)
>
> One other thing: Solaris 10 supports lseek with the SEEK_HOLE and SEEK_DATA options, which
> are easier to use and which (as far as I can tell from the manual) shouldn't require anything
> fdatasync-ish. Any objection if I propose support for that too? It is supposed to work
> with ZFS, something I can test here.
>
There is no plan to implement SEEK_HOLE/SEEK_DATA in the kernel.
At most glibc will use fiemap to extend lseek(). BTW, SEEK_HOLE/DATA
also have the same problem with active files.
ccing linux-ext4.
next parent reply other threads:[~2010-06-11 0:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4BE41FFF.4020809@oracle.com>
[not found] ` <871vdho68j.fsf@meyering.net>
[not found] ` <4BEC0BCC.3080906@oracle.com>
[not found] ` <87k4qyl6lw.fsf@meyering.net>
[not found] ` <4BF683CC.3060407@oracle.com>
[not found] ` <4BF6ABE7.3020600@oracle.com>
[not found] ` <877hmpeivx.fsf@meyering.net>
[not found] ` <4BFF763A.9010205@oracle.com>
[not found] ` <8763286kni.fsf@meyering.net>
[not found] ` <4C0275FA.1030901@oracle.com>
[not found] ` <874ohpywri.fsf@meyering.net>
[not found] ` <87y6exuc5i.fsf@meyering.net>
[not found] ` <874ohdu5b8.fsf@meyering.net>
[not found] ` <87eighs1t9.fsf@meyering.net>
[not found] ` <4C0FA93C.6020205@oracle.com>
[not found] ` <87iq5sp7eg.fsf@meyering.net>
[not found] ` <4C108CB9.8010805@oracle.com>
[not found] ` <4C11798B.6090500@cs.ucla.edu>
2010-06-11 0:31 ` Sunil Mushran [this message]
2010-06-11 8:31 ` bug#6131: [PATCH]: fiemap support for efficient sparse file copy jeff.liu
2010-06-11 12:38 ` Jim Meyering
2010-06-11 14:03 ` Eric Sandeen
2010-06-13 3:37 ` jeff.liu
2010-06-15 21:09 ` Paul Eggert
2010-06-15 21:11 ` Paul Eggert
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=4C1183FD.9010502@oracle.com \
--to=sunil.mushran@oracle.com \
--cc=Joel.Becker@oracle.com \
--cc=bug-coreutils@gnu.org \
--cc=chris.mason@oracle.com \
--cc=eggert@CS.UCLA.EDU \
--cc=jeff.liu@oracle.com \
--cc=jim@meyering.net \
--cc=linux-ext4@vger.kernel.org \
--cc=tao.ma@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 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.