Conversation
|
Would this work with subpage configurations (e.g. 4K subpage on Linux configured for 64K pages)? |
|
Also, out of curiosity, how did wind up in a situation where you needed 64K pages to work? |
dattobd failed in situation with 64k pages, such as #254. After I apply this patch, dattobd works well. |
I don't know the relationship between subpage and dattobd, this patch only used to fix the problem that aliengment between cow block and pagesize on sutuation with 64k pages. Could you please give me more tails about |
It might not be a problem anymore, but I recalled that some filesystems used to have their block size tied to page size and now don't (e.g. XFS, ext4), so aspects of the filesystem may be flipping between 64k and 4k. Empirically testing seems to imply this isn't an issue in modern kernels, so I'm inclined to say this is fine nowadays. |
dattobd built or tested to work with anything but 4k pages currently,4k cow blocks not always page aligned when page size is 64k, this patch add 64k PAGE_SIZE compatibility。
following is test result of this patch on system with 64k pagesize:
[root@localhost ~]# getconf PAGESIZE
65536
[root@localhost ~]# dbdctl setup-snapshot /dev/sda1 /mnt/.datto1 1
[root@localhost ~]# dd if=/dev/datto1 of=/tmp/sda1.img bs=1M
记录了1024+0 的读入
记录了1024+0 的写出
1073741824字节(1.1 GB,1.0 GiB)已复制,2.09144 s,513 MB/s
[root@localhost ~]# dd if=/dev/urandom of=/mnt/data bs=1M count=100
记录了100+0 的读入
记录了100+0 的写出
104857600字节(105 MB,100 MiB)已复制,0.394681 s,266 MB/s
[root@localhost ~]# dbdctl transition-to-incremental 1
[root@localhost ~]# dbdctl transition-to-snapshot /mnt/.datto2 1
[root@localhost ~]# update-img /dev/datto1 /mnt/.datto1 /tmp/sda1.img
snapshot is 262144 blocks large
copying blocks
copying complete: 25624 blocks changed, 0 errors
[root@localhost ~]# mount -o nouuid /tmp/sda1.img /tmp/X
[root@localhost ~]# md5sum /mnt/data
206ecf8bf19227ec78ef41970fe9e034 /mnt/data
[root@localhost ~]# md5sum /tmp/X/data
206ecf8bf19227ec78ef41970fe9e034 /tmp/X/data
[root@localhost ~]#