B.H. Thanks for the detailed answer!
On Fri, Jul 29, 2016 at 8:23 PM, Duncan <1i5t5.dun...@cox.net> wrote: > ... > Of course the fact that the transaction aborted /does/ indicate some sort > of problem, which may in fact have left the filesystem in an unknown > state. However, I'd recommend a couple other checks, not balance, to be > sure you're good. First, a btrfs scrub of the filesystem, just to be > sure the checksums all come out fine (or are fixable and fixed if not). > Second, a btrfs check, which will be read-only unless you add --repair or > similar option. OK, scrub finished with 0 errors so I assume the FS is probably in a good shape Regarding 'btrfs check' - my FS is huge and with a lot of metadata so btrfs check seems to consume a lot of RAM. I've added all of my system disk's free space as a swap but the check was killed due to OOM after consuming about 100GB of memory. > ... > So I'd recommend upgrading to the latest kernel 4.4 if you want to stay > with the stable series, or 4.6 or 4.7 if you want current, and then (less > important) upgrading the btrfs userspace as well. It's possible the > newer kernel will handle the combined rsync and send stresses better, and > if not, you're on a better base to provide bug reports, etc. OK, upgraded to 4.4 (Ubuntu 16.04 stock kernel) and the fresh btrfs-progs 4.7. I'm assuming the error was due to some kind of bug or race condition and the FS is clean. Let's see how it behaves. Thanks! -- משיח NOW! Moshiach is coming very soon, prepare yourself! יחי אדוננו מורינו ורבינו מלך המשיח לעולם ועד! -- 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
