On Fri, Mar 13, 2015 at 4:27 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > When using the custom partitioning flow, the installer must be able to: > > * Correctly display, remove, and assign mount points to existing > storage volumes of the supported types (requiring entry of the > encryption passphrase, for encrypted volumes) > * Correctly display the locations and sizes of, and remove, existing > partitions of other types > * Create and assign mount points to new storage volumes of the > supported types "assign" appears in 2 out of 3, "remove" appears in 2 out of 3. I'd like to think "correctness" is implicit, and can go without explicitly saying it, and if not then add correctness to the initial statement. I definitely think encryption caveat is a given, it's unworkable if the user doesn't enter the passphrase). This reads more consistently to me: When using the custom partitioning flow, the installer must be able to (correctly): - create mount points with new storage volumes of the supported types. - assign mount points to existing storage volumes of the supported types. - display (including location and size), and remove any storage volume. > * Remove a planned storage volume from the planned layout How does this differ from "remove any storage volume"? Seems wordy. > * Reject or disallow invalid disk and volume configurations without > crashing. Good as is. > > footnote: Supported storage volume types > > Supported storage volume types are btrfs, xfs and ext4 filesystems - > including LUKS-encrypted filesystems - residing on: > * Plain partitions > * LVM logical volumes (including thinly-provisioned LVs) > * btrfs volumes and sub-volumes > * Linux software RAID-0, RAID-1, and RAID-5 sets > * Reasonable combinations of the above (e.g. LVM-on-RAID) Supported storage volume types are Btrfs, XFS, an ext4 filesystems, including if LUKS encrypted, when residing on: - plain partitions - LVM Logical Volumes (including thin Volumes) - Linux software RAID 0, RAID 1, and RAID 5 sets. - Reasonable combinations of the above (e.g. LVM-on-RAID) ## omitted separate item for btrfs volumes and subvolumes because a.) it's implicit, thus redundant; b.) making it explicit is confusing+silly because of this 2.5 year old bug with a submitted, tested patch yet no forward progress getting it into grubby stable, and now Anaconda has reverted support for /boot on Btrfs subvolumes again for the umpteenth time. Haha, yes it is like sand stuck in the wrong place for me...GRR! ## It's not a hill I'm going to die on, but I personally don't like the idea of blocking on raid0 or raid5. For one, raid0 is "I hate my data" anyway. And raid10 is conservative, scalable, better performing, and more general purpose than raid5, so I'd sooner promote it to working by beta rather than raid 5. I think it's a good idea for raid1 installs to be possible by Beta, beyond that is icing. OK maybe block on raid0/raid5 if a problem is found? But if the test in the matrix hasn't been done then a missing test itself isn't blocking (it's an optional test)? > If we're going to touch this stuff, though, maybe we should try to > kill the horrible Final criterion, decide what (if anything) beyond > the above we want to support by Final, and maybe split the > requirements a bit between Beta and Final or allow some workarounds / > exceptions at Beta and stuff. There's still quite a lengthy list for the additional installer items for Final. The only thing really being added is LUKS as existing rather than newly created. And that makes sense because more people use it these days. And there seems to be some tentative agreement on doing the work necessary to make it a default on day, since unlike marginally longer login passwords, it'll protect your data at rest should the computer go MIA. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
