在 2024/10/10 19:36, David Howells 写道:
Zizhi Wo <wozizhi@xxxxxxxxxx> wrote:
For scenarios such as nfs/cifs, the corresponding bsize is PAGE_SIZE aligned
cache->bsize is a property of the cache device, not the network filesystems
that might be making use of it (and it might be shared between multiple
volumes from multiple network filesystems, all of which could, in theory, have
different 'block sizes', inasmuch as network filesystems have block sizes).
David
Sorry, I might have a slightly different idea now. The EROFS process
based on fscache is similar to NFS and others, supporting only
PAGE_SIZE-granularity reads/writes, which is fine. The issue now lies in
the __cachefiles_prepare_write() function, specifically in the block
count calculation when calling cachefiles_has_space(). By default, the
block size used there is PAGE_SIZE.
If the block size of the underlying cache filesystem is not PAGE_SIZE
(for example, smaller than PAGE_SIZE), it leads to an incorrect
calculation of the required block count, which makes the system think
there is enough space when there might not be. This should be the same
problem for all network file systems that specify the back-end cache
file system mode.
For example, assume len=12k, pagesize=4k, and the underlying cache
filesystem block size is 1k. The currently available blocks are 4, with
4k of space remaining. However, cachefiles_has_space() calculates the
block count as 12k/4k=3, and since 4 > 3, it incorrectly returns that
there is enough space.
Therefore, I believe this could be a general issue. If
cachefiles_add_cache() is part of a common workflow, then using
cache->bsize here might be more appropriate? Looking forward to your
reply.
Thanks,
Zizhi Wo
