Re: Bug: btrfs dev del missing fails where it shouldn't

[Duncan <1i5t5.duncan@cox.net>]

Karoly Pados posted on Mon, 27 Mar 2017 14:12:58 +0000 as excerpted:

>> But, even there, a close read says missing tells btrfs to delete the
>> first device described by the filesystem metadata that wasn't present
>> when the filesystem was mounted. And since your case does a remount,
>> not a full unmount and clean mount, that "missing" device was present
>> when the filesystem was mounted, so attempting to delete missing
>> /should/ be expected to fail.
> 
> I checked, and a full unmount+mount instead of a remount makes 'missing'
> work for me as expected. Thank you once more. Here though I have a (IMHO
> important) feature suggestion: make 'missing' behave the same after a
> remount as after a full-unmount-mount. And though I have no specific
> example yet, possibly other features too aside from 'missing'. For a
> simple reason:
> 
> Even if you describe 'missing' as "delete the first device described by
> the filesystem metadata that wasn't present when the filesystem was
> mounted", no normal admin or user is going to interpret it that way. You
> are right the info is in there, and kernel or btrfs devs will take that
> sentence apart like lawyers and interpret it very exactly. But I dare to
> say that most admins think of remount as unmount-mount-on-steroids,
> basically as a possibly atomic unmount+mount that does not break file
> descriptors. My point is, I argue that most people will expect 'missing'
> to work after a remount even after reading its correct description
> above. So I would either explicitly spell out in the docs that 'missing'
> will not work in that case, or better, 'fix' it to work even after a
> remount.

FWIW...

I absolutely agree with you on how an admin would take delete missing, as 
I'd definitely expect it to work that way myself.  =:^/  Only after 
having it fail would I be trying to figure out why, and presumably would 
come across that "at mount" wording and smack myself upside the head, 
"Oh, OK, I can deal with that!"

Unfortunately, I suspect the change at least short term will have to be 
spelling it out explicitly in the docs, as btrfs as it currently is 
really doesn't have the concept of a device going MIA, missing in action, 
and will simply continue to try to write to it, filling memory with 
unwritten data...  IOW, the "missing" thing isn't the only or even the 
most critical issue with btrfs not really detecting device presence or 
absence except on mount.

There are longer-term-project patches to change that and make btrfs aware 
of device changes, but AFAIK, they're moldering in a developer's branch 
somewhere (the global hot-spare patches branch), and when they'll 
actually be polished up and mainlined is I believe unknown, ATM.  
Certainly I don't know, tho Chris Mason and the dev in question might 
have some general idea.

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