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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