On Tue, May 29, 2018 at 08:08:03PM +0300, Amir Goldstein wrote: > On Fri, May 11, 2018 at 1:41 PM, Eryu Guan <guaneryu@xxxxxxxxx> wrote: > > On Wed, May 09, 2018 at 07:22:48PM +0300, Amir Goldstein wrote: > >> On Wed, May 9, 2018 at 6:27 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > >> > Hi, > >> > > >> > Please find attached the V2 of the patch. Took care of Amir's comments > >> > from previous version. > >> > > >> > Add tests for metadata only copy up feature. > >> > > >> > Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx> > >> > >> Looks good. > >> > >> Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > > > > Thanks for the review! > > > >> > >> Just a note to Eryu - > >> > >> You may want to hold on to this test until metacopy is merged > >> or at least staged on Miklos' next branch. > > > > I'd wait for the patches hit Miklos' tree. > > > > Vivek, > > This test seems to fail with overlayfs-next on check_file_blocks(). > With ext4 underneath, blocks count is bigger than expected by 8 sectors. > With xfs+reflink the blocks check also fails with different actual nr of blocks. > > I think it is generally unreliable to try to compute nr of blocks > and fail the test if actual is different than computed. > Maybe just check that overlay nr blocks is as the actual lower nr of > blocks. Hi Amir, Ok, I will change test to only make sure lower blocks are same as overlay blocks for metacopy file. But something strange is happening on ext4. I create a file and do stat on that it reports 40 blocks. After sleeping for 10 seconds, it reports 32 blocks on same file. Is this expected? I run following bash script on ext4 and I can reproduce the issue. Is this a bug in ext4? Vivek !/bin/bash ext4file="/mnt/test-ext4/testfile.txt" rm $ext4file >> /dev/null 2>&1 echo "hello" >> $ext4file chmod 600 $ext4file xfs_io -c "falloc 0 16384" $ext4file stat $ext4file sleep 10 stat $ext4file -- 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
