- openSUSE Storage

Announcement: this list is closing per 13/7/2018
by per＠opensuse.org 06 Jul '18

06 Jul '18

Dear list users, due to the fact that this list hasn't been used for over a year, this list will be archived and closed. Please find the current mailing lists at https://lists.opensuse.org. The list will remain open until Friday 13 July 2018. Goodbye, see you on the other lists, forums, IRC or social media. Best regards the openSUSE Board, on behalf of the community -- Per Jessen, Zürich (18.1°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse-storage+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

1 0

Refinement meetings for next Scrum sprint
by Ancor Gonzalez Sosa 02 Nov '16

02 Nov '16

Just a reminder for YaST Team-S: the product owner will not be present during next planning meeting. We need to schedule as many refinement meetings as needed to make sure that's not a problem. Just saying. :-) -- 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

1 0

Limitations of the new LVM-based proposal
by Ancor Gonzalez Sosa 27 Oct '16

27 Oct '16

This mail is targeted to all the yast-storage-ng developers and POs. I have been working in an approach for LVM-based proposal that offers quite some cool features, like proposing a VG with several PVs to optimize the space usage and similar stuff. But I have a problem with that approach. I'm starting to feel the logic is too hard to follow. So I wanted to go back to square one and define a more dumb LVM proposal. The resulting code will be easier to understand and will reuse many components with almost no modifications. I just wanted to make sure we all agree the following restrictions are acceptable. 1) A pre-existing VG will be reused for our purposes only if it's already big enough, i.e. we never grow existing VGs. 2) If we need to create a new VG, it will contain just one big PV. Potentially, that means we will need to destroy/resize more partitions, compared to a more flexible approach with the ability to propose a VG with several PVs. 2) Extra space freed while making space for the no-lvm partitions (EFI, PReP, /boot, etc.) will not be turned into PVs to grow our VG (no matter if it's created or reused). After all, it's just a proposal. Is everybody fine with the restrictions? -- 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

2 1

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

Mid-term goal for storage-ng
by Ancor Gonzalez Sosa 19 May '16

19 May '16

I have been planning to send this mail for quite some time. Since we were lately focused on implementing features for SP2 I had put it on hold. In this sprint we have some storage-ng related PBIs again so... This is kind of a suggestion for our product owner about sorting team-S' PBIs. Following the agile approach of trying to have something shippable as soon as possible (and always shippable), I would like to see an installable Tumbleweed image using libstorage-ng the sooner the better. Something that can turn our own instance of openQA green for, at least, one scenario. The three main "users" of libstorage (from the top of my head) are: - (a) The partitioning proposal - (b) Yast-Bootloader - (c) The expert partitioner For (a) we already have working code for very simple scenarios (ms-dos style partitions with contiguous space). (c) is not absolutely needed to perform an installation[1]. Yast-Bootloader has been recently refactored to the ground, killing a lot of old code and replacing SCR with the more object-oriented CFA. It should be in a sane-enough state to be touched. So, as much as I would like to keep working in improving the proposal and supporting LVM (two things that are indeed quite interesting from a developer's point of view), I think we should postpone improving what we already have and focus on having a first version of the stuff that is missing (i.e. stuff that is preventing us from having that installable ISO). (b) comes to mind, but sure I'm forgetting something. Cheers. [1] Moreover, we should probably use the opportunity to have the UI of the expert partitioner redesigned (or at least reviewed), but that's another story. -- 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

2 1

legacy strategy and other things
by Steffen Winterfeldt 15 Apr '16

15 Apr '16

Hi Ancor, [ https://github.com/yast/yast-storage-ng/pull/47 ] working on the legacy strategy I stumbled across some general (design) issues: (1) the current 'refinement' using Modules does not work and is somewhat clumsy; is there anything against extending the libstorage-ng classes directly (like I did in storage/refinements.rb? - and (1a) dump the refinements directory entirely? (2) the internal structure of yast-storage-ng is a nightmare - can we do something about it? always having to require a bunch of sub-classes is pointless; ruby ends up including basically all of them anyway; see boot_requirements_strategies/base.rb for what I mean. As always all strategies are included anyway, we can bundle the requires in the base class. Or is this so un-ruby? (3) we require 'yast' just for the logger in different places; can we stuff this into a single place and include our own (wrapper) logger instead? (4) what will an external user of storage-ng 'require'? Steffen -- Give orange me give eat orange me eat orange give me eat orange give me you. (chimp Nim, using sign language) -- To unsubscribe, e-mail: opensuse-storage+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

2 3

Re: Reusing partitions in the proposal
by Steffen Winterfeldt 14 Apr '16

14 Apr '16

On Tuesday 2016-04-12 10:04, Ancor Gonzalez Sosa wrote: > Right now the mechanism to reuse existing partitions is not 100% clear. > > Case 1 - EFI partition > > If there is already an EFI partition in the system, the VolumesGenerator > will not include an EFI partition in the list of volumes (since we don't > need to create it). It's not clear to me who/when will do the actual > work of reusing the existing partition. > > Case 2 - Swap > > Right now, VolumesGenerator always includes a swap volume, even if there > is one in the system. This PBI suggests that deciding between creating a > new partition or resizing an existing one would be a task for SpaceMaker > and PartitionCreator. > > We need a more consistent approach. Ideas? > > Maybe having something like > vol.reuse_device = "/dev/sdc3" > so the VolumesGenerator already decides that? Something for settings? Like reuse_efi_system_partition, reuse_swap? BTW, the ml is opensuse-storage; Cc-ing. Steffen -- To unsubscribe, e-mail: opensuse-storage+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

5 9

Notes from Storage meeting
by Jiri Srain 30 Mar '16

30 Mar '16

Hello, now that hopefully everyone is on the list, find attached the notes from the meeting we had in Nuernberg. It is based on the Etherpad notes created during the meeting. After getting some feedback, I would push it back to Git so that it can be worked on further as the requirements of various areas and details about some specific stuff becomes clear. Thanks for any feedback, and sorry for taking that time, Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com

1 0