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