At Tue, 15 Jan 2019 22:53:17 +0900 (JST), HIRAKI Hideaki wrote: > Dear Qu, > > At Tue, 15 Jan 2019 20:55:38 +0800, Qu Wenruo wrote: >> On 2019/1/15 7:47, HIRAKI Hideaki wrote: <snip> >>> The second question is about btrfs-restore. It doesn't restore subvolumes >>> even when the destination path is in a BTRFS file system. >> >> I had a plan to support snapshot/subvolume creation for btrfs-restore if >> destination is btrfs, or supports reflink. >> >> But that feature will be too late for your use case anyway. >> >>> "btrfs restore -l" >>> is to list subvolumes but the output lacks the path (relative to the top >>> level subvolume) information. >> >> You could try my experimental patch: >> https://patchwork.kernel.org/patch/10738583/ >> >> It provides kernel equivalent of btrfs-restore, using 'ro,skip_bg' mount >> option. >> >> If everything goes OK, then you should be able to get 'btrfs subv list' >> working. >> > > I'll try this later.
With the patch, 'btrfs subv list' worked! Thank you very much. As the read-only mount was succeeded, I thought btrfs-send/receive might be useful, but it didn't work because the subvolume was NOT read-only. Your plan to improve btrfs-restore is just awesome. Apparently 7 files (ERROR: cannot map block logical ...) and 88 directories (Reached the end of the tree searching the directory) couldn't be restored. I'll move to docker's side to see what were lost. Regards, Hideaki
