On 29/01/2019 12.06, Ludwig Nussel wrote:

Michael Schroeder schrieb:

...

On Tue, Jan 29, 2019 at 11:49:38AM +0100, Ludwig Nussel wrote:

...

Axel Braun schrieb:

...

[...] Raspi are heavily depending on the kind of 'hard disk' you are using, whether it is a SD card (connected via USB2) or an internal SSD Here is the result of a Raspi using a Leap 15 LXQT image:

/home/test # systemd-analyze blame       1min 30.071s display-manager.service       1min 18.481s backup-rpmdb.service

Did anyone ever rely on that rpm database backup the last decade?

Me. And I helped others with instructions to use it with a destroyed rpm database. Examples with a quick google search: https://serverfault.com/questions/765523/suse-restore-packages-list-from-var... http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html https://www.linuxquestions.org/questions/linux-general-1/help-me-to-recover-... http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html

...

It's you last hope if your rpm database gets corrupt.

The question is if that still happens, it's not 1996 anymore :-) Also we have btrfs snapshots by default that include the rpm DB.

No, *we* don't. Please, just move the service to run some other time. Daily or weekly, just not at boot. In fact, you could create something to run some services that currently run at boot to run 15 minutes later. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Op dinsdag 29 januari 2019 12:43:03 CET schreef Thorsten Kukuk:

On Tue, Jan 29, Carlos E. R. wrote:

...

https://serverfault.com/questions/765523/suse-restore-packages-list-from- > var-adm-backup-rpmdb-packages-20160323-gz> http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html <https://www.linuxquestions.org/questions/linux-general-1/help-me-to-reco ver-my-rpmdb-228527/> http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html Most of them are over 10 years old ... Time is going on, we are not 2004 anymore, too :)

...

...

...

It's you last hope if your rpm database gets corrupt.

The question is if that still happens, it's not 1996 anymore :-) Also we have btrfs snapshots by default that include the rpm DB.

No, *we* don't.

*we* have btrfs snapshots by default. If you disable them, your problem, like you could also disable the backup-rpmdb service if you don't like it. Sorry, but that you can change the default is no argument, as it works in both directions. If you decide to not use btrfs, you need to decide how else you want to backup your rpmdb. Punishing everybody else is not the right way to do it.

...

Please, just move the service to run some other time. Daily or weekly, just not at boot. In fact, you could create something to run some services that currently run at boot to run 15 minutes later.

Better would be to run it if the rpmdb has really changed. If really some people insist on this.

My vote would be: disable it by default, and if people decide to do a non-standard installation and they need the service, they can enable it.

+1, no doubt.

Thorsten

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op dinsdag 29 januari 2019 12:53:59 CET schreef Carlos E. R.:

On 29/01/2019 12.43, Thorsten Kukuk wrote:

...

On Tue, Jan 29, Carlos E. R. wrote:

...

<https://serverfault.com/questions/765523/suse-restore-packages-list-from -var-adm-backup-rpmdb-packages-20160323-gz> http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html <https://www.linuxquestions.org/questions/linux-general-1/help-me-to-rec over-my-rpmdb-228527/> http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html> Most of them are over 10 years old ... Time is going on, we are not 2004 anymore, too :)

...

...

...

It's you last hope if your rpm database gets corrupt.

The question is if that still happens, it's not 1996 anymore :-) Also we have btrfs snapshots by default that include the rpm DB.

No, *we* don't.

*we* have btrfs snapshots by default. If you disable them, your problem,

*We* don't use btrfs. Dangerous thing to have, sorry.

...

like you could also disable the backup-rpmdb service if you don't like it. Sorry, but that you can change the default is no argument, as it works in both directions. If you decide to not use btrfs, you need to decide how else you want to backup your rpmdb. Punishing everybody else is not the right way to do it.

So, you want to punish everybody by forcing us to use btrfs?

...

...

Please, just move the service to run some other time. Daily or weekly, just not at boot. In fact, you could create something to run some services that currently run at boot to run 15 minutes later.

Better would be to run it if the rpmdb has really changed. If really some people insist on this.

Please.

...

My vote would be: disable it by default, and if people decide to do a non-standard installation and they need the service, they can enable it.

