Thanks! This works. I will try to tweak the config so it does not balloon like it did. For now I have resolved the issue using LVM, by shrinking /home and increasing / , but really snapshots should be trimmed here - the default number limit of 10 might be too much? On 13 November 2017 at 21:30, Mike Henry wrote:

Use snapper to mange the snapshots

"sudo snapper list" will list all of the snapshots. man snapper and sudo snapper help will provide some further guidance.

On Mon, Nov 13, 2017 at 2:18 PM, Mikhail Ramendik wrote:

...

Hello,

I trued to upgrade to 42.3 and the process failed because the root file system was full. df -h shows it full at 40 gigabytes.

But... with du, I can only find the usage of 15 gigabytes.

Moreover. I found 3 gigabytes in /root that could be deleted, and promptly deleted them. But df -h is not showing any more space! I am in the command line under root, no trash system anywhere.

I suspect snapshots are the problem, because I accepted the default of btrfs for the root filesystem. So I could just delete some old snapshots.

But how do I list the snapshots? And how do I remove them? Somehow when I google this I can't find anything.

I mean, I did find

btrfs subvolume list /

and it lists quite a few lines like:

ID 996 gen 288328 top level 258 path @/.snapshots/558/snapshot

But I can't find a way to delete these snapshots. when I do

btrfs subvolume delete @/.snapshots/558/snapshot

I get "no such file or directory".

So how can I delete snapshots? Even better. how do I find out which snapshots are made when and include what, so I can delete those I certainly don't need?

I am tempted to reinstall with an ext4 root file system, but I do not want to spend all the time needed for a fresh install. -- Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tuesday, 14 November 2017 8:00:33 ACDT Dr.-Ing. Dieter Jurzitza wrote:

Hello Mikhail, your plan to switch to ext4 is the best thing you can do for private usage.

+1

[...] The main property of btrfs is being broken. And the tools that are at hand are neither easy to use nor secure. You should never use fsck for example -

+100 Found these; https://www.linux.com/news/snapper-suses-ultimate-btrfs-snapshot-manager https://www.suse.com/documentation/sles11/stor_admin/data/ trbl_btrfs_volfull.html The second is likely to be more useful. After being burned by exactly the same thing and ending up with a non-bootable system, I simply banned btrfs from any system managed by me, at least until the tools have matured and there are sensible installation defaults (or warnings in big, bold print NOT to accept the defaults during installation). HTH. R. -- ============================================================== 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 14.11.2017 10:05, nicholas cunliffe wrote:

...

Btrfs shows many many issues for a normal user and tends to exhibit exactly those problems you are experiencing right now. this is not directed at the OP but those who have responded with prejudice instead of proving support to the actual problem at hand.

Most problems and those currently being 'experienced right now' are due to user ignorance - specifically: not monitoring space, not knowing commands to monitor space, not knowing how to deal with snapshots, not knowing how or implementing default settings.

Like he said: "many issues for a normal user", i.e. no good defaults.

sudo snapper list sudo snapper rm xxx-yyy where xxx-yyy is the numbered range. delete the oldest (except the root FS 0 and 1 by default if no rollback has occurred). The oldest take the most space and are the least useful. remove pre and post pairs together.

after than run a balance and make sure the cron jobs are actually installed (bug caused cron files to disappear for a while on TW) sudo /etc/cron.weekly/btrfs-balance

edit configs here, if you have quotas enabled it is effective to set SPACE_LIMIT= to a lower value /etc/snapper/configs/root

if you add this to .bashrc you can quickly monitor space before large changes alias space='sudo btrfs filesystem usage -h /'

that is all good and well, but it should not be necessary if the defaults were good. Cheers Mathias -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 14 November 2017 at 11:21, nicholas cunliffe wrote:

...

that is all good and well, but it should not be necessary if the defaults were good. yes, im all in favour of not having "a lifeboat so big it sinks the ship". i think they have improved from way back, i would prefer to see a more minimal snapper config

We have a more minimal snapper config - based on user feedback we've already stopped snapper from doing regular snapshots (based on time) Instead we now ONLY do snapshots triggered by actual administration tooling (ie. zypper and YaST) This dramatically reduced the number of snapshots, which are now a direct function of how much you change your system from the default - and as more changes bring more risk I think it's reasonable to think it's a good idea to have more snapshots We also have a space based automatic cleanup on snapper since Leap 42.3 But as the OP is talking about an upgrade, I think it is likely that at least some of the above applied to them. That is unfortunate, but we do not change an existing configuration of a running system for obvious reasons. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Nov 14, 2017 at 2:28 PM, Wols Lists wrote:

Okay, overwriting a user's changed settings is a no-go, but if you can detect that the user hasn't changed the old defaults, upgrading them to new defaults WITHOUT ASKING is perfectly sensible and okay.

How do you distinguish between user intentionally leaving default values and user never intending to customize them? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 14/11/17 12:33, Richard Brown wrote:

