[opensuse-factory] leap - partioning proposal with subvolumes for mailman, libvirt, named, pgsql ?
I was just re-installing Leap on my test desktop when I noticed the btrfs partitioning proposal: * Create subvolume @/var/lib/libvirt/images on device /dev/sda5 with * Create subvolume @/var/lib/mailman on device /dev/sda5 * Create subvolume @/var/lib/mariadb on device /dev/sda5 with * Create subvolume @/var/lib/named on device /dev/sda5 * Create subvolume @/var/lib/pgsql on device /dev/sda5 I guess mariadb is installed by default, but what about the rest, is that really also default? mailman, named and pgsql? I don't mind, I'm just curious. -- Per Jessen, Zürich (6.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello Per and all, When introducing btrfs as the default filesystem for SUSE Linux Enterprise, we started evaluating areas of potential "disappointment", and we figured that there is one - well known - risk: write performance in the context of databases and virtual machine images (host). This is not a "bug" in btrfs, but it is a programatic issue with all filesystems using "Copy on write"; in other words, also other CoW filesystems suffer from this. Thus the strong suggestion is to use xfs for databases. However, we know that not everbody is reading release notes, and we are aware that people often want it "quick and easy", just "one filesystem". To accomodate this behaviour and minimize risk, we have decided to use the btrfs capability of marking database files as "NoCOW"; the easiest way to achieve this is by creating a btrfs subvolume and marking this as NOCOW, thus all files in this subvolume are not COWed, and the performance penalty is removed. Find attached a graph showing this effect: The graph was created by simulating the situation via a loop device, aka "nested filesystems". xfs is always the filesystem within the loop, the "host" filesystems are ext4, xfs, btrfs+cow, btrfs-cow (no cow). -- As you see, the btrfs-no-CoW performance is equal to ext4, xfs is a bit better -- for this specific test. Hope this explains. As a general recommendation for those people looking for the last percent of performance, we suggest that you always test your specific workload with all combinations of filesystems and IO schedulers on the target hardware. So long - MgE P.S.: I will present about the topic of filesystem recommendations at SUSECon 2015 in Amsterdam. On 2015-10-14 T 09:26 +0200 Per Jessen wrote:
I was just re-installing Leap on my test desktop when I noticed the btrfs partitioning proposal:
* Create subvolume @/var/lib/libvirt/images on device /dev/sda5 with * Create subvolume @/var/lib/mailman on device /dev/sda5 * Create subvolume @/var/lib/mariadb on device /dev/sda5 with * Create subvolume @/var/lib/named on device /dev/sda5 * Create subvolume @/var/lib/pgsql on device /dev/sda5
I guess mariadb is installed by default, but what about the rest, is that really also default? mailman, named and pgsql? I don't mind, I'm just curious.
-- Matthias G. Eckermann - Senior Product Manager SUSE® Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Hi Matthias, Am 14.10.2015 um 10:39 schrieb Matthias G. Eckermann:
Hello Per and all,
When introducing btrfs as the default filesystem for SUSE Linux Enterprise, we started evaluating areas of potential "disappointment", and we figured that there is one - well known - risk: write performance in the context of databases and virtual machine images (host).
noone[™] will run productive virtualization with VMS in /var/lib/libvirt/images on the rootfs anyway :-) As already mentioned by Ludwig, hardcoding this in the installer is a possibility, but one of such stupidity (IMNSHO) that it is only applicable to "enterprise" customers, but not to a community project. Now I know that Leap is going to use (very small) parts of SLES12 code base, but we should actually use the good ones and not the bad ones. BTW: the view of the installation proposal with it's 3 screenfuls of mount points is making everyone in my vincinity just go into the "expert" partitioner and select "ext4" for the root fs. And if they don't, they go back a few weeks later, because their system monitoring tools (using "df") will tell them that all their partitions are 90% full, sending red alarms, even though "du -s" tells them only 20% are used. Half an hour later, they have reinstalled with ext4/xfs... So if you want this btrfs thing to succeed, make it look better to old-timers. Both in the installation proposal (subject of this thread) and in daily use. (I personally do not use btrfs, because it does not bring *me* any benefit and I do not trust it yet, not because I would not be able to find out how to "df"). With due respect :-) seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Wed, Oct 14, 2015 at 09:26:51AM +0200, Per Jessen wrote:
I was just re-installing Leap on my test desktop when I noticed the btrfs partitioning proposal:
* Create subvolume @/var/lib/libvirt/images on device /dev/sda5 with * Create subvolume @/var/lib/mailman on device /dev/sda5 * Create subvolume @/var/lib/mariadb on device /dev/sda5 with * Create subvolume @/var/lib/named on device /dev/sda5 * Create subvolume @/var/lib/pgsql on device /dev/sda5
I guess mariadb is installed by default, but what about the rest, is that really also default? mailman, named and pgsql? I don't mind, I'm just curious.
I consider this a suboptimal workflow. But I expect the following answer: It doesn't cost anything. The subvolume are created with the goal to proect them while rolling back a snapshot. Instead of having these suvolumes all configured by default it would be nice to have a generic mechanism which allows to create a subvolume on demand if a particular service gets installed or selected for installation. And if the filesystem in question supports it. You see how much more easy it is to create them all with one shot? I'm adding Arvin to get his feedback/ inspiration/ nack :-) Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 2015-10-14 T 10:43 +0200 Lars Müller wrote:
But I expect the following answer: It doesn't cost anything.
Yes, it's safer to do this upfront than in the RPM (for example).
The subvolume are created with the goal to proect them while rolling back a snapshot.
Thanks, Lars, this indeed is the other(and probably even more important) aspect, why we are doing separate subvolumes. It seems, I am too much into my SUSECon presentation (see other E-Mail), currently:-) So long - MgE -- Matthias G. Eckermann - Senior Product Manager SUSE® Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Matthias G. Eckermann wrote:
On 2015-10-14 T 10:43 +0200 Lars Müller wrote:
But I expect the following answer: It doesn't cost anything.
Yes, it's safer to do this upfront than in the RPM (for example).
Is there a way at all to make a package create a subvolume resp flag one of it's directories as no copy on write? Extending the hardcoded list in the installer for every potential package doesn't scale. For example it would make sense for the openQA package to also use a separate subvolume resp nocow for it's worker pool directories. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Lars Müller wrote:
Hi,
On Wed, Oct 14, 2015 at 09:26:51AM +0200, Per Jessen wrote:
I was just re-installing Leap on my test desktop when I noticed the btrfs partitioning proposal:
* Create subvolume @/var/lib/libvirt/images on device /dev/sda5 with * Create subvolume @/var/lib/mailman on device /dev/sda5 * Create subvolume @/var/lib/mariadb on device /dev/sda5 with * Create subvolume @/var/lib/named on device /dev/sda5 * Create subvolume @/var/lib/pgsql on device /dev/sda5
I guess mariadb is installed by default, but what about the rest, is that really also default? mailman, named and pgsql? I don't mind, I'm just curious.
I consider this a suboptimal workflow.
But I expect the following answer: It doesn't cost anything.
Yep, I think so too.
The subvolume are created with the goal to proect them while rolling back a snapshot.
Instead of having these suvolumes all configured by default it would be nice to have a generic mechanism which allows to create a subvolume on demand if a particular service gets installed or selected for installation. And if the filesystem in question supports it. You see how much more easy it is to create them all with one shot?
Yup. -- Per Jessen, Zürich (8.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 14, 2015 at 10:43:11AM +0200, Lars Müller wrote:
Hi,
On Wed, Oct 14, 2015 at 09:26:51AM +0200, Per Jessen wrote:
I was just re-installing Leap on my test desktop when I noticed the btrfs partitioning proposal:
* Create subvolume @/var/lib/libvirt/images on device /dev/sda5 with * Create subvolume @/var/lib/mailman on device /dev/sda5 * Create subvolume @/var/lib/mariadb on device /dev/sda5 with * Create subvolume @/var/lib/named on device /dev/sda5 * Create subvolume @/var/lib/pgsql on device /dev/sda5
I guess mariadb is installed by default, but what about the rest, is that really also default? mailman, named and pgsql? I don't mind, I'm just curious.
I consider this a suboptimal workflow.
I agree.
Instead of having these suvolumes all configured by default it would be nice to have a generic mechanism which allows to create a subvolume on demand if a particular service gets installed or selected for installation. And if the filesystem in question supports it. You see how much more easy it is to create them all with one shot?
The snapper package now has a program called mksubvolume which
does the required tasks: Find the correct filesystem, create
subvolume (with no-cow if desired), add it to fstab and finally
mount it. Can be used in a rpm post-install section.
ciao Arvin
--
Arvin Schnell,
Den 14. okt. 2015 23:25, skrev Arvin Schnell:
On Wed, Oct 14, 2015 at 10:43:11AM +0200, Lars Müller wrote:
Hi,
On Wed, Oct 14, 2015 at 09:26:51AM +0200, Per Jessen wrote:
I was just re-installing Leap on my test desktop when I noticed the btrfs partitioning proposal:
* Create subvolume @/var/lib/libvirt/images on device /dev/sda5 with * Create subvolume @/var/lib/mailman on device /dev/sda5 * Create subvolume @/var/lib/mariadb on device /dev/sda5 with * Create subvolume @/var/lib/named on device /dev/sda5 * Create subvolume @/var/lib/pgsql on device /dev/sda5
I guess mariadb is installed by default, but what about the rest, is that really also default? mailman, named and pgsql? I don't mind, I'm just curious. I consider this a suboptimal workflow. I agree.
Instead of having these suvolumes all configured by default it would be nice to have a generic mechanism which allows to create a subvolume on demand if a particular service gets installed or selected for installation. And if the filesystem in question supports it. You see how much more easy it is to create them all with one shot? The snapper package now has a program called mksubvolume which does the required tasks: Find the correct filesystem, create subvolume (with no-cow if desired), add it to fstab and finally mount it. Can be used in a rpm post-install section.
ciao Arvin
At least for new or re-installation on an existing multiboot sliced system, I always change to Expert Partitioning and next Import existing mount points Then there will be minimal need for manual editing, i.e only change root partition to format. Terje J. H -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Arvin Schnell -
Lars Müller -
Ludwig Nussel -
Matthias G. Eckermann -
Per Jessen -
Stefan Seyfried -
Terje J. Hanssen