That would be acceptable. You can also detect non btrfs installs. Also disable btrfs maintenance timers on not btrfs systems. Please, don't start another btrfs flame war. It's the default, if you step away, that's your choice. And, don't judge btrfs if you don't use it. I do, and it's working more than fine.

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 29/01/2019 12.57, Knurpht-openSUSE wrote:

...

Op dinsdag 29 januari 2019 12:53:59 CET schreef Carlos E. R.:

...

On 29/01/2019 12.43, Thorsten Kukuk wrote:

...

On Tue, Jan 29, Carlos E. R. wrote:

...

<https://serverfault.com/questions/765523/suse-restore-packages-list-fr om -var-adm-backup-rpmdb-packages-20160323-gz> <http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html

...

<https://www.linuxquestions.org/questions/linux-general-1/help-me-to-re c over-my-rpmdb-228527/> <http://opensuse.14.x6.nabble.com/Corrupted-RPM-database-td3128580.html

...

>

Most of them are over 10 years old ... Time is going on, we are not 2004 anymore, too :)

...

...

> It's you last hope if your rpm database gets corrupt.

The question is if that still happens, it's not 1996 anymore :-) Also we have btrfs snapshots by default that include the rpm DB.

No, *we* don't.

*we* have btrfs snapshots by default. If you disable them, your problem,

*We* don't use btrfs. Dangerous thing to have, sorry.

...

like you could also disable the backup-rpmdb service if you don't like it. Sorry, but that you can change the default is no argument, as it works in both directions. If you decide to not use btrfs, you need to decide how else you want to backup your rpmdb. Punishing everybody else is not the right way to do it.

So, you want to punish everybody by forcing us to use btrfs?

...

...

Please, just move the service to run some other time. Daily or weekly, just not at boot. In fact, you could create something to run some services that currently run at boot to run 15 minutes later.

Better would be to run it if the rpmdb has really changed. If really some people insist on this.

Please.

...

My vote would be: disable it by default, and if people decide to do a non-standard installation and they need the service, they can enable it.

That would be acceptable. You can also detect non btrfs installs. Also disable btrfs maintenance timers on not btrfs systems.

Please, don't start another btrfs flame war. It's the default, if you step away, that's your choice. And, don't judge btrfs if you don't use it. I do, and it's working more than fine.

I will if you accept that people are not mandated to use your default choices. If you try to force us to use btrfs, I'll speak up. :-/

Talking of removing system features assuming everybody uses btrfs is *bad*.

And for the record, I do recommend btrfs to people. I explain pros and cons and they decide, and many go for it. Please stop the 'us' / 'we' arguing. You are not a customer, you are part of

Op dinsdag 29 januari 2019 13:32:37 CET schreef Carlos E. R.: the same community the devs and packagers are. There is no 'we' or 'us' unless you mean them included. You IMHO are 100% wrong in your perception of 'us users' vs 'them devs/packagers'. And this is not the first time I notice this attitude. Where it is wrong. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2019-01-29 13:01, Michael Schroeder wrote:

On Tue, Jan 29, 2019 at 12:43:03PM +0100, Thorsten Kukuk wrote:

...

Better would be to run it if the rpmdb has really changed. If really some people insist on this.

That's basically what the service already does. But it checks for changes by calculating the md5sum of the Packages file, which seems to take too long on some machines.

Yeah how did we get to a 100MB-sized Packages file anyway? RPM databases never seemed so big. Individual records, believing that is what db48_dump shows, are often in excess of 20 KB. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Dienstag, 29. Januar 2019 13:08:53 CET Michael Schroeder wrote:

On Tue, Jan 29, 2019 at 01:05:46PM +0100, Jan Engelhardt wrote:

...

Yeah how did we get to a 100MB-sized Packages file anyway? RPM databases never seemed so big. Individual records, believing that is what db48_dump shows, are often in excess of 20 KB.

