* Re: [PATCH] block: loop: set discard_granularity as PAGE_SIZE if sb->s_blocksize is 0 [not found] <20220124100628.1327718-1-ming.lei@redhat.com> @ 2022-01-24 13:36 ` Vivek Goyal [not found] ` <Ye6yE2Ephyv+WBYY@infradead.org> 1 sibling, 0 replies; 2+ messages in thread From: Vivek Goyal @ 2022-01-24 13:36 UTC (permalink / raw) To: Ming Lei Cc: Jens Axboe, linux-block, Pei Zhang, Miklos Szeredi, linux-unionfs On Mon, Jan 24, 2022 at 06:06:28PM +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. [ Copying linux-unionfs and Miklos ] Miklos mentioned that it might be ok to copy upper->s_blocksize into ovl->s_blocksize in overlayfs as other anonymous filesystem set it to some value (nfs, 9p, fuse, cifs) as well. So it might be reasonable to fix overlayfs as well. But I think we need a block layer fix as well to deal with any filesystem which supports ->fallocate() and does not advertize ->s_blocksize. Not advertizing ->s_blocksize will probably only lead to suboptimial performance and nothing more. > > Fix the issue by setting discard_granularity as PAGE_SIZE in this case > since PAGE_SIZE is the most common data unit for FS. > > Cc: Vivek Goyal <vgoyal@redhat.com> > Reported-by: Pei Zhang <pezhang@redhat.com> > Signed-off-by: Ming Lei <ming.lei@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Vivek > --- > drivers/block/loop.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/block/loop.c b/drivers/block/loop.c > index b1b05c45c07c..8c15bfab7e1a 100644 > --- a/drivers/block/loop.c > +++ b/drivers/block/loop.c > @@ -776,6 +776,10 @@ static void loop_config_discard(struct loop_device *lo) > } else { > max_discard_sectors = UINT_MAX >> 9; > granularity = inode->i_sb->s_blocksize; > + > + /* Take PAGE_SIZE if the FS doesn't provide us one hint */ > + if (!granularity) > + granularity = PAGE_SIZE; > } > > if (max_discard_sectors) { > -- > 2.31.1 > ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <Ye6yE2Ephyv+WBYY@infradead.org>]
* Re: [PATCH] block: loop: set discard_granularity as PAGE_SIZE if sb->s_blocksize is 0 [not found] ` <Ye6yE2Ephyv+WBYY@infradead.org> @ 2022-01-24 15:22 ` Vivek Goyal 0 siblings, 0 replies; 2+ messages in thread From: Vivek Goyal @ 2022-01-24 15:22 UTC (permalink / raw) To: Christoph Hellwig Cc: Ming Lei, Jens Axboe, linux-block, Pei Zhang, Miklos Szeredi, linux-unionfs On Mon, Jan 24, 2022 at 06:05:07AM -0800, Christoph Hellwig wrote: > On Mon, Jan 24, 2022 at 06:06:28PM +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. > > > > Fix the issue by setting discard_granularity as PAGE_SIZE in this case > > since PAGE_SIZE is the most common data unit for FS. > > sb->s_blocksize really does not mean anything. kstat.blksize might > be a better choice, even if it someimes errs on the too large side. [ CC linux-unionfs, Miklos ] This should work well for overlayfs too. I see it just passes the query to underlying filesystem and that should report optimal I/O size. On my overlayfs instance, I see. # stat -c '%o' foo.txt 4096 Vivek ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-01-24 15:22 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20220124100628.1327718-1-ming.lei@redhat.com> 2022-01-24 13:36 ` [PATCH] block: loop: set discard_granularity as PAGE_SIZE if sb->s_blocksize is 0 Vivek Goyal [not found] ` <Ye6yE2Ephyv+WBYY@infradead.org> 2022-01-24 15:22 ` Vivek Goyal
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).