NeilBrown ne...@suse.de 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
On Fri, 10 Apr 2015 11:24:31 +1000 NeilBrown ne...@suse.de wrote:
On Thu, 09 Apr 2015 10:23:08 +0100 David Howells dhowe...@redhat.com wrote:
NeilBrown ne...@suse.de wrote:
Is there a better way? Could a better way be created? Maybe
SEEK_DATA_RELIABLE ??
fiemap() maybe?
On Fri, Apr 10, 2015 at 02:28:16PM +0100, David Howells wrote:
Dave Chinner da...@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
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
NeilBrown ne...@suse.de 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