It's simply the rpm headers. If they seem too big it's probably because we keep to many changelog entries (but that's just guessing, somebody should check the header contents).

M.

My Tumbleweed 20190115 went down from ~90 MByte to ~50 MByte changelogs when updating to 20190205. --- $> rpm -q rpm --changelog | head * So Jan 13 2019 Dirk Mueller - update macrosin.diff: Set cutoff date to SLE12 GA to remove changelogs from 2009-2014 from the generated RPMs. --- Changelog size determined by $> rpm -qa --changelog | wc -c 51852286 Another waste of of space is probably the %{FILECLASS} attribute, which stores the output of "file" verbatim for each file. Some gems: - "directory" stored for directores (implicit by file mode) - truetype fonts: e.g. TrueType Font data, 17 tables, 1st "GDEF", 30 names, Macintosh, Copyright (c) 2010-2013 by tyPoland Lukasz Dziedzic with Reserved Font Name "Carlito". Licensed - JPEGs: e.g. JPEG image data, JFIF standard 1.01, resolution (DPCM), density 50x50, segment length 16, baseline, precision 8, 5120x3200, components 3 - Executable/shared libs (note the BuildID): ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=76ee472fd428c969018f80369163acaf9ed019bc, stripped - Symlinks pointing into the buildsystem?: "cannot open `/home/abuild/rpmbuild/BUILDROOT/llvm7-7.0.1-1.1.x86_64/etc/ alternatives/FileCheck.1.gz' (No such file or directory)" The fileclass attribute alone amounts to 10 MByte (of ~110 MByte): $> rpm -qa --queryformat '[%{FILECLASS}\n]\n' | wc -c 274963 1327919 10743024 Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 29.01.19 um 12:43 schrieb Thorsten Kukuk:

*we* have btrfs snapshots by default.

So openSUSE is only for Torsten Kukuk and Ludwig Nussel nowadays? Or who is this "we"? Using a safe file system is no longer supported? -- 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

On Tue, Jan 29, Stefan Seyfried wrote:

Am 29.01.19 um 12:43 schrieb Thorsten Kukuk:

...

*we* have btrfs snapshots by default.

So openSUSE is only for Torsten Kukuk and Ludwig Nussel nowadays? Or who is this "we"?

Sorry Stefan, but your tone is absolute not appropriate here. btrfs is the default filesystem for a default openSUSE Tumbleweed installation, which means whoever is doing a default openSUSE Tumbleweeed installation has snapshots by default. So openSUSE Tumbleweed as btrfs snapshots by default, exactly as I wrote. Not Thorsten and not Ludwig. If you like it or not. Between, the next time you attack persons personally, you should at least try to write their names correct ... And before the next complain is coming from you that this is all my fault that we have btrfs as default: I was not involved in the decission to use btrfs as default filesystem for any product except MicroOS.

Using a safe file system is no longer supported?

Please stop complaining but read exactly what I wrote. Then you would see that it is nonsense what you write here. Not amused, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 1/29/19 8:59 PM, Thorsten Kukuk wrote:

On Tue, Jan 29, Stefan Seyfried wrote:

...

Am 29.01.19 um 12:43 schrieb Thorsten Kukuk:

...

*we* have btrfs snapshots by default.

So openSUSE is only for Torsten Kukuk and Ludwig Nussel nowadays? Or who is this "we"?

Sorry Stefan, but your tone is absolute not appropriate here.

While I don't always agree with other posters in this thread I have to speak up here. The word "we" used by you and Ludwig indeed sounded somewhat excluding to those who chose not to use btrfs (also me). I share the concerns that the decision for btrfs installed as default with its snapshot feature too easily leads to other design assumptions/decisions conflicting with what a significant set of community members want. And no, I don't want to start a discussion about file systems. The point is that some concerns raised are often not taken serious enough.

And before the next complain is coming from you that this is all my fault that we have btrfs as default:

Personally I did not read such a complain yet. Ciao, Michael.

Am 29.01.19 um 12:06 schrieb Ludwig Nussel:

Michael Schroeder schrieb:

...

On Tue, Jan 29, 2019 at 11:49:38AM +0100, Ludwig Nussel wrote:

...

Axel Braun schrieb:

...

[...] Raspi are heavily depending on the kind of 'hard disk' you are using, whether it is a SD card (connected via USB2) or an internal SSD Here is the result of a Raspi using a Leap 15 LXQT image:

/home/test # systemd-analyze blame       1min 30.071s display-manager.service       1min 18.481s backup-rpmdb.service

Did anyone ever rely on that rpm database backup the last decade?

It's you last hope if your rpm database gets corrupt.

The question is if that still happens, it's not 1996 anymore :-) Also we have btrfs snapshots by default that include the rpm DB.

If you care about boot time, getting rid of BTRFS ist a better way. backup-rpmdb is a systemd timer, that all expired timers apparently run on boot immediately is a problem to be solved in systemd IMHO. That this happens on raspi on every boot is probably due to the lack of a hardware clock => again, a systemd problem to be solved there. Just converting them back to cron.daily scripts will nicely resolve this.

...

...

Maybe it's time to retire that service?

Please don't. But wan't this about boot times? The rpmdb backup is not a boot time service, is it?

It is, that's why it sucks even more :-)

No, it isn't.

...

And note that the script currently caluclates the md5 of the packages file. It's probably enough to check if the size/mtime/inode has changed or not.

Not sure if that helps. In the end the DB (several hundred megabytes) has to be copied which is slow on rotating disks and SD cards like on ARM.

Which does not matter at all if it runs with low (IO and cpu) priority and not during the boot process. The btrfs-scrub job, which runs on every boot on the only machine I have that has btrfs (on a slow rotating rust storage) is much worse than the rpmdb backup. -- 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

Thorsten Kukuk schrieb:

On Tue, Jan 29, Michael Schroeder wrote:

...

On Tue, Jan 29, 2019 at 11:49:38AM +0100, Ludwig Nussel wrote:

...

Axel Braun schrieb:

...

[...] Raspi are heavily depending on the kind of 'hard disk' you are using, whether it is a SD card (connected via USB2) or an internal SSD Here is the result of a Raspi using a Leap 15 LXQT image:

/home/test # systemd-analyze blame 1min 30.071s display-manager.service 1min 18.481s backup-rpmdb.service

Did anyone ever rely on that rpm database backup the last decade?

It's you last hope if your rpm database gets corrupt.

For this we have btfrs snapshots and/or transactional-updates ;)

