* [LSF/MM TOPIC] Performance of seekdir(SEEK_HOLE/DATA) and FIEMAP
@ 2017-03-16 16:09 Trond Myklebust
2017-03-16 17:53 ` [Lsf-pc] " Jeff Layton
0 siblings, 1 reply; 2+ messages in thread
From: Trond Myklebust @ 2017-03-16 16:09 UTC (permalink / raw)
To: lsf-pc@lists.linux-foundation.org; +Cc: linux-fsdevel@vger.kernel.org
Hi all,
If there are any free slots on the filesystem track, then it would be
nice to have a conversation about use of FIEMAP and SEEK_HOLE/DATA
performance.
The issue is this: as large sparse files become more prevalent, there
is a potential performance advantage to be made if applications can
quickly and easily detect areas of no data.
Full disclosure: my interest here is seeing Anna's work on implementing
the NFSv4.2 sparse file support come to fruition; right now she is
finding that the performance of the filesystem tools (both seekdir()
and FIEMAP) are insufficient to allow us to implement the READPLUS (htt
ps://tools.ietf.org/html/rfc7862#section-6.2.1) operation and realise
the promised performance goals.
If there is time left on the schedule, then it might be nice to have a
full discussion of this topic with all the filesystem folks present,
but if not, we could do it as a lightning talk.
Thanks
Trond
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Lsf-pc] [LSF/MM TOPIC] Performance of seekdir(SEEK_HOLE/DATA) and FIEMAP
2017-03-16 16:09 [LSF/MM TOPIC] Performance of seekdir(SEEK_HOLE/DATA) and FIEMAP Trond Myklebust
@ 2017-03-16 17:53 ` Jeff Layton
0 siblings, 0 replies; 2+ messages in thread
From: Jeff Layton @ 2017-03-16 17:53 UTC (permalink / raw)
To: Trond Myklebust, lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org
On Thu, 2017-03-16 at 16:09 +0000, Trond Myklebust wrote:
> Hi all,
>
> If there are any free slots on the filesystem track, then it would be
> nice to have a conversation about use of FIEMAP and SEEK_HOLE/DATA
> performance.
>
> The issue is this: as large sparse files become more prevalent, there
> is a potential performance advantage to be made if applications can
> quickly and easily detect areas of no data.
> Full disclosure: my interest here is seeing Anna's work on implementing
> the NFSv4.2 sparse file support come to fruition; right now she is
> finding that the performance of the filesystem tools (both seekdir()
> and FIEMAP) are insufficient to allow us to implement the READPLUS (htt
> ps://tools.ietf.org/html/rfc7862#section-6.2.1) operation and realise
> the promised performance goals.
>
> If there is time left on the schedule, then it might be nice to have a
> full discussion of this topic with all the filesystem folks present,
> but if not, we could do it as a lightning talk.
>
> Thanks
> Trond
>
It turns out that we still had one open slot later in the afternoon on
Tuesday so I added this there.
Cheers,
--
Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-03-16 18:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-16 16:09 [LSF/MM TOPIC] Performance of seekdir(SEEK_HOLE/DATA) and FIEMAP Trond Myklebust
2017-03-16 17:53 ` [Lsf-pc] " Jeff Layton
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).