summaryrefslogtreecommitdiffstats
path: root/block/blk-map.c
diff options
context:
space:
mode:
authorMing Lei <ming.lei@redhat.com>2022-01-26 11:58:30 +0800
committerJens Axboe <axboe@kernel.dk>2022-02-11 15:10:49 -0700
commit06582bc86d7f48d35cd044098ca1e246e8c7c52e (patch)
treed6038c855d863a83b254063fd3f6bea8887a1bad /block/blk-map.c
parenta12821d5e012a42673f6fe521971f193441d8aa4 (diff)
downloadlinux-stable-06582bc86d7f48d35cd044098ca1e246e8c7c52e.tar.gz
linux-stable-06582bc86d7f48d35cd044098ca1e246e8c7c52e.tar.bz2
linux-stable-06582bc86d7f48d35cd044098ca1e246e8c7c52e.zip
block: loop:use kstatfs.f_bsize of backing file to set discard granularity
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> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220126035830.296465-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/blk-map.c')
0 files changed, 0 insertions, 0 deletions