On Fri, 10 Apr 2015 11:24:31 +1000 NeilBrown <neilb@xxxxxxx> wrote: > On Thu, 09 Apr 2015 10:23:08 +0100 David Howells <dhowells@xxxxxxxxxx> wrote: > > > NeilBrown <neilb@xxxxxxx> 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 fscache_enqueue_operation > > > > Do you have the patches here applied? > > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache-fixes > > > > Do I don't. I had looked through them and while they did seem to be > addressing similar sorts of races, nothing seems like an obvious match. > I haven't been able to reproduce the BUG_ON myself. I only have a report > of it repeatedly affecting someone else: > > https://bugzilla.opensuse.org/show_bug.cgi?id=908706 > > I'll probably have to be happy with fixing usage on btrfs, and hope the other > bug is fixed already or doesn't become a problem. 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. That just leave the bmap issue. I'll post a patch which causes lseek to be used when the fs says that is OK. Thanks, NeilBrown
Attachment:
pgpoXY45n4Aub.pgp
Description: OpenPGP digital signature
-- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
