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:34:37 -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 20/04/10 04:24 PM, Mark Lord wrote:
> 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!
..

Ahh. here it is/was:

On August 17, 1009, Mark Lord wrote:
> Taking care of mounted RAID / LVM filesystems requires in-kernel TRIM
> support, possibly exported via an ioctl().
>
> Taking care of unmounted RAID / LVM filesystems is possible in userland,
> but would also benefit from in-kernel support, where layouts are defined
> and known better than in userland.
>
> The XFS_TRIM was an idea that Cristoph floated, as a concept for examination.
>
> I think something along those lines would be best, but perhaps with an
> interface at the VFS layer.  Something that permits a userland tool
> to work like this (below) might be nearly ideal:
>
> main() {
>     int fd = open(filesystem_device);
>     while (1) {
>         int g, ngroups = ioctl(fd, GET_NUMBER_OF_BLOCK_GROUPS);
>         for (g = 0; g < ngroups; ++g) {
>             ioctl(fd, TRIM_ALL_FREE_EXTENTS_OF_GROUP, g);
>         }
>         sleep(3600);
>     }
> }
>
> Not all filesystems have a "block group", or "allocation group" structure,
> but I suspect that it's an easy mapping in most cases.
>
> With this scheme, the kernel is absolved of the need to track/coallesce
> TRIM requests entirely.
>
> Something like that, perhaps.
>
>
--
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