search

NVSL / linux-nova

NOVA is a log-structured file system designed for byte-addressable non-volatile memories, developed at the University of California, San Diego.
http://nvsl.ucsd.edu/index.php?path=projects/nova
Other
422 stars 117 forks source link

DEntry is staill visible after unlink and rmdir in case of crashes #148

Open iaoing opened 6 months ago

iaoing commented 6 months ago

Issue

In unlink and rmdir, NOVA will append a new DIR_LOG and reassign create_dentry if the creation and removal epoches differ. If the system crashes before invalidating (reassigning) the dentry, after recovery, the dentry will be considered a valid dentry and seen by users but the removed inode has been gone.

NOTE: This issue could be occurred in other circumstances. After fixing the atomicity bug in rename (https://github.com/NVSL/linux-nova/pull/135), this bug occurs. This is because rename appends a new entry for detecting a dentry instead of updating it in-place, triggering the reassignment of the creation entry.

After fixing the issue #125 by disabling the in-place update of the log in unlink, this bug will occur without creating snapshots. This is because the invalidation of the dentry will not be triggered if NOVA in-place updates the log to represent the removal. After the fix, NOVA never in-place updates the log, so that, the invalidation is required, leading to this bug.

Reproduce

  1. Modify the source code in nova_unlink to simulate a crash. https://github.com/NVSL/linux-nova/blob/976a4d1f3d5282863b23aa834e02012167be6ee2/fs/nova/namei.c#L459-L460
    nova_invalidate_link_change_entry(sb, old_linkc);
    goto out; // simulate a crash before reassigning the dentry
    nova_invalidate_dentries(sb, &update_dir);
  1. The commands 
    insmod nova.ko metadata_csum=1 data_csum=1 data_parity=1
mount -t NOVA -o init,dbgmask=255 /dev/pmem0 /mnt/pmem0
# create a file
touch /mnt/pmem0/f1
# create and delete a snapshot to increase epochs
echo 1 > /proc/fs/NOVA/pmem0/create_snapshot
echo 0 > /proc/fs/NOVA/pmem0/delete_snapshot
# unlink the file
rm /mnt/pmem0/f1
# cat the image then umount
cat /dev/pmem0 > image
umount /mnt/pmem0
# remount
cat image > /dev/pmem0
mount -t NOVA -o dbgmask=255 /dev/pmem0 /mnt/pmem0
# ls can see the dentry, f1
ls /mnt/pmem0
# stat will arise an error, "stat: cannot stat '/mnt/pmem0/f1': No such file or directory"
stat /mnt/pmem0/f1

Testing the rmdir function has the similar reproduce process.

Reason

The reassignment of the dentry is non-synchronous OR The recovery process cannot distinguish whether the reassignment is unfinished.

Fix

There might be different ways to fix this bug. However, I have not tried any of them yet. Besides, the reassign flag is designed for snapshots, I do not whether this fix affects the design.

Option 1. Since the snapshots have been deleted, it should be safe to in-place update the dentry in unlink and rmdir. Option 2. Journal the reassignment process. Option 3. In recovery, when seeing a dentry is deleted, search backward to continue the unfinished reassign process.