linux-kernel - Re: [PATCH V2 1/1] loop: introduce LO_FLAGS_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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