On Mon, 2016-02-29 at 06:58 -0800, Adam Williamson wrote: > On Mon, 2016-02-29 at 09:29 -0500, David Lehman wrote: > > On Fri, 2016-02-26 at 14:03 -0800, Adam Williamson wrote: > > > > > > On Wed, 2016-02-24 at 09:40 -0500, David Lehman wrote: > > > > > > > > > > > > > > > > > > "This means that if the installer offers mechanisms for > > > > > resizing > > > > > storage volumes, then it must run the appropriate resizing > > > > > tool > > > > > with > > > > > the appropriate parameters for the resize the user chooses. > > > > > The > > > > > reason > > > > > > > > What is the appropriate tool (and parameters) for resizing the > > > > formatting on a device with unrecognized/unknown formatting? > > > I don't believe we explicitly considered that question at the > > > time of > > > writing the criterion. However, my interpretation as the person > > > who > > > drafted it (IIRC) would be that the "appropriate tool" for any > > > partition with data on it is a tool which is at least *intended* > > > to > > > preserve the data. > > > > > > In an ideal world, with no specific technical concerns, it would > > > be > > > my > > > expectation that we would not offer an operation named "resize" > > > in > > > the > > > case where we have no idea how to preserve any contents of the > > > volume. > > > We would only offer an operation named "resize" in cases where we > > > do > > > actually have some idea how to perform a non-destructive resize. > > > I'm > > > entirely open to there being technical reasons why this is not > > > possible, though. > > It is not possible to distinguish between a lack of meaningful data > > and > > meaningful data that the OS has no means of recognizing. A > > partition > > type flag or GUID is not generally sufficient for this purpose. > > > > We do have the option to prevent resize of devices with no > > formatting > > or unrecognized formatting. You could certainly argue that it makes > > more sense to remove such a device than to resize it if you need > > more > > space. I'll just explain that it's in the name of protecting > > careless > > users when the bugs start coming in. > > So basically it's another shoot-yourself-in-the-foot conundrum, with > the standard choices? Leave the safety off, put a dumbass "Are you > sure > you want to do that?" message in front of it, or disallow it and > annoy > some partition pokemon with an implausible use case for it? > > Well hey, life sucks. I *think* my preference, if you asked my > opinion, > would be to disallow it and just say "if it's an empty partition you > really want to make smaller, just do it in another tool or delete it > and recreate it smaller". But if you think the balance here should be > in favour of letting people shoot themselves in the foot, I'm not > gonna > argue it, and we'll just have to rewrite the criterion somehow. I don't have a strong preference as to which corner-case we turn our back on here. I do think that if this qualifies as a blocker under the current criteria a rewrite/edit is definitely in order. David _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
