On 2015-09-22 08:51, Qu Wenruo wrote:
>
>
> 在 2015年09月22日 19:32, Austin S Hemmelgarn 写道:
>> On 2015-09-21 16:35, Erkki Seppala wrote:
>>> Gareth Pye <gareth@cerberos.id.au> writes:
>>>
>>>> People tend to be looking at BTRFS for a guarantee that data doesn't
>>>> die when hardware does. Defaults that defeat that shouldn't be used.
>>>
>>> However, data is no more in danger at startup than it is at the moment
>>> when btrfs notices a drive dropping, yet it permits IO to proceed. Is
>>> there not a contradiction?
>>>
>>> Personally I don't see why system startup should be a special case, in
>>> particular as it can be very stressful situation to recover from when
>>> RAID is there just to avoid the immediate reaction when hardware breaks;
>>> and when in practice you can do the recovery while the system is running
>>> in systems where short service interruptions matter.
>>>
>> The difference is that we have code to detect a device not being present
>> at mount, we don't have code (yet) to detect it dropping on a mounted
>> filesystem.  Why having proper detection for a device disappearing does
>> not appear to be a priority, I have no idea, but that is a separate
>> issue from mount behavior.
>>
>
> Sorry for jumping out for such a sudden, but I submitted a patchset
> which is somewhat related to such degraded case.
>
> [PATCH 0/5] Btrfs: Per-chunk degradable check
>
> With that patchset, btrfs can do quite good check for degradable and
> mount/remount and even mounted time.
> (Return value of btrfs_check_degradable() will indicate all devices OK,
> or not all OK but degradable, or not writable degradable)
>
> And with that patchset, it's quite easy to add support for btrfs to
> sliently switch to degraded mount option if possible.
> (Along with other improvement of course)
>
>
> For the original feedback from end user, personally I understand users
> who don't want to add degraded mount option manually when a device
> fails, nor don't want to add a permanent mount option info fstab, just
> in case of failure.
>
> So personally, I'd like to add a new mount option "nodegraded", to allow
> user to force no degraded mount.
> And if neither "degraded" nor "nondegraded" is given, let btrfs to
> automatically switch to degraded if possible.
>
> And it should also still be able to info user, either by the easily
> igored dmesg, or easier to notice mount option change.
>
> How about this method to solve the problem?
It's not a bad idea, except that it changes established usage, and there 
are probably some people out there who depend on the current behavior. 
If we do go that way, mount needs to spit out a big obnoxious warning 
(as in, not through dmesg or mount options, but directly on stderr) if 
the filesystem gets mounted degraded automatically.  A better option 
might be to add a compat feature bit, and if that bit is set, then use 
the above logic, otherwise use the current logic.