linux-ext4 - Re: Ext4: batched discard support

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 20 Apr 2010 16:24:43 -0400
From:	Mark Lord <kernel@...savvy.com>
To:	Greg Freemyer <greg.freemyer@...il.com>
CC:	Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org,
	Jeff Moyer <jmoyer@...hat.com>,
	Edward Shishkin <eshishki@...hat.com>,
	Eric Sandeen <esandeen@...hat.com>,
	Ric Wheeler <rwheeler@...hat.com>, Mark Lord <liml@....ca>
Subject: Re: Ext4: batched discard support

On 19/04/10 12:20 PM, Greg Freemyer wrote:
> Adding Mark Lord in cc.
..
> On Mon, Apr 19, 2010 at 6:55 AM, Lukas Czerner<lczerner@...hat.com>  wrote:
..
>> The basic idea behind my discard support is to create an ioctl which
>> walks through all the free extents in each allocating group and discard
>> those extents. As an addition to improve its performance one can specify
>> minimum free extent length, so ioctl will not bother with shorter extents.
..

Perfect.  I proposed exactly this last year, but never found time to work it further.
Please proceed with it!

..
>> But you may notice, that there is one problem. bb_bitmap_deleted does
>> not survive umount. To bypass the problem the first ioctl call have to
>> walk through whole file system trimming all free extents. But there is a
>> better solution to this problem. The bb_bitmap_deleted can be stored on
>> disk an can be restored in mount time along with other bitmaps, but I
>> think it is a quite big change and should be discussed further.
..

That's not necessary.  It is a simple matter to TRIM a clean filesystem
before it is mounted R/W during the boot sequence.  No new information
is required for that operation.

My wiper.sh script already shows walking the freelists and trimming all
available space, something which takes only a couple of seconds on a 120GB
filesystem that has not been kept up-to-date with on-the-fly trim.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html