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. >>>>> Although no blocks need to be moved, the SUFILE entry of the >>>>> corresponding segment needs to be updated to avoid an infinite loop. >>>>> >>>>> This is potentially useful for all gc policies, but it is especially >>>>> beneficial for the timestamp policy. >>>> >>>> I completely misunderstand this statement. What do you mean? >>> >>> Well the timestamp policy always selects the oldest segment. If the >>> oldest segment is below the threshold it won't be cleaned. If we don't >>> change the timestamp it will be immediately selected again and it >>> probably will still be below the threshold and so on in an infinite loop. >> >> I understand your approach. But I misunderstand about what usefulness >> you are talking. What is it? >> > > It helps to avoid unnecessary copy operations of data. Ok. But how your implementation and approach can be used for timestamp policy implementation? Is it possible to combine GC policies into hybrid one? Thanks, Vyacheslav Dubeyko. -- 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
