Am Mittwoch, 16. November 2016, 07:57:08 CET schrieb Austin S. Hemmelgarn: > On 2016-11-16 06:04, Martin Steigerwald wrote: > > Am Mittwoch, 16. November 2016, 16:00:31 CET schrieb Roman Mamedov: > >> On Wed, 16 Nov 2016 11:55:32 +0100 > >> > >> Martin Steigerwald <martin.steigerwald@xxxxxxxxx> wrote: […] > > As there seems to be no force option to override the limitation and I > > do not feel like compiling my own btrfs-tools right now, I will use rsync > > instead. > > In a case like this, I'd trust rsync more than send/receive. The > following rsync switches might also be of interest: > -a: This turns on a bunch of things almost everyone wants when using > rsync, similar to the same switch for cp, just with even more added in. > -H: This recreates hardlinks on the receiving end. > -S: This recreates sparse files. > -A: This copies POSIX ACL's > -X: This copies extended attributes (most of them at least, there are a > few that can't be arbitrarily written to). > Pre-creating the subvolumes by hand combined with using all of those > will get you almost everything covered by send/receive except for > sharing of extents and ctime. I usually use rsync -aAHXSP already :). I was able to rsync any relevant data of the disk which is now being deleted by shred command. Thank you, -- Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
