Hi Anand,
On 2015-09-17 17:18, Anand Jain wrote: > it looks like -o degraded is going to be a very obvious feature, > I have plans of making it a default feature, and provide -o > nodegraded feature instead. Thanks for comments if any. > > Thanks, Anand I am not sure if there is a "good" default for this kind of problem; there are several aspects: - remote machine: for a remote machine, I think that the root filesystem should be mounted anyway. For a secondary filesystem (home ?), may be that an user intervention could be better (but without home, how an user could log?). - spare: in case of a degraded filesystem, the system could insert a spare disk; or a reshaping could be started (raid5->raid1, raid6->raid5) - initramfs: this is the most complicated things: currently most initramfs don't mount the filesystem if all the volumes aren't available. Allowing a degraded root filesystem means: a) wait for the disks until a timeout b) if the timeout expires, mount in degraded mode (inserting a spare disk if available ?) c) otherwise mount the filesystem as usual - degraded: I think that there are different level of degraded. For example, in case of raid6 a missing device could be acceptable; however in case of a raid5, this should be not allowed; and an user intervention may be preferred. In the past I suggested the use of an helper, mount.btrfs [1], which could handle all these cases better without a kernel intervention: - wait for the devices to appear - verifying if all the needed devices are present - mounting the filesystem passing - all the devices to the kernel (without relying to udev and btrfs dev scan...) - allowing the degraded mode or not (policy) - starting an insertion of the spare (policy) G.Baroncelli [1] http://www.spinics.net/lists/linux-btrfs/msg39706.html -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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