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] [day] [month] [year] [list]
Date:	Mon, 24 Jan 2011 18:53:21 -0700
From:	tm@....ma
To:	"Andreas Dilger" <adilger.kernel@...ger.ca>
Cc:	"Lukas Czerner" <lczerner@...hat.com>, "Tao Ma" <tm@....ma>,
	linux-ext4@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>
Subject: Re: speed up group trim

> On 2011-01-24, at 06:39, Lukas Czerner wrote:
>>> I don't know either. But that is the user's choice of 'minlen' and we
>>> can't
>>> provent them from doing like that.
>>>
>>> Here is a scenario:
>>> 1. run with minlen=1mb, he got that only 1G get trimmed. but the free
>>> space is
>>> more than 3gb actually because of the fragmentation.
>>> 2. So he decide to run with minlen=512kb or even smaller len to see
>>> whether
>>> more space can be trimmed.
>>>
>>> Is it possible? I guess the answer is yes.
>>
>> Hi,
>>
>> I think that this is actually quite useful *feature*. I can imagine that
>> people might want to run FITRIM with bigger minlen (megabytes or tens of
>> megabytes) weekly, as it is much faster, especially on fragmented
>> filesystem. Then, they might want to run FITRIM with smaller minlen
>> (4kB)
>> monthly to reclaim even the smaller (or all of them) extents.
>>
>> But I like Andreas' idea, it should improve FITRIM performance
>> significantly (since we are doing mkfs trim). Minlen can be stored in
>> high bits of bb_state as number of blocks.
>
> I'd rather just add a proper field in ext4_group_info to store the length.
>  I don't think this will change the actual memory usage, since this is
> already a fairly large and odd-sized structure.
yeah, a proper field should be fine.
First, we don't store it in the disk, so we don't care for the layout
compatibility problem.
Second, we don't have much group in the volume. So a new field wouldn't
cost much for us like inodes.

Regards,
Tao

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

Powered by blists - more mailing lists