aboutsummaryrefslogtreecommitdiff
path: root/lib/libcrc32c.c
diff options
context:
space:
mode:
authorJaegeuk Kim2013-06-27 09:59:40 +0900
committerJaegeuk Kim2013-07-02 08:48:15 +0900
commit763bfe1bc575dcce56dc5c570dc005d94911705f (patch)
tree4588fcb84b11e97a33dc3b75908dc6b0fccc735b /lib/libcrc32c.c
parent6cc4af56066d8e9c62584cf61c6ce50fd0ab139a (diff)
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>
Diffstat (limited to 'lib/libcrc32c.c')
0 files changed, 0 insertions, 0 deletions