[opensuse] zypper dup very busy defragging btrfs, when there is nobtrfs partition...
Hi, zypper dup of one 42.3 system to 15.0 on a VBox guest. After this question: 1904 packages to upgrade, 607 to downgrade, 762 new, 291 to remove, 8 to change vendor, 8 to change arch. Overall download size: 1.97 GiB. Already cached: 0 B. After the operation, additional 1.3 GiB will be used. Continue? [y/n/...? shows all options] (y): Do you agree with the terms of the license? [yes/no] (no): yes The system gets busy for minutes with snapper.py, and later with btrfs-defrag-pl, but there are no btrfs partitions at all: lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL, NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL sda sda 512 0 0 20G disk ├─sda1 sda1 512 0 0 7M part ├─sda2 sda2 512 0 0 4G part swap swap_1 ├─sda3 sda3 512 0 0 10G part ext4 Main └─sda4 sda4 512 0 0 6G part xfs Home sdb sdb 512 0 0 20G disk ├─sdb1 sdb1 512 0 0 4G part swap swap_2 ├─sdb2 sdb2 512 0 0 12G part ext4 Usr └─sdb3 sdb3 512 0 0 4G part crypto_LUKS └─cr_sdb3 dm-0 512 0 0 4G crypt xfs sdc sdc 512 0 0 20G disk └─sdc1 sdc1 512 0 0 4.9G part reiserfs Reiserfs I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Thu, Jun 7, 2018 at 2:37 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Hi,
zypper dup of one 42.3 system to 15.0 on a VBox guest.
After this question:
1904 packages to upgrade, 607 to downgrade, 762 new, 291 to remove, 8 to change vendor, 8 to change arch. Overall download size: 1.97 GiB. Already cached: 0 B. After the operation, additional 1.3 GiB will be used. Continue? [y/n/...? shows all options] (y): Do you agree with the terms of the license? [yes/no] (no): yes
The system gets busy for minutes with snapper.py, and later with btrfs-defrag-pl, but there are no btrfs partitions at all:
lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,
NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL sda sda 512 0 0 20G disk ├─sda1 sda1 512 0 0 7M part ├─sda2 sda2 512 0 0 4G part swap swap_1 ├─sda3 sda3 512 0 0 10G part ext4 Main └─sda4 sda4 512 0 0 6G part xfs Home sdb sdb 512 0 0 20G disk ├─sdb1 sdb1 512 0 0 4G part swap swap_2 ├─sdb2 sdb2 512 0 0 12G part ext4 Usr └─sdb3 sdb3 512 0 0 4G part crypto_LUKS └─cr_sdb3 dm-0 512 0 0 4G crypt xfs sdc sdc 512 0 0 20G disk └─sdc1 sdc1 512 0 0 4.9G part reiserfs Reiserfs
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
we had like many posts on the list complaining about this stuff already, only apparently rarely ever any officials or in charge care also look at your diagram, where do you see any btrfs fs there? why is the command or the tool even called btrfs when it runs for nonbtrfs people? or why does it run and eat resources when there is no btrfs fs around? what does it do? sell your cpu cycles to your power company? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op donderdag 7 juni 2018 14:37:03 CEST schreef Carlos E. R.:
Hi,
zypper dup of one 42.3 system to 15.0 on a VBox guest.
After this question:
1904 packages to upgrade, 607 to downgrade, 762 new, 291 to remove, 8 to change vendor, 8 to change arch. Overall download size: 1.97 GiB. Already cached: 0 B. After the operation, additional 1.3 GiB will be used. Continue? [y/n/...? shows all options] (y): Do you agree with the terms of the license? [yes/no] (no): yes
The system gets busy for minutes with snapper.py, and later with btrfs-defrag-pl, but there are no btrfs partitions at all:
lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,
NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL sda sda 512 0 0 20G disk ├─sda1 sda1 512 0 0 7M part ├─sda2 sda2 512 0 0 4G part swap swap_1 ├─sda3 sda3 512 0 0 10G part ext4 Main └─sda4 sda4 512 0 0 6G part xfs Home sdb sdb 512 0 0 20G disk ├─sdb1 sdb1 512 0 0 4G part swap swap_2 ├─sdb2 sdb2 512 0 0 12G part ext4 Usr └─sdb3 sdb3 512 0 0 4G part crypto_LUKS └─cr_sdb3 dm-0 512 0 0 4G crypt xfs sdc sdc 512 0 0 20G disk └─sdc1 sdc1 512 0 0 4.9G part reiserfs Reiserfs
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU. Deserves a bug report IMO. If there is no btrfs, I don't see the reason to execute the btrfs tools.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, 7 June 2018 22:29:31 ACST Knurpht @ openSUSE wrote: [...]
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
Deserves a bug report IMO. If there is no btrfs, I don't see the reason to execute the btrfs tools.
If there is no btrfs partition, I don't understand why btrfs tools should even be installed, except that the btrfsprogs package seems to be a dependency for GParted (why?), so I can't get rid of them without losing GParted. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rodney Baker wrote:
On Thursday, 7 June 2018 22:29:31 ACST Knurpht @ openSUSE wrote: [...]
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
Deserves a bug report IMO. If there is no btrfs, I don't see the reason to execute the btrfs tools.
If there is no btrfs partition, I don't understand why btrfs tools should even be installed, except that the btrfsprogs package seems to be a dependency for GParted (why?),
probably to understand that filesystem? btrfs tools are installed as part of the pattern, perfectly normal. -- Per Jessen, Zürich (24.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/06/18 10:22 AM, Rodney Baker wrote:
If there is no btrfs partition, I don't understand why btrfs tools should even be installed, except that the btrfsprogs package seems to be a dependency for GParted (why?), so I can't get rid of them without losing GParted.
Perhaps that too is a bug? But then ... On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted. This my be sufficient but it it is not necessary. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 04:25, Anton Aylward wrote:
On 07/06/18 10:22 AM, Rodney Baker wrote:
If there is no btrfs partition, I don't understand why btrfs tools should even be installed, except that the btrfsprogs package seems to be a dependency for GParted (why?), so I can't get rid of them without losing GParted.
Perhaps that too is a bug?
But then ... On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted. This my be sufficient but it it is not necessary.
No, it is a missing feature :-) The program may be modular and ask you to install other modules at run time if you request do something on a filesystem that it doesn't support with the installed software (maybe recommending them at install time), or may depend on them all at install time. It is a design choice, not a bug. Maybe you can install it with broken deps and try. See what happens when there is a non supported partition type. Does it handle the situation nicely? Then dependencies can be changed to recommends. Me, I like it supporting all possible types from the first minute. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Anton Aylward wrote:
On 07/06/18 10:22 AM, Rodney Baker wrote:
If there is no btrfs partition, I don't understand why btrfs tools should even be installed, except that the btrfsprogs package seems to be a dependency for GParted (why?), so I can't get rid of them without losing GParted.
Perhaps that too is a bug?
But then ... On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted.
Yes, I think you're right Anton - gparted manages quite well with other filesystems, without explicitly pulling in their respective tools and/or libaries. -- Per Jessen, Zürich (18.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted. This my be sufficient but it it is not necessary.
TBH, I would really be pissed off if I installed GParted, try to run it on my system - only to get (at best) an info box telling me 'Oh, for *this* to work you also have to install <bla>....' GParted is a toolbox, and I don't want to buy every wrench in that box separate. Because the moment you need it will be the one the shop is closed (i.e., you're not online to get that package) .... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 12:18, Peter Suetterlin wrote:
Anton Aylward wrote:
On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted. This my be sufficient but it it is not necessary.
TBH, I would really be pissed off if I installed GParted, try to run it on my system - only to get (at best) an info box telling me 'Oh, for *this* to work you also have to install <bla>....'
GParted is a toolbox, and I don't want to buy every wrench in that box separate. Because the moment you need it will be the one the shop is closed (i.e., you're not online to get that package) ....
Same here... -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Friday, 8 June 2018 20:10:39 ACST Carlos E. R. wrote:
On 2018-06-08 12:18, Peter Suetterlin wrote:
Anton Aylward wrote:
On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted. This my be sufficient but it it is not necessary.
TBH, I would really be pissed off if I installed GParted, try to run it on my system - only to get (at best) an info box telling me 'Oh, for *this* to work you also have to install <bla>....'
GParted is a toolbox, and I don't want to buy every wrench in that box separate. Because the moment you need it will be the one the shop is closed (i.e., you're not online to get that package) ....
Same here...
Personally, I don't have btrfs partitions, I don't want btrfs partitions and I never, ever intend to install btrfs on any hardware that I am responsible for, so I'd rather not have btrfsprogs installed either, but that's just personal preference - I like to be able uninstall unnecessary crud and keep only what's really needed. That reduces the size of updates, too - no need to download 100's of MB of stuff for packages that are never used. Not everyone has big pipes to the internet. Yes, I know btrfsprogs is not that big, but all the little bits add up. I'd much rather have recommends than hard dependencies if possible. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/08/2018 08:52 AM, Rodney Baker wrote:
Personally, I don't have btrfs partitions, I don't want btrfs partitions and I never, ever intend to install btrfs on any hardware that I am responsible for, so I'd rather not have btrfsprogs installed either, but that's just personal preference - I like to be able uninstall unnecessary crud and keep only what's really needed.
That reduces the size of updates, too - no need to download 100's of MB of stuff for packages that are never used. Not everyone has big pipes to the internet. Yes, I know btrfsprogs is not that big, but all the little bits add up. I'd much rather have recommends than hard dependencies if possible.
What was the original Linux philosophy? (Oh, yes, I remember...) Many small tools doing a single job -- and doing it well. The argument for Gparted and the btrfs addons -- "it's in the kernel", the argument against "like rodney said -- never ever ever.." -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/06/18 06:18 AM, Peter Suetterlin wrote:
Anton Aylward wrote:
On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted. This my be sufficient but it it is not necessary.
TBH, I would really be pissed off if I installed GParted, try to run it on my system - only to get (at best) an info box telling me 'Oh, for *this* to work you also have to install <bla>....'
GParted is a toolbox, and I don't want to buy every wrench in that box separate. Because the moment you need it will be the one the shop is closed (i.e., you're not online to get that package) ....
I don't think that will happen, certainly not if you use Yast or Zypper to install GParted. As far as I can see looking at the package spec, there are mandated dependencies. When you install GParted using YastZypper it will drag in those other "wrenches" whether you like it or not, whether you use those file systems or not. THAT is what I object to. If the installer was smart enough to recognise what file systems ytou did have configured and brought those "wrenches" in, that another matter. If you start using another file system then I would expect that in order to administer it you would bring in the necessary toolbox to support it, and that includes what GParted would see the wrenches now needed. Surely the RPM system has this capability? Surely dependencies aren't an all or nothing matter? I do see your point about not always being online, but then again, wearing my sysadmin hat, I can't see starting to use a new type of FS without the supporting tools to manage it. And I don't see why things I'm never going to use are forced upon me. What scares me is that logical consequence of mandating stuff like this, even if it is never going to be used, is that it is going to be simpler to just load everything in all the repositories that you have configured, regardless. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8 June 2018 at 16:29, Anton Aylward <opensuse@antonaylward.com> wrote:
On 08/06/18 06:18 AM, Peter Suetterlin wrote:
Anton Aylward wrote:
On 07/06/18 10:43 AM, Per Jessen wrote:
probably to understand that filesystem?
If that is the case and that is hard wired into GParted then I think there is a bug in the architecture of the modularity of GParted. This my be sufficient but it it is not necessary.
TBH, I would really be pissed off if I installed GParted, try to run it on my system - only to get (at best) an info box telling me 'Oh, for *this* to work you also have to install <bla>....'
GParted is a toolbox, and I don't want to buy every wrench in that box separate. Because the moment you need it will be the one the shop is closed (i.e., you're not online to get that package) ....
I don't think that will happen, certainly not if you use Yast or Zypper to install GParted. As far as I can see looking at the package spec, there are mandated dependencies. When you install GParted using YastZypper it will drag in those other "wrenches" whether you like it or not, whether you use those file systems or not.
THAT is what I object to. If the installer was smart enough to recognise what file systems ytou did have configured and brought those "wrenches" in, that another matter.
If you start using another file system then I would expect that in order to administer it you would bring in the necessary toolbox to support it, and that includes what GParted would see the wrenches now needed.
Surely the RPM system has this capability? Surely dependencies aren't an all or nothing matter?
I do see your point about not always being online, but then again, wearing my sysadmin hat, I can't see starting to use a new type of FS without the supporting tools to manage it. And I don't see why things I'm never going to use are forced upon me.
What scares me is that logical consequence of mandating stuff like this, even if it is never going to be used, is that it is going to be simpler to just load everything in all the repositories that you have configured, regardless.
gparted requires a whole bunch of tools regardless of whether or not they're used by a system e2fsprogs xfsprogs jfsutils hfsutils nilfs-utils ntfsprogs btrfsprogs If you removed all of them gparted would be rather useless.. And there is no magic RPM dependency flag that lets RPM psychically know all the filesystems that you have (or more importantly, going to have) on your system Especially in the era of NAS', SANs' and software defined storage where block devices (with whatever filesystems contained within) could be dissapearing and reappearing at a whim Your 'sysadmin hat' sounds old and moth eaten - we're in more and more of a devops world where a single sysadmin is unlikely to be in total control of what their developers & users are connecting to your servers, VMs, cloud guests, or containers. I think in that case it most certainly makes good sensible engineering sense to have a system that could handle all supported filesystems And in the case of btrfs, it's the default and the recommended for the root filesystem for openSUSE, so it would be insane to make it an optional dependency even if there was magic RPM filesystems-in-use & filesystems-in-future flags -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, 9 June 2018 0:23:29 ACST Richard Brown wrote:
[...]
If you start using another file system then I would expect that in order to administer it you would bring in the necessary toolbox to support it, and that includes what GParted would see the wrenches now needed.
Surely the RPM system has this capability? Surely dependencies aren't an all or nothing matter?
I do see your point about not always being online, but then again, wearing my sysadmin hat, I can't see starting to use a new type of FS without the supporting tools to manage it. And I don't see why things I'm never going to use are forced upon me.
What scares me is that logical consequence of mandating stuff like this, even if it is never going to be used, is that it is going to be simpler to just load everything in all the repositories that you have configured, regardless.
gparted requires a whole bunch of tools regardless of whether or not they're used by a system e2fsprogs xfsprogs jfsutils hfsutils nilfs-utils ntfsprogs btrfsprogs
If you removed all of them gparted would be rather useless..
And there is no magic RPM dependency flag that lets RPM psychically know all the filesystems that you have (or more importantly, going to have) on your system
Especially in the era of NAS', SANs' and software defined storage where block devices (with whatever filesystems contained within) could be dissapearing and reappearing at a whim
Your 'sysadmin hat' sounds old and moth eaten - we're in more and more of a devops world where a single sysadmin is unlikely to be in total control of what their developers & users are connecting to your servers, VMs, cloud guests, or containers.
I think in that case it most certainly makes good sensible engineering sense to have a system that could handle all supported filesystems
And in the case of btrfs, it's the default and the recommended for the root filesystem for openSUSE, so it would be insane to make it an optional dependency even if there was magic RPM filesystems-in-use & filesystems-in-future flags
I think you missed the point. When you **install** btrfs it should bring in the tools i.e. btrfsprogs should be dependency of btrfs, not gparted (and the same applies to other fs's), and it should be possible to install a system without it (i.e. to choose what filesystems and associated tools are installed or not). I would very much like to remove all traces of btrfs from all of my systems - I detest it! The day I'm forced to use it will be the day I switch distros, before I end up with an unbootable and unrecoverable system again. I don't trust btrfs, and I don't think I ever will after previous experiences. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 17:38, Rodney Baker wrote:
On Saturday, 9 June 2018 0:23:29 ACST Richard Brown wrote:
[...]
If you start using another file system then I would expect that in order to administer it you would bring in the necessary toolbox to support it, and that includes what GParted would see the wrenches now needed.
Surely the RPM system has this capability? Surely dependencies aren't an all or nothing matter?
I do see your point about not always being online, but then again, wearing my sysadmin hat, I can't see starting to use a new type of FS without the supporting tools to manage it. And I don't see why things I'm never going to use are forced upon me.
What scares me is that logical consequence of mandating stuff like this, even if it is never going to be used, is that it is going to be simpler to just load everything in all the repositories that you have configured, regardless.
gparted requires a whole bunch of tools regardless of whether or not they're used by a system e2fsprogs xfsprogs jfsutils hfsutils nilfs-utils ntfsprogs btrfsprogs
If you removed all of them gparted would be rather useless..
And there is no magic RPM dependency flag that lets RPM psychically know all the filesystems that you have (or more importantly, going to have) on your system
Especially in the era of NAS', SANs' and software defined storage where block devices (with whatever filesystems contained within) could be dissapearing and reappearing at a whim
Your 'sysadmin hat' sounds old and moth eaten - we're in more and more of a devops world where a single sysadmin is unlikely to be in total control of what their developers & users are connecting to your servers, VMs, cloud guests, or containers.
I think in that case it most certainly makes good sensible engineering sense to have a system that could handle all supported filesystems
And in the case of btrfs, it's the default and the recommended for the root filesystem for openSUSE, so it would be insane to make it an optional dependency even if there was magic RPM filesystems-in-use & filesystems-in-future flags
I think you missed the point. When you **install** btrfs it should bring in the tools i.e. btrfsprogs should be dependency of btrfs, not gparted (and the same applies to other fs's), and it should be possible to install a system without it (i.e. to choose what filesystems and associated tools are installed or not).
But you don't "install" btrfs. You partition a disk as btrfs, or as something else. At the time of formatting, the tools must be available - so you need btrfs tools before. What you ask is rather more complex to implement. It could be the YaST partitioner module that somehow ASKS the package management module to install the rpm for the filesystems it created, later during the installation. I doubt this hook exist, and it would be complext to do. But the packager module would also have to scan all the existing disks in the computer to find out what filesystems are there already, plus those that are going to be created, and then decide what modules to install. I'll put my old, moth eaten dev hat on for a while, and I'll say, I'm not coding that. Little gain and a lot of effort :-P But surely they'll be happy to accept your contributed code to do it ;-) And mind, like you I'm not going to use btrfs anytime soon. But removing those tools automatically is far from easy. Maybe it would be possible to delete them after installation, if they are not flagged hard deps. I understand that nobody so far has come with a way of doing that - see <https://bugzilla.opensuse.org/show_bug.cgi?id=953131> for instance. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 08/06/18 12:51 PM, Carlos E. R. wrote:
But you don't "install" btrfs. You partition a disk as btrfs, or as something else. At the time of formatting, the tools must be available - so you need btrfs tools before.
I think you are missing the point that Rodney and I ar tying to make. Yes, if I want to set up a partiution to use a spcifi tytpe of FS I'll install the toolkit for administering that. So what? I don't use BtrFS so I don't have that toolkit. Without that toolkit I can't mkfs.btrfs anyway # mkfs.btrfs If 'mkfs.btrfs' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf mkfs.btrfs main:~ # cnf mkfs.btrfs The program 'mkfs.btrfs' can be found in following packages: * btrfsprogs [ path: /sbin/mkfs.btrfs, repository: zypp (repo-oss) ] * btrfsprogs [ path: /usr/sbin/mkfs.btrfs, repository: zypp (repo-oss) ] ] Try installing with: zypper install btrfsprogs So your point is a bit off the mark.
What you ask is rather more complex to implement. It could be the YaST partitioner module that somehow ASKS the package management module to install the rpm for the filesystems it created, later during the installation. I doubt this hook exist, and it would be complext to do.
I don't think so. There are many things I've done with Yast where it has asked me to install a package. Seeing what FS you have available is easy enough: # cat /proc/filesystems | egrep -v nodev -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op vrijdag 8 juni 2018 17:38:55 CEST schreef Rodney Baker:
On Saturday, 9 June 2018 0:23:29 ACST Richard Brown wrote:
[...]
If you start using another file system then I would expect that in order to administer it you would bring in the necessary toolbox to support it, and that includes what GParted would see the wrenches now needed.
Surely the RPM system has this capability? Surely dependencies aren't an all or nothing matter?
I do see your point about not always being online, but then again, wearing my sysadmin hat, I can't see starting to use a new type of FS without the supporting tools to manage it. And I don't see why things I'm never going to use are forced upon me.
What scares me is that logical consequence of mandating stuff like this, even if it is never going to be used, is that it is going to be simpler to just load everything in all the repositories that you have configured, regardless.
gparted requires a whole bunch of tools regardless of whether or not they're used by a system e2fsprogs xfsprogs jfsutils hfsutils nilfs-utils ntfsprogs btrfsprogs
If you removed all of them gparted would be rather useless..
And there is no magic RPM dependency flag that lets RPM psychically know all the filesystems that you have (or more importantly, going to have) on your system
Especially in the era of NAS', SANs' and software defined storage where block devices (with whatever filesystems contained within) could be dissapearing and reappearing at a whim
Your 'sysadmin hat' sounds old and moth eaten - we're in more and more of a devops world where a single sysadmin is unlikely to be in total control of what their developers & users are connecting to your servers, VMs, cloud guests, or containers.
I think in that case it most certainly makes good sensible engineering sense to have a system that could handle all supported filesystems
And in the case of btrfs, it's the default and the recommended for the root filesystem for openSUSE, so it would be insane to make it an optional dependency even if there was magic RPM filesystems-in-use & filesystems-in-future flags
I think you missed the point. When you **install** btrfs it should bring in the tools i.e. btrfsprogs should be dependency of btrfs, not gparted (and the same applies to other fs's), and it should be possible to install a system without it (i.e. to choose what filesystems and associated tools are installed or not).
It is possible, no doubt. And doing that for other FS's you don't use yourself brings back the olden days, where machines could only read the FS's it used itself, i.e. NTFS and FAT.
I would very much like to remove all traces of btrfs from all of my systems - I detest it! The day I'm forced to use it will be the day I switch distros, before I end up with an unbootable and unrecoverable system again.
I don't trust btrfs, and I don't think I ever will after previous experiences.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/06/18 10:53 AM, Richard Brown wrote:
If you removed all of them gparted would be rather useless..
You are being quite ridiculous, Richard. That's like saying removing all the drivers under /lib/modules/*/kernel/fs Quite obviously you would never do that. You would install the toolkits that are relevant to the file systems that you do use AND ONLY THOSE. In fact that's what I do. Very specifically that's what I do. e2fsprogs-1.44.2-107.1.x86_64 package xfsprogs is not installed jfsutils-1.1.15-27.1.x86_64 package hfsutils is not installed package nilfs-utils is not installed ntfsprogs-2017.3.23-53.1.x86_64 package btrfsprogs is not installed I also have reiserfs-3.6.27-59.1 And yes, I don't have GParted. More inadequate design that would bring in more unnecessary bloat. Why should I use GParted to shuffle partitions back and forth when I can use the immensely more flexible and capable LVM? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 23:11, Anton Aylward wrote:
On 08/06/18 10:53 AM, Richard Brown wrote:
If you removed all of them gparted would be rather useless..
You are being quite ridiculous, Richard. That's like saying removing all the drivers under /lib/modules/*/kernel/fs
Quite obviously you would never do that. You would install the toolkits that are relevant to the file systems that you do use AND ONLY THOSE.
Well, no, the kernel has modules for absolutely everything. It looks if you have them at run time, not install time.
And yes, I don't have GParted. More inadequate design that would bring in more unnecessary bloat.
Why should I use GParted to shuffle partitions back and forth when I can use the immensely more flexible and capable LVM?
Because it is a very good partitioner that handles about everytype of disk. Even LVM! You don't like it, don't install it. But then, you have yast and its partitioner, which also probably requires all supported filesystem type tools. The distribution has to carry generic cases for most people, not particular cases. That's up to you. So yes, by default all filesystems are supported, even those you do not use. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 08/06/18 05:21 PM, Carlos E. R. wrote:
On 2018-06-08 23:11, Anton Aylward wrote:
On 08/06/18 10:53 AM, Richard Brown wrote:
If you removed all of them gparted would be rather useless..
You are being quite ridiculous, Richard. That's like saying removing all the drivers under /lib/modules/*/kernel/fs
Quite obviously you would never do that. You would install the toolkits that are relevant to the file systems that you do use AND ONLY THOSE.
Well, no, the kernel has modules for absolutely everything. It looks if you have them at run time, not install time.
Just as I could 'zypper rm' the kits for any FS I don't want to use (such as BtrFS) I can remove the unwanted entries from /lib/modules/*/kernel/fs if I want. That they *ALL* get dragged in whether I want them or not just further illustrates the point Rodney and I are trying to make. I run 'bleachbit' occasionally. One thing it can do is removed unwanted localizations, language files for languages I don't use. Even so, there are Dot-desktop files that are bloated with unused, unwanted language entries that bleachbit can't clean out. Perhaps a later, more sophisticated version will do that.
And yes, I don't have GParted. More inadequate design that would bring in more unnecessary bloat.
Why should I use GParted to shuffle partitions back and forth when I can use the immensely more flexible and capable LVM?
Because it is a very good partitioner that handles about everytype of disk. Even LVM!
Again, you are missing the point. With LVM I don't need any of the partition tools such as GParted. I use 'pvcreate'.
From the man page:
pvcreate initializes PhysicalVolume for later use by the Logical Volume Manager (LVM). Each PhysicalVolume can be a disk partition, whole disk, meta device, or loopback file. For DOS disk partitions, the partition id should be set to 0x8e using fdisk(8), cfdisk(8), or a equivalent. For whole disk devices only the partition table must be erased, which will effectively destroy all data on that disk. Note that: "... whole disk..." and "... partition table must be erased..." And yes, you can do the same with BtrFS, the "One FileSystem To Rule Them All", and, as I understand it, ZFS. "It is not necessary nor recommended to partition the drives before creating the zfs filesystem." All in all, the way computing is going, the old concept of partitioning a drive in order to mount a file system is falling by the wayside. I suspect that before long we will see a Linux distribution that doesn't have the extFS built in to the distributed kernel. It is possible that Leap 18 differentiates from Redhat & Fedora be dropping the compiled in ext4 and using a compiled in BtrFS, to orient itself more to the needs of 'commercial' customers. At that point it may also presume to do away with partitioning as we are doing it right now.
You don't like it, don't install it. But then, you have yast and its partitioner, which also probably requires all supported filesystem type tools.
I don't like, I don't install it and I run YaST, occasionally, quite happily,, without it. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 23:50, Anton Aylward wrote:
On 08/06/18 05:21 PM, Carlos E. R. wrote:
On 2018-06-08 23:11, Anton Aylward wrote:
On 08/06/18 10:53 AM, Richard Brown wrote:
If you removed all of them gparted would be rather useless..
You are being quite ridiculous, Richard. That's like saying removing all the drivers under /lib/modules/*/kernel/fs
Quite obviously you would never do that. You would install the toolkits that are relevant to the file systems that you do use AND ONLY THOSE.
Well, no, the kernel has modules for absolutely everything. It looks if you have them at run time, not install time.
Just as I could 'zypper rm' the kits for any FS I don't want to use (such as BtrFS) I can remove the unwanted entries from /lib/modules/*/kernel/fs if I want. That they *ALL* get dragged in whether I want them or not just further illustrates the point Rodney and I are trying to make.
I run 'bleachbit' occasionally. One thing it can do is removed unwanted localizations, language files for languages I don't use. Even so, there are Dot-desktop files that are bloated with unused, unwanted language entries that bleachbit can't clean out. Perhaps a later, more sophisticated version will do that.
But I don't. I usually don't care. Disks are big, no need to trim.
And yes, I don't have GParted. More inadequate design that would bring in more unnecessary bloat.
Why should I use GParted to shuffle partitions back and forth when I can use the immensely more flexible and capable LVM?
Because it is a very good partitioner that handles about everytype of disk. Even LVM!
Again, you are missing the point. With LVM I don't need any of the partition tools such as GParted. I use 'pvcreate'. From the man page:
Why not, if you can use gparted instead? One tool to rule them all? :-P And then, inside the PVM big space there are smaller spaces that contain filesystems. One for root, another for home, another for swap... And you can do them with gparted. Guessing, I have not tried. Or with YAST. :-P -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
You don't like it, don't install it. But then, you have yast and its partitioner, which also probably requires all supported filesystem type tools.
YaST supports a limited set of filesystems. -- Per Jessen, Zürich (18.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-09 09:09, Per Jessen wrote:
Carlos E. R. wrote:
You don't like it, don't install it. But then, you have yast and its partitioner, which also probably requires all supported filesystem type tools.
YaST supports a limited set of filesystems.
Yes, all the supported. Reiserfs is not, for instance. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/08/2018 04:21 PM, Carlos E. R. wrote:
Well, no, the kernel has modules for absolutely everything. It looks if you have them at run time, not install time.
Well they have modules for all currently supported filesystems - zfs isn't there, but is regularly used. I would have to look further, but it sounds like btrfs doesn't just rely on a simple kernel module for providing a full interface to all filesystem parameters, but instead requires the kernel module "plus" additional tools to be able to manipulate it. gparted seems to be able to incorporate code to handle most filesystems on its own, but it looks like it is relying on the additional tools for btrfs to garner the needed info to do what it does. You would hope in the future as btrfs development settles down that the needed bits can be incorporated in gparted and do away with external dependencies (which would eliminate the dependency cruft for those who don't use it), but as btrfs has been a moving-target for the past couple of years, it probably just made sense to gparted to call external tools to gather whatever info it needed rather than committing to endlessly having to patch and support all the development changes to the btrfs code (and what version of btrfs was currently in use by distro X release Y, etc.). -- David C. Rankin, J.D.,P.E.
David C. Rankin wrote:
I would have to look further, but it sounds like btrfs doesn't just rely on a simple kernel module for providing a full interface to all filesystem parameters, but instead requires the kernel module "plus" additional tools to be able to manipulate it.
Which is really the same for all filesystems. They all have driver modules and tool sets. (which contain e.g. mkfs.<filesystem>).
gparted seems to be able to incorporate code to handle most filesystems on its own, but it looks like it is relying on the additional tools for btrfs to garner the needed info to do what it does.
gparted also requies toolset packages for the other filesystems - e.g. jfsutils, nilfs-utils, reiserfs, udftools, xfsprogs. What I don't like is that gparted drags along btrfsmaintenance, snapper, snapper-zypp-plugin, yast2-snapper unless you specify '--no-recommends'. -- Per Jessen, Zürich (20.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/18 03:34 AM, David C. Rankin wrote:
You would hope in the future as btrfs development settles down that the needed bits can be incorporated in gparted and do away with external dependencies (which would eliminate the dependency cruft for those who don't use it),
I think you miss my point. Having it built in to GParted means that if it is a FS that isn't in the set of built-in you have to have an external module for it anyway, so why not simplify and do the 'does one thing and only one thing' and make the GParted a zero-knowledge and load-on-demand. There are plenty of other applications, Yast being one, that do a 'load on demand'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, 9 June 2018 22:36:06 ACST Anton Aylward wrote:
On 09/06/18 03:34 AM, David C. Rankin wrote:
You would hope in the future as btrfs development settles down that the needed bits can be incorporated in gparted and do away with external dependencies (which would eliminate the dependency cruft for those who don't use it), I think you miss my point. Having it built in to GParted means that if it is a FS that isn't in the set of built-in you have to have an external module for it anyway, so why not simplify and do the 'does one thing and only one thing' and make the GParted a zero-knowledge and load-on-demand.
Precisely! The funny thing is, as far as I understand it GParted is a front- end to parted, yet btrfsprogs is **not** a dependency for parted, only Gparted. Maybe I'll dump it and reinstall with --no-recommends and see what happens. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/06/18 09:53 AM, Rodney Baker wrote:
Maybe I'll dump it and reinstall with --no-recommends and see what happens.
Alternatively you could dump it and convert to using LVM which is a lot easier. It also lets you resize tour "partitions", add or delete them without shutting down. Which is wonderful for a production server, a 7/24 machine. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op donderdag 7 juni 2018 14:59:31 CEST schreef Knurpht @ openSUSE:
Op donderdag 7 juni 2018 14:37:03 CEST schreef Carlos E. R.:
Hi,
zypper dup of one 42.3 system to 15.0 on a VBox guest.
After this question:
1904 packages to upgrade, 607 to downgrade, 762 new, 291 to remove, 8 to change vendor, 8 to change arch. Overall download size: 1.97 GiB. Already cached: 0 B. After the operation, additional 1.3 GiB will be used. Continue? [y/n/...? shows all options] (y): Do you agree with the terms of the license? [yes/no] (no): yes
The system gets busy for minutes with snapper.py, and later with btrfs-defrag-pl, but there are no btrfs partitions at all:
lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,
NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL sda sda 512 0 0 20G disk ├─sda1 sda1 512 0 0 7M part ├─sda2 sda2 512 0 0 4G part swap swap_1 ├─sda3 sda3 512 0 0 10G part ext4 Main └─sda4 sda4 512 0 0 6G part xfs Home sdb sdb 512 0 0 20G disk ├─sdb1 sdb1 512 0 0 4G part swap swap_2 ├─sdb2 sdb2 512 0 0 12G part ext4 Usr └─sdb3 sdb3 512 0 0 4G part crypto_LUKS
└─cr_sdb3 dm-0 512 0 0 4G crypt xfs
sdc sdc 512 0 0 20G disk └─sdc1 sdc1 512 0 0 4.9G part reiserfs Reiserfs
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
Deserves a bug report IMO. If there is no btrfs, I don't see the reason to execute the btrfs tools. Correcting myself here. It should be there, though not activated. Like on my laptop with only btrfs and ext4, reiserfstune etc. is installed.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-07 17:43, Knurpht @ openSUSE wrote:
Op donderdag 7 juni 2018 14:59:31 CEST schreef Knurpht @ openSUSE:
Op donderdag 7 juni 2018 14:37:03 CEST schreef Carlos E. R.:
Hi,
zypper dup of one 42.3 system to 15.0 on a VBox guest.
...
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
Deserves a bug report IMO. If there is no btrfs, I don't see the reason to execute the btrfs tools. Correcting myself here. It should be there, though not activated. Like on my laptop with only btrfs and ext4, reiserfstune etc. is installed.
Exactly. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 7 June 2018 at 14:37, Carlos E. R. <robin.listas@telefonica.net> wrote:
Hi,
zypper dup of one 42.3 system to 15.0 on a VBox guest.
After this question:
1904 packages to upgrade, 607 to downgrade, 762 new, 291 to remove, 8 to change vendor, 8 to change arch. Overall download size: 1.97 GiB. Already cached: 0 B. After the operation, additional 1.3 GiB will be used. Continue? [y/n/...? shows all options] (y): Do you agree with the terms of the license? [yes/no] (no): yes
The system gets busy for minutes with snapper.py, and later with btrfs-defrag-pl, but there are no btrfs partitions at all:
lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,
NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL sda sda 512 0 0 20G disk ├─sda1 sda1 512 0 0 7M part ├─sda2 sda2 512 0 0 4G part swap swap_1 ├─sda3 sda3 512 0 0 10G part ext4 Main └─sda4 sda4 512 0 0 6G part xfs Home sdb sdb 512 0 0 20G disk ├─sdb1 sdb1 512 0 0 4G part swap swap_2 ├─sdb2 sdb2 512 0 0 12G part ext4 Usr └─sdb3 sdb3 512 0 0 4G part crypto_LUKS └─cr_sdb3 dm-0 512 0 0 4G crypt xfs sdc sdc 512 0 0 20G disk └─sdc1 sdc1 512 0 0 4.9G part reiserfs Reiserfs
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
Very strange "btrfs-defrag-pl" probably related to "btrfs-defrag-plugin.py", which is provided by the btrfsmaintenance package No package requires btrfsmaintenance, but it is recommended by btrfsprogs and the minimal_base pattern The python script itself is a zypper plugin running after rpm commit, to defrag the rpmdb folder specifically The script itself checks that the filesystem containing the rpmdb is btrfs Snipping the relevant lines from the script: PATH=subprocess.check_output(["rpm", "--eval", "%_dbpath"], **popen_kwargs).strip() ... def fstype(path): ret=qx('stat -f --format=%T "'+path+'"') return ret.rstrip() ... if fstype(PATH) != 'btrfs': self.ack() return ... So the questions now are Q1 where does your system think it's rpmdb is located? Run "rpm --eval %_dbpath" to give the exact same answer that the script will get Q2 why does the script think it's btrfs? Run "stat -f --format=%T $ANSWER_TO_Q1" to give the exact same answer to the script Q3 if Q2 doesn't say it's btrfs, then you've found a legitimate bug with the plugin in the btrfsmaintenance package that justifies a bug report with this debugging information to make it very clear that the return isn't being called as expect when the filesystem is not btrfs -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-07 17:49, Richard Brown wrote:
On 7 June 2018 at 14:37, Carlos E. R. <robin.listas@telefonica.net> wrote:
Hi,
zypper dup of one 42.3 system to 15.0 on a VBox guest.
After this question:
1904 packages to upgrade, 607 to downgrade, 762 new, 291 to remove, 8 to change vendor, 8 to change arch. Overall download size: 1.97 GiB. Already cached: 0 B. After the operation, additional 1.3 GiB will be used. Continue? [y/n/...? shows all options] (y): Do you agree with the terms of the license? [yes/no] (no): yes
The system gets busy for minutes with snapper.py, and later with btrfs-defrag-pl, but there are no btrfs partitions at all:
lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,
NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL sda sda 512 0 0 20G disk ├─sda1 sda1 512 0 0 7M part ├─sda2 sda2 512 0 0 4G part swap swap_1 ├─sda3 sda3 512 0 0 10G part ext4 Main └─sda4 sda4 512 0 0 6G part xfs Home sdb sdb 512 0 0 20G disk ├─sdb1 sdb1 512 0 0 4G part swap swap_2 ├─sdb2 sdb2 512 0 0 12G part ext4 Usr └─sdb3 sdb3 512 0 0 4G part crypto_LUKS └─cr_sdb3 dm-0 512 0 0 4G crypt xfs sdc sdc 512 0 0 20G disk └─sdc1 sdc1 512 0 0 4.9G part reiserfs Reiserfs
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
Very strange
It is strange. I understant that the tool is installed and that it gets called, but should exit instantly.
"btrfs-defrag-pl" probably related to "btrfs-defrag-plugin.py", which is provided by the btrfsmaintenance package
Maybe the name got trimmed on the right side, I copy pasted from "top".
No package requires btrfsmaintenance, but it is recommended by btrfsprogs and the minimal_base pattern
The python script itself is a zypper plugin running after rpm commit, to defrag the rpmdb folder specifically
In this case, it ran before "zypper dup" starts the real job.
The script itself checks that the filesystem containing the rpmdb is btrfs
Snipping the relevant lines from the script:
PATH=subprocess.check_output(["rpm", "--eval", "%_dbpath"], **popen_kwargs).strip() ... def fstype(path): ret=qx('stat -f --format=%T "'+path+'"') return ret.rstrip() ... if fstype(PATH) != 'btrfs': self.ack() return ...
So the questions now are
Q1 where does your system think it's rpmdb is located? Run "rpm --eval %_dbpath" to give the exact same answer that the script will get
I'll find that out later, because now the upgrade to 15.0 finished. But it is a VM with a snapshot to revert to 42.3. We are investigating a crash in systemd while upgrading, and needs doing the upgrade several times to try catch a coredump and detailed logs (not yet successfully). So later I'll revert and find out where it was.
Q2 why does the script think it's btrfs? Run "stat -f --format=%T $ANSWER_TO_Q1" to give the exact same answer to the script
At this moment, after the upgrade finished (not yet rebooted): Eleanor-423:~ # rpm --eval %_dbpath /usr/lib/sysimage/rpm Eleanor-423:~ # stat -f --format=%T /usr/lib/sysimage/rpm ext2/ext3 Eleanor-423:~ #
Q3 if Q2 doesn't say it's btrfs, then you've found a legitimate bug with the plugin in the btrfsmaintenance package that justifies a bug report with this debugging information to make it very clear that the return isn't being called as expect when the filesystem is not btrfs
I'll tell you after reverting the upgrade. :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 2018-06-07 19:32, Carlos E. R. wrote:
On 2018-06-07 17:49, Richard Brown wrote:
On 7 June 2018 at 14:37, Carlos E. R. <> wrote:
Q3 if Q2 doesn't say it's btrfs, then you've found a legitimate bug with the plugin in the btrfsmaintenance package that justifies a bug report with this debugging information to make it very clear that the return isn't being called as expect when the filesystem is not btrfs
I'll tell you after reverting the upgrade. :-)
Eleanor-423:~ # rpm --eval %_dbpath /var/lib/rpm Eleanor-423:~ # stat -f --format=%T /var/lib/rpm ext2/ext3 Eleanor-423:~ # I'll report the bug later. I have to go out now. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 2018-06-07 20:33, Carlos E. R. wrote:
On 2018-06-07 19:32, Carlos E. R. wrote:
On 2018-06-07 17:49, Richard Brown wrote:
On 7 June 2018 at 14:37, Carlos E. R. <> wrote:
Q3 if Q2 doesn't say it's btrfs, then you've found a legitimate bug with the plugin in the btrfsmaintenance package that justifies a bug report with this debugging information to make it very clear that the return isn't being called as expect when the filesystem is not btrfs
I'll tell you after reverting the upgrade. :-)
Eleanor-423:~ # rpm --eval %_dbpath /var/lib/rpm Eleanor-423:~ # stat -f --format=%T /var/lib/rpm ext2/ext3 Eleanor-423:~ #
I'll report the bug later. I have to go out now.
Done. <https://bugzilla.opensuse.org/show_bug.cgi?id=1096589> -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 07/06/18 02:33 PM, Carlos E. R. wrote:
Eleanor-423:~ # rpm --eval %_dbpath /var/lib/rpm Eleanor-423:~ # stat -f --format=%T /var/lib/rpm ext2/ext3
HMM. I run those commands and get the exact same output. But there is a problem. The FS my /var is on is actually Ext4 It seems that 'stat' doesn't know about ext4 or cannot differentiate. It looks like you need to determine what device /var/lib/rpm is on then use something like 'lsblk' -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 04:53, Anton Aylward wrote:
On 07/06/18 02:33 PM, Carlos E. R. wrote:
Eleanor-423:~ # rpm --eval %_dbpath /var/lib/rpm Eleanor-423:~ # stat -f --format=%T /var/lib/rpm ext2/ext3
HMM. I run those commands and get the exact same output. But there is a problem. The FS my /var is on is actually Ext4 It seems that 'stat' doesn't know about ext4 or cannot differentiate.
It looks like you need to determine what device /var/lib/rpm is on then use something like 'lsblk'
Doesn't matter, it is not btrfs. Beyond that, it is for the devs at the other side of the Bugzilla to find out ;-) I have no idea why stat doesn't differentiate ext4. What's more, it doesn't differentiate ext2 from ext3 either. Not in my pay level :-P -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
* Anton Aylward <opensuse@antonaylward.com> [06-07-18 22:54]:
On 07/06/18 02:33 PM, Carlos E. R. wrote:
Eleanor-423:~ # rpm --eval %_dbpath /var/lib/rpm Eleanor-423:~ # stat -f --format=%T /var/lib/rpm ext2/ext3
HMM. I run those commands and get the exact same output. But there is a problem. The FS my /var is on is actually Ext4 It seems that 'stat' doesn't know about ext4 or cannot differentiate.
It looks like you need to determine what device /var/lib/rpm is on then use something like 'lsblk'
I do have btrfs and get: stat -f --format=%T /var/lib/rpm btrfs -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/07/2018 02:37 PM, Carlos E. R. wrote:
Hi,
zypper dup of one 42.3 system to 15.0 on a VBox guest.
After this question:
1904 packages to upgrade, 607 to downgrade, 762 new, 291 to remove, 8 to change vendor, 8 to change arch. Overall download size: 1.97 GiB. Already cached: 0 B. After the operation, additional 1.3 GiB will be used. Continue? [y/n/...? shows all options] (y): Do you agree with the terms of the license? [yes/no] (no): yes
The system gets busy for minutes with snapper.py, and later with btrfs-defrag-pl, but there are no btrfs partitions at all:
lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,
NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL sda sda 512 0 0 20G disk ├─sda1 sda1 512 0 0 7M part ├─sda2 sda2 512 0 0 4G part swap swap_1 ├─sda3 sda3 512 0 0 10G part ext4 Main └─sda4 sda4 512 0 0 6G part xfs Home sdb sdb 512 0 0 20G disk ├─sdb1 sdb1 512 0 0 4G part swap swap_2 ├─sdb2 sdb2 512 0 0 12G part ext4 Usr └─sdb3 sdb3 512 0 0 4G part crypto_LUKS └─cr_sdb3 dm-0 512 0 0 4G crypt xfs sdc sdc 512 0 0 20G disk └─sdc1 sdc1 512 0 0 4.9G part reiserfs Reiserfs
I can understand testing for btrfs then exiting, but it takes minutes at 100% CPU.
I'm not sure if any of the following ways is correct, but * on one of my systems, I have removed it via: $ zypper rm btrfsmaintenance && zypper al btrfsmaintenance * and on another system, the script exists pretty quick because of the setting in sysconfig: $ grep BTRFS_DEFRAG_PATHS /etc/sysconfig/btrfsmaintenance BTRFS_DEFRAG_PATHS="" * I think a third possibility could be (likewise for snapper-boot): $ systemctl disable btrfs-defrag.service Have a nice day, Berny
participants (11)
-
Anton Aylward -
Bernhard Voelker -
cagsm -
Carlos E. R. -
David C. Rankin -
Knurpht ＠ openSUSE -
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
Richard Brown -
Rodney Baker