%
daily.
Sometimes I can work around the issue by deleting the offending snapshot (I get
hangs that require a hard reboot during the backup process) and retrying.
-BJ Quinn
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord
benefit from parallelism
if it were at all reasonably possible to do so. I'm surprised ANY
compression method could really tax modern hardware to that extent.
-BJ
- Original Message -
From: Xavier Bassery xav...@bartica.org
To: BJ Quinn b...@placs.net
Cc: ps...@cfl.rr.com, Jan Schmidt
it incorrectly).
Thanks in advance for your help!
-BJ
- Original Message -
From: Jan Schmidt m...@jan-o-sch.net
To: BJ Quinn b...@placs.net
Cc: Jan Schmidt list.bt...@jan-o-sch.net, linux-btrfs@vger.kernel.org,
ps...@cfl.rr.com, Freddie Cash fjwc...@gmail.com
Sent: Tuesday, July 30, 2013
, July 29, 2013 3:21:51 AM
Hi BJ,
[original message rewrapped]
On Thu, July 25, 2013 at 18:32 (+0200), BJ Quinn wrote:
(Apologies for the double post -- forgot to send as plain text the first time
around, so the list rejected it.)
I see that there's now a btrfs send / receive and I've tried
[a03be4cd]
ulist_add_merge+0x2d/0x190 [btrfs]
Jul 24 18:46:48 foxserver8 kernel: RSP 880beebaf958
Jul 24 18:46:48 foxserver8 kernel: ---[ end trace a30ba65210ac4804 ]---
-BJ
- Forwarded Message -
From: Jan Schmidt list.bt...@jan-o-sch.net
To: BJ Quinn b...@placs.net
Cc
Now I've managed to basically bring my system to its knees. My rsync script
that takes weeks ends up bringing the system to a crawl long before it can ever
finish. I end up with 100% of the CPU used up by the following as shown by top
btrfs-endio-wri
btrfs-delayed-m
btrfs-transacti
Actually, I seem to be having problems where my rsync script ends up hanging
the system again. It's pretty repeatable, and the system is completely frozen
and I have to do a hard reboot. Runs for a couple of hours and hangs the
system every time. Of course, I'm not doing anything special
No, btrfs send is exactly what you need. Using dd is slow because it
copies unused blocks, and requires the source fs be unmounted and the
destination be an empty partition. rsync is slow because it can't take
advantage of the btrfs tree to quickly locate the files (or parts of
them) that have
At any rate, was someone saying that some work had already started on
something like btrfs send?
That's right.
Google tells me that someone is you. :)
What Google wouldn't tell me though was whether you have something I could test?
-BJ
--
To unsubscribe from this list: send the line
As soon as there's something that can be tested, you'll find it on this list.
Great, I'd love to try it. I spent a lot of time with ZFS and the zfs
send/recv functionality was very convenient.
Meanwhile, does anyone know how I can change the UUID of a btrfs partition or
are there any other
Care to share you rsync script?
Sure. It's a little raw, and makes some assumptions about my environment, but
it does the job other than the fact that it takes weeks to run. :)
In the below example, the main or source FS is mounted at /mnt/btrfs, the
backup or target FS at
mount one or the other. This means I can't continue to
simply update the backup array with the new snapshots created on the main array
(my script is capable of catching up the backup array with the new snapshots,
but if I can't mount both arrays...).
Any suggestions?
-BJ Quinn
--
To unsubscribe
send was pretty slow too in a scenario like this. What I need
is to be able to clone a btrfs array somehow -- dd would be nice, but as I said
I end up with the identical UUID problem. Is there a way to change the UUID of
an array?
-BJ Quinn
--
To unsubscribe from this list: send the line
13 matches
Mail list logo
