]> git.karo-electronics.de Git - karo-tx-linux.git/commit
f2fs: remove reusing any prefree segments
authorJaegeuk Kim <jaegeuk.kim@samsung.com>
Thu, 27 Jun 2013 00:59:40 +0000 (09:59 +0900)
committerJaegeuk Kim <jaegeuk.kim@samsung.com>
Thu, 27 Jun 2013 00:59:40 +0000 (09:59 +0900)
commit796a466b8925b8482d0e34c02760ecbac98a1532
tree4588fcb84b11e97a33dc3b75908dc6b0fccc735b
parent5dfc2290ccfbebf335446209aa728082ba57b194
f2fs: remove reusing any prefree segments

This patch removes check_prefree_segments initially designed to enhance the
performance by narrowing the range of LBA usage across the whole block device.

When allocating a new segment, previous f2fs tries to find proper prefree
segments, and then, if finds a segment, it reuses the segment for further
data or node block allocation.

However, I found that this was totally wrong approach since the prefree segments
have several data or node blocks that will be used by the roll-forward mechanism
operated after sudden-power-off.

Let's assume the following scenario.

/* write 8MB with fsync */
for (i = 0; i < 2048; i++) {
offset = i * 4096;
write(fd, offset, 4KB);
fsync(fd);
}

In this case, naive segment allocation sequence will be like:
 data segment: x, x+1, x+2, x+3
 node segment: y, y+1, y+2, y+3.

But, if we can reuse prefree segments, the sequence can be like:
 data segment: x, x+1, y, y+1
 node segment: y, y+1, y+2, y+3.
Because, y, y+1, and y+2 became prefree segments one by one, and those are
reused by data allocation.

After conducting this workload, we should consider how to recover the latest
inode with its data.
If we reuse the prefree segments such as y or y+1, we lost the old node blocks
so that f2fs even cannot start roll-forward recovery.

Therefore, I suggest that we should remove reusing prefree segments.

Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
fs/f2fs/segment.c