On Wed, Jul 5, 2017 at 12:59 PM, Eryu Guan <eguan@xxxxxxxxxx> wrote:
> On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote:
>> Two tasks make a modification concurrently on two hardlinks of a large
>> lower inode. The copy up should be triggered by one of the tasks and the
>> other should be waiting for copy up to complete. Both copy up targets
>> should end up being upper hardlinks and both metadata changes should be
>> visible in both hardlinks.
>>
>> With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up
>
> So this will be fixed in 4.13-rc1 kernel?
It is fixed on current overlayfs-next branch. Yes.
>> +
>> +_do_cmd()
>
> I'd rename it to do_cmd for a local helper function.
>
sure
>> +{
>> + echo "`date +%T` $1..." >> $seqres.full
>> + eval "$1"
>> + echo "`date +%T` ...$1" >> $seqres.full
>> +}
>> +
>> +# Perform one modification on each hardlink (size and owner)
>> +_do_cmd "echo >> $SCRATCH_MNT/one" &
>> +#
>> +# When hardlinks are broken and overlayfs supports concurrent copy up,
>> +# $seqres.full will show that file two copy up started ~2s after file one
>> +# copy up started and ended ~2s after file one copy up ended.
>> +# With synchronized copy up of lower inodes, $seqres.full will show that
>> +# file two copy up ended at the same time as file one copy up.
>> +#
>> +sleep 2
>
> If the first copyup finished within 2 seconds, it's not a concurrent
> modification on the two hardlinks. Does that break the test assumption?
It will not be a race, plain 2 consequent copy ups, so not testing anything
special, but won't cause test to fail.
I am testing overlayfs with 2 underlying fs configurations:
1. xfs with clone support
2. ext4
With xfs clone up takes fraction of a second, the test is not really concurrent.
With ext4, on my laptop with SSD, the 500M copy up takes ~3 seconds,
which is quite close to the 2 seconds delay.
I increased the copy up file size to 1G and now first copy up takes ~6 seconds,
so there is more slack for the 2 sec delay, but still keeps the test 'quick'.
>
>> +_do_cmd "chown 100 $SCRATCH_MNT/two" &
>> +
>> +wait
>> +
>> +# Expect all hardlinks to show both metadata modifications
>> +for f in zero one two; do
>> + _ls_l -n $SCRATCH_MNT/$f | awk '{ print $2, $3, $5, $9 }' | _filter_scratch
>
> Better to comment on what are the 4 fields.
>
They show the metadata that was changes by chown and write.
Will add a comment.
Thanks,
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
