Mordechay Kaganer posted on Fri, 29 Jul 2016 16:37:05 +0300 as excerpted: > While saving a backup (using rsync) the FS went read only and i've got > BTRFS: Transaction aborted (error -28) error. While writing a new backup > i was also doing btrfs send of another subvolume on the same FS from > this server out to another server. > > After reboot, the device mounts OK. Does it mean something went wrong > with the FS? Need to run a full balance?
Because btrfs is designed to be copy-on-write, with atomic transactions, an aborted transaction /should/ leave you with a consistent filesystem, simply lacking whatever changes would have occurred in that transaction. 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. If those both come out fine it was probably simply stress from the rsync and the send at the same time. Rsync in particular is known to be intensive enough to be a reasonable real-world stress test for btrfs, and has in fact flushed out a number of bugs over the years that people didn't see in otherwise normal usage. Combining it with send of course amplifies the stress on the filesystem, such that if bugs are going to show up, and btrfs isn't yet fully stable and mature so that's expected, combining rsync with pretty much anything else intensive as well is likely to flush them out. > btrfs-tools version: btrfs-progs v4.3.1 > > The kernel is based on Ubuntu mainline PPA 4.3.3 > (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3.3-wily/) with a > patch to fix RAID10 issue. FWIW, kernel 4.3 is no longer really recommended or supported well on this list. The list recommendation is the last two kernels series in either the LTS or current channels. The last two upstream LTS series are 4.4 and 4.1. The latest current kernel is of course 4.7, so 4.7 and 4.6 would be supported there. Of course distros can and do choose other kernel series to support, and you may choose to go with them and their support instead, but if so, you really should be getting support from them, because they are tracking what patches they've backported, while this list is generally focused on mainline and won't know what distros have backported, and because the focus is on moving forward, we only generally support the two current kernel series, plus the two current LTS series for those who don't want to be upgrading to a new kernel series every couple months. During normal operation, userspace (btrfs-progs) is less important as most commands simply call the kernel code to do the real work. However, once something goes wrong and you're trying to recover, it's mostly userspace code, and the newer versions are better positioned to fix more problems, so they're recommended then. Plus, as the commands and their output are still changing from time to time, get too old and the commands and output are different enough it's hard to compare. So a good rule of thumb is to at least match your kernel x.y version, tho newer is fine. That way, provided you're following the kernel recommendations, you're assured of a reasonably current btrfs userland as well. 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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
