On Mon, Sep 24, 2018 at 10:43 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > On Sep 24 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Mon, Sep 24, 2018 at 10:06 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: >>> Hi, >>> >>> What happens with dirty pages when a (writeback-cache enabled) FUSE >>> filesystem sends a NOTIFY_INVAL_INODE request? Are they dropped? >>> flushed? >> >> Haven't tried, but AFAICS it flushes dirty pages and waits on >> writeback for these. > > "waits on writeback" means "wait until the write requests have > completed"? Appears to be so. An so there we have the blocking notification you've asked about. > >> However, it doesn't wait on already queued >> writes. So it's a bit of a mess at the moment. >> >>> >>> To me neither behaviour seems correct... >> >> What would be the correct operation be if neither flushing not >> dropping them is correct? > > What about returning an error? > > My thinking is that if the filesystem issues an inval request, then the > data has already been changed/disappeared. So a writeback at this point > would most likely not do the right thing - since it would partially > write back old data that has actually been mutated. > > Similarly, just dropping the cache seems bad because most likely this > causes data loss for the new data that hasn't been flushed. This is a pretty complicated issue. For reference we should look at what NFS is doing, because NFS has a long history and likely that behavior is the most acceptable when cached writes are mixed with concurrent remote updates. And I don't think NFS will report an error in such a situation. More likely it will accept the reordered writes. Thanks, Miklos
