[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5775cbb-bd2a-decf-ad81-a861d796e3fe@gmail.com>
Date: Wed, 10 Aug 2022 19:00:00 +0800
From: Zhang Boyang <zhangboyang.id@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
linux-block@...r.kernel.org,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Jan Kara <jack@...e.cz>, Ming Lei <ming.lei@...hat.com>,
Chaitanya Kulkarni <kch@...dia.com>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/1] loop: introduce LO_FLAGS_NO_DEALLOC
Hi,
On 2022/8/10 06:19, Darrick J. Wong wrote:
>
> Considering that discard isn't required to do anything, why not
> echo 0 | sudo tee /sys/block/loopX/queue/discard_max_bytes ?
>
Thanks for reviewing! This will disable discard completely (>=5.19),
thus the filesystem of backing file has no knowledge about what can be
freed. In contrast, my patch convert REQ_OP_DISCARD to
FALLOC_FL_ZERO_RANGE, the discarded parts of backing file is flagged
zeroed. So there is possibility for the filesystem of backing file to
discard (trim) the zeroed range, improving the write performance on, for
example, SSDs.
However, it seems only XFS with realtime discard enabled can do trim on
FALLOC_FL_ZERO_RANGE. All other filesystems (and XFS without realtime
discard) can't do trim on extents flagged zeroed. Batch discard like
FITRIM (used by `fstirm' tool) also can't help here, because no
filesystem track `allocated but flagged zeroed' extents at filesystem
level. I will probably write another patch to add the ability to trim
zeroed extents in single file to FITRIM. (Currently, FITRIM work on
filesystem level, not file level)
Best Regards,
Zhang Boyang
Powered by blists - more mailing lists