On 14 November 2017 at 12:28, Wols Lists wrote:

...

...

That is unfortunate, but we do not change an existing configuration of a running system for obvious reasons.

WHAT obvious reasons?

On 14 November 2017 at 13:20, Andrei Borzenkov wrote:

...

How do you distinguish between user intentionally leaving default values and user never intending to customize them?

Exactly ^ that reason (which I thought was obvious)

In which case, that's actually a good reason for changing them :-) The user never intended to customise them. In other words, they want a default system! You have now (by updating the system, but not the defaults) left them with a non-standard system :-)

We never intentionally break a users running system. We assume that their current configuration of a running system is exactly how they like it. We cannot distinguish between a user intentionally leaving a default value and a user who didn't know better. Sadly, zypper doesn't have mind-reading powers, therefore we don't go changing an existing systems configuration when upgrading.

Point taken. But if we divide users into three categories, there are those who modify the defaults. That's fine, neither you nor me expect an update to trample on their changes. Then there are those people *who know what they are doing* who review the defaults and choose to leave them alone. My change would "break" those systems, yes. Then there are those *who don't have a clue*, who presumably massively outnumber those who know what they are doing. You would rather break the *majority* of systems, rather than the minority? Systemd gets this right, in that the defaults get updated as a matter of course (okay, I guess there's rarely any need to). Any configuration you explicitly want, you specify in the user area which by design is not updated. If you review the defaults, then you can save the (non)-changes to the user area. That way, they'll override any new defaults. "You have reviewed the configuration but made no changes. Do you want this configuration to survive updates unchanged?" Retrofitting the functionality to YaST might not be easy, but imho you'll break far fewer systems by having a way for users to say "this is what I want" and manage the rest automatically, than by allowing (mis)configured cruft from old versions to accumulate until suddenly a new version breaks on an option left behind from a long dead version. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 14/11/2017 à 13:33, Richard Brown a écrit :

We never intentionally break a users running system. (...)

why not use the rpmnew mechanism? that is add a rpmnew file with the recommended new defaults, leaving the choice to use then or not? I just verified I have some rpmnew files on my disk, but not for zypper jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

15.11.2017 01:33, David C. Rankin пишет:

On 11/14/2017 4:05 AM, nicholas cunliffe wrote:

...

Most problems and those currently being 'experienced right now' are due to user ignorance - specifically: not monitoring space, not knowing commands to monitor space, not knowing how to deal with snapshots, not knowing how or implementing default settings.

To be blunt and non-politically correct, that's just BS.

When YAST is supposed to be the wizard that guides new users through setup providing defaults for just about everything and hiding the details behind "Expert" partitioning buttons, it is malarkey, and an ill placed ad hominem to blame the user for not monitoring what is mysteriously ballooning storage behind the scenes -- that heretofore has never been a problem before btrfs became the default filesystem.

To be candid, you can blame the user for failing to monitor disk space when the cause of the problem is what the user put on the disk filling it up, but when the problem is the result of YAST defaults that repeatedly lead to just this type of problem, blaming the user is just an attempt to avoid responsibility for an imprudent choice of a default filesystem.

If we are not going to have YAST make good default choices for the new users, then we certainly should not blame the user or call them "ignorant" when foreseeable problems based on YAST defaults occur.

What should YaST defaults be? You apparently are in possession of silver bullet, why keep it secret? I am sure developers will immediately implement your suggestion. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-15 at 04:43 +0100, Carlos E. R. wrote:

On Wednesday, 2017-11-15 at 06:28 +0300, Andrei Borzenkov wrote:

...

15.11.2017 01:33, David C. Rankin пишет:

...

On 11/14/2017 4:05 AM, nicholas cunliffe wrote:

...

Most problems and those currently being 'experienced right now' are due to user ignorance - specifically: not monitoring space, not knowing commands to monitor space, not knowing how to deal with snapshots, not knowing how or implementing default settings.

To be blunt and non-politically correct, that's just BS.

When YAST is supposed to be the wizard that guides new users through setup providing defaults for just about everything and hiding the details behind "Expert" partitioning buttons, it is malarkey, and an ill placed ad hominem to blame the user for not monitoring what is mysteriously ballooning storage behind the scenes -- that heretofore has never been a problem before btrfs became the default filesystem.

To be candid, you can blame the user for failing to monitor disk space when the cause of the problem is what the user put on the disk filling it up, but when the problem is the result of YAST defaults that repeatedly lead to just this type of problem, blaming the user is just an attempt to avoid responsibility for an imprudent choice of a default filesystem.

If we are not going to have YAST make good default choices for the new users, then we certainly should not blame the user or call them "ignorant" when foreseeable problems based on YAST defaults occur.

What should YaST defaults be? You apparently are in possession of silver bullet, why keep it secret? I am sure developers will immediately implement your suggestion.

You are correct, but David also has a point, but not nicely drawn :-)

