On 3/27/19 2:13 PM, Rich wrote: > Honestly, if nobody else writes it or convinces me otherwise, I'll > probably take a stab at it in the next 7 days, as the actual > implementation without configurability shouldn't require a lot of > code. (...neither should permitting configurability, really, it's just > that AFAIK zpool doesn't currently have much of any sort of runtime > config parsing, just argument parsing).
I care very little about the main point of this proposal, which is to make it easier for me to create/keep a (data) pool portable to a _different_ operating system. I care a lot about fixing the situation where `zpool status` is nagging me to run `zpool upgrade bpool`, which will (may?) break booting my currently working system. Thankfully, these can be solved in exactly the same way. When you create the features=portable behavior, I will propose a features=grub definition. I don't really care if this is in ZoL .c code, in a text file, or in an Debian/Ubuntu patch. As long as your implementation doesn't _prevent_ this, I'll be happy. -- Richard ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Td66d70a086ae5a9e-Me5d8063533ab84a7f746bbae Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
