Re: btrfs ops hang indefinitely (process in D state)

[Eugene Crosser <crosser@average.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2916 bytes --]

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...
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]