On Mon, Apr 18, 2016 at 4:26 PM, Roman Mamedov <r...@romanrm.net> wrote: > On Mon, 18 Apr 2016 16:13:28 +0200 > Henk Slager <eye...@gmail.com> wrote: > >> (your email keeps ending up in gmail spam folder) >> >> On Mon, Apr 18, 2016 at 9:24 AM, sri <toyours_srid...@yahoo.co.in> wrote: >> > I tried btrfs-image and created image file and ran btrfs-image -r to a >> > different disk. Once recovered and mounted, I can able to see data is >> > not zeroed out as mentioned in btrfs-image man page. >> >> "different disk" you mention, that is important info. If you doe the >> restore to a image file, that image file is sparse and all data blocks >> are read as zeros. >> >> However, if you restore to a block device, then you can assume it just >> writes the device blocks for metadata and leaves the rest untouched. >> So trim whole device first or brute-force overwrite completely with >> zeros. >> >> So maybe the man pages needs some correction / extra notes. >> >> > I tried on same machine. > > Does btrfs-image store/restore the FS UUID? If it does, then potentially both > the source FS and the restored one were visible at the same time to the kernel > with identical UUIDs, and maybe it was actually accessing/mounting the source > one.
Very good point! The UUID's are the same. I remember I used a VM to separate the source FS from the restored FS Also, the assumption I made about restoring to a block device is not correct: If you restore to a loopdev that has a file with all non-zeros as backing-store, the files in the mounted restored FS are read as zeros. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
