Hi Duncan, I pretty much understand the risks and do not need them to be explained to me. When I installed the remote system, the versions where pretty close to the cutting edge. And the problem looks as if it *could* to be the same in 3.13 and in 4.4 kernels.
I wrote here to ask advice about "live" recovery *if* you have any, and to offer debug information *if* you interested. If you do not have advice for me, and are not interested in the sort of debug data that I *can* provide, so be it... Regards, Eugene On 07/02/2016 01:54 PM, Duncan wrote: > Eugene Crosser posted on Sat, 02 Jul 2016 12:49:53 +0300 as excerpted: > >> Enter the second system. It is a rented physical server in a datacenter >> with two hard disks, joined into a single root btrfs (/dev/sd[ab]1 are >> swap partitions): >> >> root@dehost:~# uname -a >> Linux dehost 3.13.0-91-generic [...] >> root@dehost:~# btrfs --version >> Btrfs v3.12 >> root@dehost:~# > > v3.12 userspace and v3.13 kernel are both ancient history in btrfs terms, > far too old to provide anything useful in terms of debugging info. > > In general, btrfs is not yet fully stable, and usage on the production > systems where that ancient a kernel and userspace might be considered for > stability reasons is considered highly incompatible with that sort of an > interest in stability at the cost of new features, because btrfs itself > isn't anything close to that level of stable. So the general > recommendation is choose one, either the still stabilizing btrfs on a > more current system if you want btrfs, or something truly stable, if you > really need that sort of years outdated stability. > > That said, while this list does tend to focus on mainline and the last > two mainline releases series of the current and LTS kernels, so ATM 4.6 > and 4.5 for current and 4.4 and 4.1 for LTS, not really much earlier, we > recognize that various distros do backporting and support much further > back. But this list tracks mainline, not those distro kernels, and > specifically, we don't track what they've backported vs. what they > haven't. So if you wish to use your distro's old kernels, that's fine, > but you're going to be better off going to them for support then, because > they'll know what they've backported and what they haven't and are thus > in a better position to provide that support. > > Meanwhile, I do recognize that you had something similar happen on a much > newer kernel as well, but that was on a different system, and you don't > have the details or logs left for that one, so that's not of much help > either. > > Unless of course you can duplicate the behavior once again with a > reasonably current kernel within the two-release series either LTS or > current range, as specified above, and can provide the logs, etc, from > it... >
signature.asc
Description: OpenPGP digital signature
