On Thu, Jan 12, 2017 at 03:13:37AM +0000, [email protected] wrote: > From: Filipe Manana <[email protected]> > > Test that an incremental send operation works after moving a directory > into a new parent directory, deleting its previous parent directory and > creating a new inode that has the same inode number as the old parent. > > This issue is fixed by the following patch for the linux kernel: > > "Btrfs: incremental send, do not delay rename when parent inode is new" > > Signed-off-by: Robbie Ko <[email protected]> > Signed-off-by: Filipe Manana <[email protected]>
I tested this patchset with/without proposed kernel patches, all tests worked as expected. Just one tiny update on commit below. > --- > +# Remount the filesystem so that the next created inodes will have the > numbers > +# 258 and 259. This is because when a filesystem is mounted, btrfs sets the > +# subvolume's inode counter to a value corresponding to the highest inode > number > +# in the subvolume plus 1. This inode counter is used to assign a unique > number > +# to each new inode and it's incremented by 1 after very inode creation. > +# Note: we unmount and then mount instead of doing a mount with "-o remount" > +# because otherwise the inode counter remains at value 260. > +_scratch_unmount > +_scratch_mount I replaced these with _scratch_cycle_mount. Thanks, Eryu -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
