Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > The fact that after a block layer initiated freeze - again mostly a
> > device mapper problem - one may or may not be able to successfully read
> > from the filesystem is annoying. Of course one can't write, that will
> > hang one immediately. But if one still has some data in the page cache
> > one can still dump the contents of that file. That's at least odd
> > behavior from a users POV even if for us it's cleary why that's the
> > case.
> 
> A frozen filesystem doesn't prevent read operations from occurring.

Yes, that's what I was saying. I'm not disputing that.

> 
> > And a freeze does do a sync_filesystem() and a sync_blockdev() to flush
> > out any dirty data for that specific filesystem.
> 
> Yes, it's required to do that - the whole point of freezing a
> filesystem is to bring the filesystem into a *consistent physical
> state on persistent storage* and to hold it in that state until it
> is thawed.
> 
> > So it would be fitting
> > to give users an api that allows them to also drop the page cache
> > contents.
> 
> Not as part of a freeze operation.

Yes, that's why I'd like to have a separate e.g., flag for fadvise.

> > For some use-cases like the Gnome use-case one wants to do a freeze and
> > drop everything that one can from the page cache for that specific
> > filesystem.
> 
> So they have to do an extra system call between FS_IOC_FREEZE and
> FS_IOC_THAW. What's the problem with that? What are you trying to
> optimise by colliding cache purging with FS_IOC_FREEZE?
> 
> If the user/application/infrastructure already has to iterate all
> the mounted filesystems to freeze them, then it's trivial for them
> to add a cache purging step to that infrastructure for the storage
> configurations that might need it. I just don't see why this needs
> to be part of a block device freeze operation, especially as the
> "purge caches on this filesystem" operation has potential use cases
> outside of the luksSuspend context....

Ah, I'm sorry I think we're accidently talking past each other... I'm
_not_ trying to tie block layer freezing and cache purging. I'm trying
to expose something like:

posix_fadvise(fs_fd, [...], POSIX_FADV_FS_DONTNEED/DROP);

The Gnome people could then do:

cryptsetup luksSuspend
posix_fadvise(fs_fd, [...], POSIX_FADV_FS_DONTNEED/DROP);

as two separate operations.

Because the dropping the caches step is useful to other users as well;
completely independent of the block layer freeze that I used to
motivate this.




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux