On 2011-01-24, at 06:39, Lukas Czerner wrote:

quoted

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.

quoted

quoted

quoted

quoted

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@vger.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Cheers, Andreas