Thread (9 messages) 9 messages, 3 authors, 2011-01-25

Re: speed up group trim

From: <hidden>
Date: 2011-01-25 01:53:22

On 2011-01-24, at 06:39, Lukas Czerner wrote:
quoted
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help