Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read

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

 



Hi,

On 29/10/2019 16:52, Linus Torvalds wrote:
On Tue, Oct 29, 2019 at 3:25 PM Konstantin Khlebnikov
<khlebnikov@xxxxxxxxxxxxxx> wrote:
I think all network filesystems which synchronize metadata lazily should be
marked. For example as "SB_VOLATILE". And vfs could handle them specially.
No need. The VFS layer doesn't call generic_file_buffered_read()
directly anyway. It's just a helper function for filesystems to use if
they want to.

They could (and should) make sure the inode size is sufficiently
up-to-date before calling it. And if they want something more
synchronous, they can do it themselves.

But NFS, for example, has open/close consistency, so the metadata
revalidation is at open() time, not at read time.

                Linus

NFS may be ok here, but it will break GFS2. There may be others too... OCFS2 is likely one. Not sure about CIFS either. Does it really matter that we might occasionally allocate a page and then free it again?

Ramfs is a simple test case, but at the same time it doesn't represent the complexity of a real world filesystem. I'm just back from a few days holiday so apologies if I've missed something earlier on in the discussions,

Steve.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux