June 2016 - openSUSE Storage - openSUSE Mailing Lists

Review partitioning requirements - x86
by Jiri Srain 14 Jul '16

14 Jul '16

Hi, find below the review from Michael Chang, based on the rspec version of the specification. Jiri Yast::Storage::BootRequirementsChecker #needed_partitions in a x86 system using UEFI with a partitions-based proposal if there are no EFI partitions requires only a new /boot/efi partition if there is already an EFI partition only requires to use the existing EFI partition with a LVM-based proposal if there are no EFI partitions requires /boot and a new /boot/efi partition if there is already an EFI partition requires /boot and a reused /boot/efi partition not using UEFI (legacy PC) with an MS-DOS partition table with sufficently large MBR gap in a partitions-based proposal does not require any particular volume in a LVM-based proposal requires only a /boot partition I am not sure why the /boot parititon is needed here. If you have sufficently large MBR gap to embed stage2 image, then it could boot off from LVM volumes directly. with too small MBR gap raises an exception with no MBR gap raises an exception It is a little messy here, how it works currently depends on file system and any disk abstractions user is going to create. Please note I am assuming we still specify --force to "grub2-install" so that fallback can really be triggered. 1. Filesystem like extX, XFS: Fallback to blocklist mode, which is more "fragile" so displaying warnings. 2. COW File system. Btrfs(ZFS): Fallback to use filesystem provided bootloader pad which can be equivalent to mbr gap. 3. Any disk abstractions like LVM and mdadm: expliclty require MBR gap, so error out is reasonable. with GPT partition table if there is no GRUB partition in a partitions-based proposal only requires a new GRUB partition in a LVM-based proposal requires /boot and a GRUB partitions Why not also creating new GRUB partition for LVM so that /boot can be omitted ? if there is already a GRUB partition in a partitions-based proposal does not require any particular volume in a LVM-based proposal only requires a /boot partition Do we have any reason to keep /boot partition for LVM ? It should be the same with previous "does not require any particular volume" to me. when proposing a boot partition requires /boot to be ext4 with at least 100 MiB requires /boot to be in the system disk out of LVM recommends /boot to be 200 MiB when proposing an new EFI partition requires /boot/efi to be vfat with at least 33 MiB requires /boot/efi to be out of LVM recommends /boot/efi to be 500 MiB requires /boot/efi to be close enough to the beginning of disk when proposing an new GRUB partition requires it to have the correct id requires it to be out of LVM requires it to be between 256KiB and 8MiB, despite the alignment recommends it to be 1 MiB -- To unsubscribe, e-mail: opensuse-storage+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

4 12

Storage-NG Trello board
by Stefan Hundhammer 20 Jun '16

20 Jun '16

https://trello.com/b/o1L32dpa/libstorage-and-yast2-storage-redesign -- Stefan Hundhammer <shundhammer(a)suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-storage+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

1 0

Sizes in yast-storage-ng after introducing alignment in libstorage-ng
by Ancor Gonzalez Sosa 15 Jun '16

15 Jun '16

Before ====== Before introducing alignment calculation in libstorage-ng the library provided methods like ::Storage::Partition#size_k #=> Fixnum ::Storage::Disk#size_k #= Fixnum On top of that, there was a DiskSize class with offered several convenient methods including DiskSize#size_k #=> Fixnum And, on top of that we had many methods always called #size that returned a DiskSize object, like FreeDiskSpace#size #=> DiskSize ::Storage::Partition#size #=> DiskSize (using a refinement) The API was pretty clear, you could always expect any method called #size to return a DiskSize object and you always had #size_k to get a Fixnum. After ===== All that beauty was broken with the change introduced in libstorage-ng. Now its API looks like ::Storage::Partition#size #=> Fixnum (bytes) ::Storage::Disk#size #= Fixnum (bytes) Now you cannot longer infer the type based in the name and everything becomes more confusing with methods like DiskSize#size #=> Fixnum (bytes) DiskSize#size_b #=> Fixnum (alias for the former) FreeDiskSpace#size #=> DiskSize Solution 1 ========== We could rename all the methods from libstorage from #size to #size_b and thus recover the initial consistency. Solution 2 ========== We could rename all the methods in the ruby layer that return a DiskSize object to something like #disk_size. So #size is always a Fixnum (bytes) and #disk_size is always a DiskSize object. For example FreeDiskSpace#disk_size #=> DiskSize In addition, I would add DiskSize#bytes as a more readable alias for DiskSize#size, resulting in things like this: a_free_space.disk_size.bytes What do you think? -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-storage+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

3 2