* Re: [PATCH/RFC] fscache/cachefiles versus btrfs
[not found] ` <9282.1428672496@warthog.procyon.org.uk>
@ 2015-04-13 17:30 ` Christoph Hellwig
0 siblings, 0 replies; only message in thread
From: Christoph Hellwig @ 2015-04-13 17:30 UTC (permalink / raw)
To: David Howells
Cc: Dave Chinner, NeilBrown, linux-btrfs, linux-cachefs,
linux-fsdevel, linux-nfs
On Fri, Apr 10, 2015 at 02:28:16PM +0100, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
>
> > SEEK_HOLE/SEEK_DATA is what you want, as they are page cache
> > coherent, not extent based operations. And, really if you need it to
> > really be able to find real holes, then a superblock flag might be a
> > better way of marking filesystems with the required capability.
>
> Actually, I wonder if what I want is a kernel_read() that returns ENODATA upon
> encountering a hole at the beginning of the area to be read.
NFS READ_PLUS could also make use of this, but someone needs to actually
implement it.
Until we have that lseek SEEK_HOLE/DATA is the way to go, and the
horrible ->bmap hack needs to die ASAP, I can't believe you managed to
sneak that in in the not too distant past.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2015-04-13 17:30 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20150409235234.GJ13731@dastard>
[not found] ` <20150409174916.5a2efef5@notabene.brown>
[not found] ` <29536.1428571388@warthog.procyon.org.uk>
[not found] ` <9282.1428672496@warthog.procyon.org.uk>
2015-04-13 17:30 ` [PATCH/RFC] fscache/cachefiles versus btrfs Christoph Hellwig
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).