diff options
author | Jaegeuk Kim <jaegeuk.kim@samsung.com> | 2013-06-27 09:59:40 +0900 |
---|---|---|
committer | Jaegeuk Kim <jaegeuk.kim@samsung.com> | 2013-07-02 08:48:15 +0900 |
commit | 763bfe1bc575dcce56dc5c570dc005d94911705f (patch) | |
tree | 4588fcb84b11e97a33dc3b75908dc6b0fccc735b /fs/f2fs/recovery.c | |
parent | 6cc4af56066d8e9c62584cf61c6ce50fd0ab139a (diff) | |
download | op-kernel-dev-763bfe1bc575dcce56dc5c570dc005d94911705f.zip op-kernel-dev-763bfe1bc575dcce56dc5c570dc005d94911705f.tar.gz |
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 'fs/f2fs/recovery.c')
0 files changed, 0 insertions, 0 deletions