NeilBrown wrote:
> I managed to reproduce the bug, and when I applied your patches I cannot any
> more. So it looks like you've fixed it - thanks.
I hope so too. Now I just hope Linus takes the patches.
> That just leave the bmap issue. I'll post a patch which causes lseek to be
> used when
On Fri, 10 Apr 2015 11:24:31 +1000 NeilBrown wrote:
> On Thu, 09 Apr 2015 10:23:08 +0100 David Howells wrote:
>
> > NeilBrown wrote:
> >
> > > Is there a better way? Could a better way be created? Maybe
> > > SEEK_DATA_RELIABLE ??
> >
> > fiemap() maybe?
> >
> > > Also, if you do try to
On Fri, Apr 10, 2015 at 02:28:16PM +0100, David Howells wrote:
> Dave Chinner 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
NeilBrown wrote:
> Is there a better way? Could a better way be created? Maybe
> SEEK_DATA_RELIABLE ??
fiemap() maybe?
> Also, if you do try to use fscache on btrfs with 3.19, then nothing gets
> cached (as expected) and with a heavy load you can lose a race and get an
> asserting fail in f
hi,
fscache cannot currently be used with btrfs as the backing store for the
cache (managed by cachefilesd).
This is because cachefiles needs the ->bmap address_space_operation, and
btrfs doesn't provide it.
cachefiles only uses this to find out if a particular page is a 'hole' or
not. For
