linux-ext4 - Re: speed up group trim

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:	Mon, 24 Jan 2011 11:51:36 -0700
From:	Andreas Dilger <adilger.kernel@...ger.ca>
To:	Lukas Czerner <lczerner@...hat.com>
Cc:	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.

>>>>> Something like:
>>>>> 
>>>>> #define EXT4_GROUP_INFO_NEED_TRIM_BIT	1
>>>>> 
>>>>> /* Note that bit clear means a trim is needed, so that a newly mounted
>>>>> * filesystem assumes that holes the group need to be trimmed. */
>>>>> #define EXT4_MB_GRP_NEED_TRIM(grp)	\
>>>>> 	(!test_bit(EXT4_GROUP_INFO_NEED_INIT_BIT,&((grp)->bb_state)))
>>>>> 
>>>>> 
>>>>> When calling the TRIM ioctl it can check EXT4_MB_GRP_NEED_TRIM(grp) and
>>>>> skip that group if it hasn't changed since last time.  Otherwise, it
>>>>> should call EXT4_MB_GRP_DONE_TRIM(grp) before doing the actual trim, so
>>>>> it is not racy with another process freeing blocks in that group.
>>>>> 
>>>>> In release_blocks_on_commit() it should call EXT4_MB_GRP_MUST_TRIM() to
>>>>> mark that the group needs to be trimmed again, since blocks were freed
>>>>> in the group.
>>>>> 
>>>>> This can potentially avoid a huge number of TRIMs to the disk, if this
>>>>> is run periodically (e.g. every day) and the filesystem is not remounted
>>>>> all the time, and does not undergo huge allocate/free/allocate cycles
>>>>> during daily use.
>>>>> 
>>>>> It would even be possible to store this bit on-disk
>>>>> ext4_group_desc->bg_flags to avoid the initial "assume every group needs
>>>>> to be trimmed" operation, if that ends up to be a significant factor.
>>>>> However, that can be done later once some numbers are measured on how
>>>>> significant the initial-mount overhead is.  It is also not free, since
>>>>> it will cause disk IO to set/clear this bit.
>>>>> 
>>>>> Cheers, Andreas
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 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
>>>> 
>>> 
>>> 
>>> Cheers, Andreas
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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
>> 
>> 
> 
> -- 


Cheers, Andreas





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