]> Pileus Git - ~andy/linux/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>
Mon, 1 Jul 2013 23:48:15 +0000 (08:48 +0900)
commit763bfe1bc575dcce56dc5c570dc005d94911705f
tree4588fcb84b11e97a33dc3b75908dc6b0fccc735b
parent6cc4af56066d8e9c62584cf61c6ce50fd0ab139a
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