Re: btrfs-image run time
On Mon, Mar 07, 2016 at 07:15:24PM +0100, Garmine 42 wrote: > According to the manpage duplicate -s is valid and the high CPU usage is > intended. Although a warning could be valid in case of -ss. Or use a different letter. Anyway, that was my stupidity and no developer time should be wasted for that. btrfs-image behaves as documented, everything else was a problem existing between chair and keyboard. Sorry for the noise. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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
Re: btrfs-image run time
On Mon, Mar 07, 2016 at 11:09:57AM -0700, Chris Murphy wrote: > On Mon, Mar 7, 2016 at 10:38 AM, Marc Haber> wrote: > > On Mon, Mar 07, 2016 at 06:27:17PM +0100, Marc Haber wrote: > >> how long is btrfs-image taking to run on a 400 GiB filesystem? > >> > >> I have /bin/btrfs-image -s -t 8 -s /dev/mapper/mydevice - | pixz -9 > > >> file.on.other.fs running for four hours now > > > > Strike my question please, I didn't see that I had the -s doubled. > > With one -s I now see actual progress. > > Could be worth a bug report and a patch to keep it from using > duplicate switches. No, the duplicate -s is a valid part of the API. One -s will replace the filenames with random data. A second one will attempt to find a replacement name that matches the CRC32 hash of the filename. That's why it takes so long. Hugo. -- Hugo Mills | What do you give the man who has everything? hugo@... carfax.org.uk | Penicillin is a good start... http://carfax.org.uk/ | PGP: E2AB1DE4 | signature.asc Description: Digital signature
Re: btrfs-image run time
On Mon, Mar 7, 2016 at 10:38 AM, Marc Haberwrote: > On Mon, Mar 07, 2016 at 06:27:17PM +0100, Marc Haber wrote: >> how long is btrfs-image taking to run on a 400 GiB filesystem? >> >> I have /bin/btrfs-image -s -t 8 -s /dev/mapper/mydevice - | pixz -9 > >> file.on.other.fs running for four hours now > > Strike my question please, I didn't see that I had the -s doubled. > With one -s I now see actual progress. Could be worth a bug report and a patch to keep it from using duplicate switches. -- Chris Murphy -- 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
Re: btrfs-image run time
On Mon, Mar 07, 2016 at 06:27:17PM +0100, Marc Haber wrote: > how long is btrfs-image taking to run on a 400 GiB filesystem? > > I have /bin/btrfs-image -s -t 8 -s /dev/mapper/mydevice - | pixz -9 > > file.on.other.fs running for four hours now Strike my question please, I didn't see that I had the -s doubled. With one -s I now see actual progress. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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
btrfs-image run time
Hi, how long is btrfs-image taking to run on a 400 GiB filesystem? I have /bin/btrfs-image -s -t 8 -s /dev/mapper/mydevice - | pixz -9 > file.on.other.fs running for four hours now, and it's constantly taking a single core, but is neither reading from the disk nor writing to its output. Is that expeced behavior? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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