On 2015-11-13 11:20, Anand Jain wrote: > > Thanks for comments. > > On 11/13/2015 03:21 AM, Goffredo Baroncelli wrote: >> On 2015-11-09 11:56, Anand Jain wrote: >>> These set of patches provides btrfs hot spare and auto replace support >>> for you review and comments. >> >> Hi Anand, >> >> is there any reason to put this kind of logic in the kernel space ? [...] > >> Another feature of this daemon could be to add a disk when the disk >> space is too low, > > That will be at the cost of a spare device which user should review > the trade-offs and do it manually ? I am not sure.
If you have more than one spare, you can do automatically both: a new disk is added when the space is low, and a disk is replaced in case of failure. If you have only one spare: you may decide to reserve it only for replacing a failed disk. But this should be a configurable option: a low space leads to a not available filesystem, a failed disk means a higher likelihood to loosing all the filesystem. I am not sure which should be the more critical. >> or to start a balance when there is no space to >> allocate further chunk..... > > Yep. As you notice, the thread created here is casualty_kthread() > (instead of replace_kthread()) over the long run I wish to provide > that feature in this thread, as it is a mutually exclusive operations > with replace. A disk replacing should be an higher priority operation. In case of disk failure during a balance/defrag, these operation should be stopped to allow a replace. If you want to start a replace, you should stop others (long time) operations like balance and defrag. > >> Of course all these logic could be implemented in kernel space, >> but I think that we should avoid that when possible. > > Easy to handle the mutually_exclusive parts with in the kernel > and Its better to have the important logic at one place. Two heads > operating on an org looking and feeling different things will lead > to wrong decisions. Which is the other logic which you are referring ? > >> Moreover in user space the logging is more easy.... > > Thanks, Anand -- 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