The thing is, we can not blame the fault on "user ignorance" if a tool such as YAST did not use good defaults for a plain user. We, as users, expect YAST to make life easy for us, without needing to be experts.

Or in other words: if a filesystem requires the user to become knowledgeable in "arcane settings and tools", then it is not a good default choice.

On the other hand, I have seen plain users with little knowledge recover from a system failure due to bad user management just by reverting a snapshot, unaided - just by chancing on the appropiate doc. Sure btrfs has very nice features. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloLuR4ACgkQtTMYHG2NR9Xu0ACcDo5sgdnA6nKygt6XFRovxtfm eBMAniYvF8SIiMjMaGmHioMOWREw6oC+ =i0Za -----END PGP SIGNATURE-----

Le 16/11/2017 à 16:56, Ken Schneider - openSUSE a écrit :

I agree that BTRFS does have some nice features and I don't blame BTRFS for filling /. The main problem I have observed is the error on using a minimal amount of space for / when the system is setup for installation.

early (aka 13.2 or 42.1) install where suboptimal. Now (42.3), default are much better. 40Gb like the OP should be enough, specially on ssd that are not yet that cheap on large size. for sure the time with small content is gone, but my own online server is not that big (not btrfs though) /dev/sda1 ext4 29G 5,1G 23G 19% / :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-15 at 09:15 +0100, jdd@dodin.xyz wrote:

Le 15/11/2017 à 04:43, Carlos E. R. a écrit :

...

Or in other words: if a filesystem requires the user to become knowledgeable in "arcane settings and tools", then it is not a good default choice.

two things:

* "default" can't fit any situation, if not it would be called "universal"

* Richard said that the defaults changed already with the time, and I can confirm the 42.3 default are much better than the old ones (on the old times, two years ago :-))

True. The key point for me, anyway, is that we should not blame the user for not knowing how to handle btrfs, when he just went ahead with whatever defaults. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloMKsAACgkQtTMYHG2NR9VK0gCglbewV+iuTpsQEMgA9f/debuU d8MAnikgJJMUx1DCm0U99lZhKddtcmfg =dMqj -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-15 at 13:04 +0100, jdd@dodin.org wrote:

Le 15/11/2017 à 12:53, Carlos E. R. a écrit :

...

The key point for me, anyway, is that we should not blame the user for not knowing how to handle btrfs, when he just went ahead with whatever defaults.

I just went on an "ext4 file system corrupt" and had to (re)learn to use fsck, same for any file system

In most cases, I just issue "fsck /dev/sdXY" and wait. If it fails, it typically says what to do next. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloML4EACgkQtTMYHG2NR9WVFwCfXU23OPd+2y2uD9y0TqOAZLNr +pwAn2acncO0GTwLWjk04YWszN1CdAoF =CkGM -----END PGP SIGNATURE-----

On Wed, 15 Nov 2017 14:46:18 +0000 Wols Lists wrote:

The problem, as I regularly find, is that when I have problems the results found by Google are often pretty naff. What's the use of a load of articles circa 2011 when Plasma 5 is giving me grief?

I agree. There are a couple of things you can do to help, of course: include +"plasma 5" in the search, or restrict the search to the past year or so. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tuesday, 14 November 2017 20:41:12 ACDT Richard Brown wrote:

On 14 November 2017 at 00:47, Rodney Baker wrote:

...

On Tuesday, 14 November 2017 8:00:33 ACDT Dr.-Ing. Dieter Jurzitza wrote:

...

Hello Mikhail, your plan to switch to ext4 is the best thing you can do for private usage.

+1

...

[...] The main property of btrfs is being broken. And the tools that are at hand

are neither easy to use nor secure. You should never use fsck for example -

+100

Found these;

https://www.linux.com/news/snapper-suses-ultimate-btrfs-snapshot-manager

https://www.suse.com/documentation/sles11/stor_admin/data/ trbl_btrfs_volfull.html

I personally prefer the openSUSE Wiki for its comprehensive guide to the common concerns with BTRFS

https://en.opensuse.org/SDB:BTRFS

Fair enough - I went with the most appropriate links that a cursory google search turned up. You'll note that the second link is from the SLES documentation, which arguably is a pretty useful resource.

Since following the above guides I've been comfortable running btrfs for the last years

I'm glad it works for you. I have no need for snapshots (I manage my own backup strategy) and having ended up with non-bootable systems not once, but twice, and with the cost of 256GB SSD's still being considerably more (locally, at least) than the 128GB that currently holds / (but not /var, / home, /usr/local, /downloads and some other local data-only partitions), I really don't need to have a filesystem that needs double the amount of space provisioned (as per the recommendation in the SLES documentation above) than would otherwise be the case. I gave up on LVM for similar reasons - irrecoverable data loss when one disk of a spanned LVM volume failed. Unfortunately, at that time, I didn't have that data backed up (thankfully, it wasn't that critical). Still, that is the beauty of Linux - choice. Rodney. -- ============================================================== 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