Re: [PATCH v2 0/5] nilfs-utils: skip inefficient gc operations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 25 Jan 2014 19:33:42 +0300, Vyacheslav Dubeyko wrote:
> 
> On Jan 24, 2014, at 5:18 PM, Andreas Rohner wrote:
> 
>>>> You have to move the live blocks to a new segment, so you gain only (8
>>>> MB - live_blocks) of free space.
>>> 
>>> You always will have 8 MB after cleaning (garbage collection).  So, all segments
>>> are identical from the free space point of view. What does GC check? And how
>>> can GC distinguish segments on the basis of free space? All cleaned segments
>>> return 8 MB free space for further allocation. So, all used segments will be over
>>> any threshold.
>> 
>> I am sorry if I wasn't clear enough. The invalidated blocks in a segment
>> are basically unusable free space, that needs to be garbage collected.
>> If you clean a segment you only gain the space of the invalidated
>> blocks, from the perspective of the whole file system. Of course the
>> whole segment is free after cleaning, but the live blocks were moved
>> somewhere else and occupy space there. So from the perspective of the
>> whole file system you only really gained the amount of space occupied by
>> the invalidated blocks.
>> 
> 
> I suggest not to use "free blocks" term for the case of invalidated blocks.
> Because it is really confusing way. I suppose that we can use term
> "invalid blocks" or "dead blocks". But I think that "dead blocks" is not
> good way too. Because, from my point of view, invalidated blocks are
> blocks that keep previous state of actual blocks. Dead block sounds for
> me likewise unusable or bad block.

"free blocks" term sounds confusing.  We often use terms
"live" and "dead" for garbage collection, but "dead blocks" also
sounds unfit to me as Vyacheslav pointed out.

How about "min reclaimable blocks" or "min collectable blocks" ?

Regards,
Ryusuke Konishi

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux BTRFS]     [Linux CIFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux