From: Jeff Layton <jlayton@poochiereds.net>
To: Trond Myklebust <trondmy@primarydata.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Performance of seekdir(SEEK_HOLE/DATA) and FIEMAP
Date: Thu, 16 Mar 2017 13:53:45 -0400 [thread overview]
Message-ID: <1489686825.2650.3.camel@poochiereds.net> (raw)
In-Reply-To: <1489680539.3151.3.camel@primarydata.com>
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>
prev parent reply other threads:[~2017-03-16 18:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [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=1489686825.2650.3.camel@poochiereds.net \
--to=jlayton@poochiereds.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=trondmy@primarydata.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.