| Message ID | 20220126035830.296465-1-ming.lei@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [V3] block: loop:use kstatfs.f_bsize of backing file to set discard granularity | expand |
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
On Wed, Jan 26, 2022 at 11:58:30AM +0800, Ming Lei wrote: > If backing file's filesystem has implemented ->fallocate(), we think the > loop device can support discard, then pass sb->s_blocksize as > discard_granularity. However, some underlying FS, such as overlayfs, > doesn't set sb->s_blocksize, and causes discard_granularity to be set as > zero, then the warning in __blkdev_issue_discard() is triggered. > > Christoph suggested to pass kstatfs.f_bsize as discard granularity, and > this way is fine because kstatfs.f_bsize means 'Optimal transfer block > size', which still matches with definition of discard granularity. > > So fix the issue by setting discard_granularity as kstatfs.f_bsize if it > is available, otherwise claims discard isn't supported. > > Cc: Christoph Hellwig <hch@lst.de> > Cc: Vivek Goyal <vgoyal@redhat.com> > Reported-by: Pei Zhang <pezhang@redhat.com> > Signed-off-by: Ming Lei <ming.lei@redhat.com> > --- > V3: > - following Christoph's suggestion to not claim discard support if > vfs_statfs() fails Hi Jens, Any chance to merge it to v5.17? Thanks, Ming
On Wed, 26 Jan 2022 11:58:30 +0800, Ming Lei wrote: > If backing file's filesystem has implemented ->fallocate(), we think the > loop device can support discard, then pass sb->s_blocksize as > discard_granularity. However, some underlying FS, such as overlayfs, > doesn't set sb->s_blocksize, and causes discard_granularity to be set as > zero, then the warning in __blkdev_issue_discard() is triggered. > > Christoph suggested to pass kstatfs.f_bsize as discard granularity, and > this way is fine because kstatfs.f_bsize means 'Optimal transfer block > size', which still matches with definition of discard granularity. > > [...] Applied, thanks! [1/1] block: loop:use kstatfs.f_bsize of backing file to set discard granularity (no commit info) Best regards,
diff --git a/drivers/block/loop.c b/drivers/block/loop.c index b1b05c45c07c..8b56eeb7e144 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -79,6 +79,7 @@ #include <linux/ioprio.h> #include <linux/blk-cgroup.h> #include <linux/sched/mm.h> +#include <linux/statfs.h> #include "loop.h" @@ -774,8 +775,13 @@ static void loop_config_discard(struct loop_device *lo) granularity = 0; } else { + struct kstatfs sbuf; + max_discard_sectors = UINT_MAX >> 9; - granularity = inode->i_sb->s_blocksize; + if (!vfs_statfs(&file->f_path, &sbuf)) + granularity = sbuf.f_bsize; + else + max_discard_sectors = 0; } if (max_discard_sectors) {
If backing file's filesystem has implemented ->fallocate(), we think the loop device can support discard, then pass sb->s_blocksize as discard_granularity. However, some underlying FS, such as overlayfs, doesn't set sb->s_blocksize, and causes discard_granularity to be set as zero, then the warning in __blkdev_issue_discard() is triggered. Christoph suggested to pass kstatfs.f_bsize as discard granularity, and this way is fine because kstatfs.f_bsize means 'Optimal transfer block size', which still matches with definition of discard granularity. So fix the issue by setting discard_granularity as kstatfs.f_bsize if it is available, otherwise claims discard isn't supported. Cc: Christoph Hellwig <hch@lst.de> Cc: Vivek Goyal <vgoyal@redhat.com> Reported-by: Pei Zhang <pezhang@redhat.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> --- V3: - following Christoph's suggestion to not claim discard support if vfs_statfs() fails V2: - take Christoph's suggestion to use kstatfs.f_bsize drivers/block/loop.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)