...

...

Maybe it's time to retire that service?

Please don't. But wan't this about boot times? The rpmdb backup is not a boot time service, is it?

It is: [Timer] Persistent=true

Persistent=true has really bad sideeffects, I removed it meanwhile from my timers everywhere.

Well, not everywhere as backup-rpmdb.timer still has it :-) Mind catching up on it? Are there any other side effects besides firing at system boot? 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

On Tue, 29 Jan 2019 at 14:01, Ludwig Nussel wrote:

...

...

Please don't. But wan't this about boot times? The rpmdb backup is not a boot time service, is it?

It is: [Timer] Persistent=true

Persistent=true has really bad sideeffects, I removed it meanwhile from my timers everywhere.

Well, not everywhere as backup-rpmdb.timer still has it :-) Mind catching up on it? Are there any other side effects besides firing at system boot?

If you have a number of persistent timers and they all didn't run at their regular assigned times, then your boot suddenly has ALL of them running at that boot The combined impact of stuff like btrfs-balance, fstrim, and backup-rpm DB all running at once can be very painful for many machines A judgement call has to be made - persistent=true should only be set on timers that absolutely, positively must run as close as possible to the desired time interval. I would argue for anything that can be described as a 'nice to have maintenance cleanup', then "old-fashioned" cron-like behaviour of "if I wasn't booted when I should have run, I'll run it at my regular time next time" is better for many of the things we're talking about here. But, ultimately, for backup-rpmdb, I think it's bonkers we're still running it at all - our default btrfs snapshots take care of that and for anyone who neglects to use that feature, they really should be taking their own backups of /usr/lib/sysimage just as they should of /etc and any user data in /srv or /var they care about. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2019-01-29 14:32, Richard Brown wrote:

...

Well, not everywhere as backup-rpmdb.timer still has it :-) Mind catching up on it? Are there any other side effects besides firing at system boot?

If you have a number of persistent timers and they all didn't run at their regular assigned times, then your boot suddenly has ALL of them running at that boot

The combined impact of stuff like btrfs-balance, fstrim, and backup-rpm DB all running at once can be very painful for many machines

Sounds like a design flaw. systemd ought to have an option to run belated timers in sequence. Or perhaps all timers in a certain "group". I still remember the days when (unprivileged) users of a classic multi-user server, able via `crontab -e`, all started their nightly stuff at the same time at 02:00. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2019-01-29 17:28, Richard Brown wrote:

https://www.freedesktop.org/software/systemd/man/systemd.timer.html RandomizedDelaySec= can be a help for that problem

But I'm reasonably confident that persistent= doesn't honour it..after all, the whole point of Persistent= is "you missed your scheduled run, I'll run it now!"

You can't squeeze a late train into an occupied platform, even Deutsche Bahn knows that ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org