You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe I've found a crash consistency bug that can be triggered by a crash while using truncate() to reduce file size. I found it by starting with a new, empty file system, creating a file under the root directory, writing 4KB to the file, then truncating the file's size to 0. The bug prevents the file system from being mounted.
Specifically, the bug occurs if the system crashes after adding the inode's number to the truncate list in pmfs_truncate_add() in inode.c and before the inode's root pointer, number of blocks, etc. are updated. When the system is mounted again, it attempts to finish up the truncate operation on the inode. I believe issue arises from the fact that this operation relies on a list of in-use blocks (stored in the pmfs_sb_info struct with the block_inuse_head` pointer), which lives in DRAM. This list is not rebuilt until AFTER recovery attempts to finish truncation, so the truncate functions can't access it. Ultimately the bug is triggered by an assertion on line 70 of balloc.c that checks whether the in-use list is empty.
I think this bug can be fixed by swapping the functions that recover the truncate list and rebuild the DRAM structures in pmfs_fill_super, although I am not sure yet that this fix wouldn't introduce any other bugs.
The text was updated successfully, but these errors were encountered:
Hi,
I believe I've found a crash consistency bug that can be triggered by a crash while using
truncate()
to reduce file size. I found it by starting with a new, empty file system, creating a file under the root directory, writing 4KB to the file, then truncating the file's size to 0. The bug prevents the file system from being mounted.Specifically, the bug occurs if the system crashes after adding the inode's number to the truncate list in
pmfs_truncate_add()
in inode.c and before the inode's root pointer, number of blocks, etc. are updated. When the system is mounted again, it attempts to finish up the truncate operation on the inode. I believe issue arises from the fact that this operation relies on a list of in-use blocks (stored in thepmfs_sb_info
struct with the block_inuse_head` pointer), which lives in DRAM. This list is not rebuilt until AFTER recovery attempts to finish truncation, so the truncate functions can't access it. Ultimately the bug is triggered by an assertion on line 70 of balloc.c that checks whether the in-use list is empty.I think this bug can be fixed by swapping the functions that recover the truncate list and rebuild the DRAM structures in
pmfs_fill_super
, although I am not sure yet that this fix wouldn't introduce any other bugs.The text was updated successfully, but these errors were encountered: