This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet.
Pending requests in repository yast-add-on:
- [WIP] Ask when the added repository is unsigned (bsc#1009127) (344 days)
https://github.com/yast/yast-add-on/pull/37
Pending requests in repository yast-branding:
- This repo is obsoleted by yast-theme (49 days)
https://github.com/yast/yast-branding/pull/4
Pending requests in repository yast-country:
- Keyboard rewrite: Load keyboard layouts (33 days)
https://github.com/yast/yast-country/pull/144
Pending requests in repository yast-installation:
- Disable plymouth by a no affend method, it will not block tty device activation at first time user login(bsc#1042554). (149 days)
https://github.com/yast/yast-installation/pull/584
Pending requests in repository yast-ldap:
- Manipulate system LDAP configuration rather than application LDAP configuration (288 days)
https://github.com/yast/yast-ldap/pull/26
Pending requests in repository yast-live-installer:
- - Use /etc/products.d/openSUSE.prod as /etc/products.d/baseproduct (217 days)
https://github.com/yast/yast-live-installer/pull/14
Pending requests in repository yast-mail:
- [WIP] return back MailTable to yast2-mail module from yast2 module (287 days)
https://github.com/yast/yast-mail/pull/25
Pending requests in repository yast-multipath:
- fix ycp killing bug with changing \r with space (205 days)
https://github.com/yast/yast-multipath/pull/19
Pending requests in repository yast-network:
- Drop replace direct access to LanItems::Items whenever it is possible. (56 days)
https://github.com/yast/yast-network/pull/588
Pending requests in repository yast-packager:
- [WIP] Ask when the added repository is unsigned (bsc#1009127) (343 days)
https://github.com/yast/yast-packager/pull/230
Pending requests in repository yast-security:
- [WIP] refactoring autoconverted ruby code into ruby code (280 days)
https://github.com/yast/yast-security/pull/40
Pending requests in repository yast-storage:
- fixed missing changes (111 days)
https://github.com/yast/yast-storage/pull/292
- Bsc 1049108 sle12 sp3 (181 days)
https://github.com/yast/yast-storage/pull/283
Pending requests in repository yast-users:
- Reduce perl (288 days)
https://github.com/yast/yast-users/pull/137
ERROR: API query limit exceeded
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
This question has been raised in IRC many times during storage-ng
development, with no satisfactory answer so far. But now we need to take
a decision at last.
Storage-ng always tries to align the start and end of all new and
resized partitions for optimal performance. In addition to that, there
is also a given alignment that has to be respected for the whole thing
to work (leaving performance aside). See [1] for more info.
For example, in the case of a typical GPT partition table in a typical
disk, the REQUIRED grain would be 1B (so we can create a partition of
any size), but the OPTIMAL grain is 1MiB (so we try to only distribute
the space in virtual "disk slices" of 1MiB).
In DASD, the typical REQUIRED grain is 48KiB, so no way we can create a
partition whose size is not divisible by that number. In addition, the
OPTIMAL grain is 3MiB.
The point is that I'm not so sure whether aligning the end makes that
much sense from the performance POV if a given partition is at the very
end of the partition table.
Two cases:
==========
1) GPT partition tables.
In GPT the last 16.5KiB are always reserved (a backup of the partition
table).
Let's say the user decides to create a partition using all the available
space at the end (or simply a big partition using the whole disk). A
very common scenario.
What should we do? Persist in our attempt to have everything aligned and
leave a gap of 1007.5Kib at the end or really use the space up until the
end?
If GPT is designed to always have those 16.5KiB stripped from the useful
space, I would assume that having a last "slice" of 1007.5Kib instead of
1MiB shouldn't imply a performance penalty. Otherwise, the GPT design is
rather... well... not-smart.
2) DASD partition tables.
A similar thing happens with DASD. In many situations, the remaining
space at the end of the disk is not divisible by 3MiB. Do we want to
leave the remainder space unused? If we decide to use also those, let's
say, 2MiB at the end of the disk, would we be introducing a performance
problem or that rule does not apply to partitions at the end of the disk?
Even further, it is possible than the remainder is not divisible by the
REQUIRED grain of 48KiB? I wouldn't expect that to happen, but these
eyes have seen so many things... ;-)
In short:
=========
For a partition trying to use the space at the end of the disk:
1) Should we give up on optimal alignment and use REQUIRED alignment for
that case? If we do so, would it have any performance impact?
2) Should we, instead, stick to the OPTIMAL alignment also for that
final partition and leave gaps at the end of all GPT and many (most) DASDs?
3) Should we even go further than (1) and completely ignore alignment
(even the REQUIRED one) assuming that partition tables can always be
used up to the end? (Who would build a disk with unusable space after
all ;-) ).
Thanks guys for the replies.
https://github.com/openSUSE/libstorage-ng/blob/master/doc/alignment.md
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
there are some confusions about what's online and what's offline upgrade.
The official SUSE terminology defines whether the target system is running
(online) or not (offline), it's NOT about the network connectivity!
See the official documentation for the details:
https://www.suse.com/documentation/sles-12/singlehtml/book_sle_deployment/b…
HTH
Ladislav
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
