2016-05-29 19:11 GMT+02:00 Chris Murphy <li...@colorremedies.com>: > On Sat, May 28, 2016 at 3:42 PM, Peter Becker <floyd....@gmail.com> wrote: >> Thanks for the clarification. I've probably overlooked this. >> >> But should "resize max" does not do what you expect instead of falling >> back on an "invisible" 1? > > How does it know what the user expects?
Then simply remove the default deviceid und let the user choise what the want. IMHO its a bad think to choise automaticly a option if its not clear what the user wants. And in spezial there is no hint in the output of the deviceid who is used. The output is: "Resize '/mnt' of 'max'" .. no hint the this only affect the deviceid 1. The suggestion for me is that the whole pool is resized to max. Possible solutions: 1. remove the default deviceid 2. resize without deviceid affects the whole pool 3. improve the output of the resize command by adding the deviceid 4. remove the inconsitent between add+remove and replace by triggering resize max after replace is finished. > I think the issue is not with the resize command, but rather the > replace command does not include the resize max operation. Presumably > the user intends the entire block device provided as the target for > replacement to be used. > > So I think the mistake is replace assumes the user wants to use the > same amount of space as the former block device. I think if the user > wanted to use the former block device size on the new block device, > they'd partition it and use the partition as the target. > > > -- > Chris Murphy -- 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
