Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e5775cbb-bd2a-decf-ad81-a861d796e3fe@gmail.com>
Date:   Wed, 10 Aug 2022 19:00:00 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: [PATCH V2 1/1] loop: introduce LO_FLAGS_NO_DEALLOC
Content-Language: en-US
To:     "Darrick J. Wong" <djwong@kernel.org>
Cc:     Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
        linux-block@vger.kernel.org,
        Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        Jan Kara <jack@suse.cz>, Ming Lei <ming.lei@redhat.com>,
        Chaitanya Kulkarni <kch@nvidia.com>,
        Damien Le Moal <damien.lemoal@opensource.wdc.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>,
        linux-kernel@vger.kernel.org
References: <20220806153022.83748-1-zhangboyang.id@gmail.com>
 <20220806153022.83748-2-zhangboyang.id@gmail.com> <YvLdc8GtbZ968qF6@magnolia>
From:   Zhang Boyang <zhangboyang.id@gmail.com>
In-Reply-To: <YvLdc8GtbZ968qF6@magnolia>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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