Btrfs at ways end here!

I have written before. Why not start/install (when 13.1 arrived) a 13.1 64 KDE VM that I can measure and look upon with this amazing features… Snapshots… I did. I did and have started it up every ~4 weeks and run a zypper dup. No other activity’s. Start up, zypper dup and let run for a day.

Yes I’m patient.

So today the VM gave up:

62/84) Installing: mozilla-nss-3.17.2-47.2 ..............................[done]
(63/84) Installing: libreoffice-4.1.6.2-33.2 ............................[error]
Installation of libreoffice-4.1.6.2-33.2 failed:
Error: Subprocess failed. Error: RPM failed:    installing package libreoffice-4.1.6.2-33.2.x86_64 needs 107MB on the / filesystem


Abort, retry, ignore? [a/r/i] (a): a
Problem occured during or after installation or removal of packages:
Installation aborted by user

Ok some check:

df
Filesystem              1K-blocks      Used Available Use% Mounted on
/dev/sda2                18876416  17686208    142328 100% /
devtmpfs                   496808        16    496792   1% /dev
tmpfs                      510308        76    510232   1% /dev/shm
tmpfs                      510308      3284    507024   1% /run
tmpfs                      510308         0    510308   0% /sys/fs/cgroup
tmpfs                      510308      3284    507024   1% /var/run
tmpfs                      510308      3284    507024   1% /var/lock
/dev/sda3                 6466560     45524   5746492   1% /home

But you cant trust df any longer using Btrfs:

btrfs fi df /
Data, single: total=15.01GiB, used=14.88GiB
System, DUP: total=8.00MiB, used=4.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.48GiB, used=1021.63MiB
Metadata, single: total=8.00MiB, used=0.00

Or:

btrfs  filesystem show
Label: none  uuid: dd195f2c-2223-4bea-8ed6-cad38656d2fa
        Total devices 1 FS bytes used 15.88GiB
        devid    1 size 18.00GiB used 18.00GiB path /dev/sda2

Label: none  uuid: a8966de9-716c-4d57-bb1f-72349096d362
        Total devices 1 FS bytes used 44.07MiB
        devid    1 size 6.17GiB used 1.28GiB path /dev/sda3

A lot of numbers. A lot of commands. What should I do? What should I thrust in? Btrfs stabile and snapshots turn on by default when install. Even worst in 13.2.

Another side of the reality is even sicker and before I understand it… Apparently I had VirtualBox to turn on snapshots for this VM. 24GiB of snapshots + the orginal .vdi file. ~50Gib on disk. Hmmm…

Right now I have a 40GiB / on my main DE running Btrfs to have a look upon. I save all my important data on my server that use Ext4. Backed up on other disks using Ext_FS.

Comments? I have “frozen” (pause) that VM if anyone comes up whit commands that I should run:). I have my opinion.

regards

On 2014-12-27 22:46, jonte1 wrote:

> So today the VM gave up:

> Ok some check:
>
>
> Code:
> --------------------
> df
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sda2 18876416 17686208 142328 100% /
> --------------------

15 GB is too small when using btrfs. It should be 50.

> Another side of the reality is even sicker and before I understand it…
> Apparently I had VirtualBox to turn on snapshots for this VM. 24GiB of
> snapshots + the orginal .vdi file. ~50Gib on disk. Hmmm…

That’s normal, because it has the historic data, repeated several times,
thus bigger than what the guest sees.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I agree upon at >40GB for / using Btrfs. 18GB was ok in (suggested VM)13.1 installation. But did you notice the numbers and the arithmetic in my post? was it 15 or 18GB? How should one get proper info when one’s served whit different numbers depending on the command? The tools for Btrfs have a lot to prove. As Btrfs itself according to my opinion.

regards

On Sat, 27 Dec 2014 21:46:01 +0000, jonte1 wrote:

> What should I do?

Delete some of the older snapshots using snapper, then tune btrfs on your
root partition so it doesn’t create so many snapshots.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

After have done some thinking… No. The test is over. Ways end. Yes I have read about the aggressive setting/config of snapshots in 13.1. I choose another way, I already have brtfs on my main 13.2 DE (ext4 for /home). After 2,5 weeks of testing SLED 12(another story) on my main laptop workhorse I reinstalled it the day before and choose btrfs for / and ext4 for /home.

Why? I think that now that SUSE itself is shipping brtfs as default fs it will stay in openSUSE for a long time. I may as well try to use it and learn (and whine a bit of course). There is things that I dont like at all with btrfs. The tools to manage it for ex. I don’t agree when people saying that nothing wrong whit the fs itself. Its the tools… Like snapper for ex. Very shortsighted IMO.

Anyway, I can afford to loose a day if something goes wrong. I have other PC’s and I can now ondays reach my files from other PC’s, tablets when running my ownCloud accessible from I-net. Yes I manage my backups at home with great care.

I will find something else to test in 2015 :).

regards

I forgot in the post above that I…

My ordinary laptop workhorse that first was upgraded from 13.1->13.2, then a short use/test whit SLED12 is now running 13.2…

The 13.1 installation had a 20GB ext4 partionion for “/”. This was of course unchanged when update 13.1->13.2. When I installed SLED12 it “picked” up the 20GB and format it with btrfs.

The same story when installed 13.2 again, it “picked” up the 20GB. Yes I know that its to small to use with brtfs. But why not I tough? Run the same scenario as a casual user will when upgrading not understanding the partitioning suggested… I expect to run into problems but how long time will it take? And how much time will it take to fix it?

regards

On 2014-12-31 17:16, jonte1 wrote:

> The same story when installed 13.2 again, it “picked” up the 20GB. Yes I
> know that its to small to use with brtfs.

Official documentation recommends 20 GB with btrfs.

https://activedoc.opensuse.org/book/opensuse-reference/chapter-3-advanced-disk-setup#sec.yast2.i_y2_part_expert

+++—-—-—-—-—-—-—-—-—-—-—-—-
Tip: Size of Btrfs Partition

Because saved snapshots require more disk space, it is recommended to
reserve more space for Btrfs partition than for a partition not capable
of snapshotting (such as Ext3). Recommended size for a root Btrfs
partition with suggested subvolumes is 20GB.
—-—-—-—-—-—-—-—-—-—-—-—-+±

/I/ would recommend 50.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

That assumes the documentation is read and understood. Then the different roles of Btrfs and Snapper should be clearer. How to run within 20GB should then be understood. It requires changes to the snapper config that affect snapshot frequency and retention. Snapper commands are also available to monitor and delete snapshots. That’s how my Tumbleweed system is now running in less than 20GB, although I originally chose a larger partition size of 35GB.

However I believe @jonte1 was referring to his earlier thoughts, which suggested to me that originally he had not made enough use of the openSUSE reference manual.

Lol.

Official documentation recommends 20 GB with btrfs.

https://activedoc.opensuse.org/book/…y2_part_expert

+++—-—-—-—-—-—-—-—-—-—-—-—-
Tip: Size of Btrfs Partition

Because saved snapshots require more disk space, it is recommended to
reserve more space for Btrfs partition than for a partition not capable
of snapshotting (such as Ext3). Recommended size for a root Btrfs
partition with suggested subvolumes is 20GB.
—-—-—-—-—-—-—-—-—-—-—-—-+±

/I/ would recommend 50.


Cheers / Saludos,

I enjoy your post earlier today in http://lmgtfy.com/?q=recover+root+pa...3Aopensuse.org# rotfl!. If you don’t mind take a San Miquel or two for me when salute the new year in Spain.

(Conused) However I believe @jonte1 was referring to his earlier thoughts, which suggested to me that originally he had not made enough use of the openSUSE reference manual.

Hmm… I test. Why? I want to know what I dealing with. I did a search on “openSUSE reference manual” and “SUSE reference manual”. Hopelessly outdated.

And by the way, -I notice a developer was present at the forum during the week (https://forums.opensuse.org/showthread.php/503888-Possible-improvements-to-openSUSE ). Nice.

Best regards ;).

On 2014-12-31 19:56, jonte1 wrote:

> I enjoy your post earlier today in
> http://lmgtfy.com/?q=recover+root+pa...3Aopensuse.org# rotfl!. If you
> don’t mind take a San Miquel or two for me when salute the new year in
> Spain.

LOL. Could not resist myself when I posted that. Somebody did it to me
when I asked something. Recovering Mr.R. password must be one of the
most asked questions.

I’m at the moment back at home, drinking “water with gas” which I
believe is called in English “soda water”. No more spirits this night.
The streets are full of mostly happy and very young people, well dressed
with suits and ties, and drinks. Here drinking in the streets is only
nominally forbidden, tradition is otherwise. Older people probably
prefer to enjoy inside, it is cold. Cold, for us, that is.

Having a bit a pre-sleep relaxation, reading here.

>> (Conused) However I believe @jonte1 was referring to his earlier
>> thoughts, which suggested to me that originally he had not made enough
>> use of the openSUSE reference manual.
>
> Hmm… I test. Why? I want to know what I dealing with. I did a search on
> “openSUSE reference manual” and “SUSE reference manual”. Hopelessly
> outdated.

It is a volunteer effort… probably the manuals are up to date for
SLES. But the photos of the installation process are correct, which is
why I had searched those page for, previously, for another thread.

> And by the way, -I notice a developer was present at the forum during
> the week (’
> https://forums.opensuse.org/showthread.php/503888-Possible-improvements-to-openSUSE
> (http://tinyurl.com/oncgywq) ). Nice.

Yes… interesting. He is oS chairman.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-12-31 19:16, consused wrote:

>> Official documentation recommends 20 GB with btrfs.
> That assumes the documentation is read and understood. Then the
> different roles of Btrfs and Snapper should be clearer. How to run
> within 20GB should then be understood. It requires changes to the
> snapper config that affect snapshot frequency and retention. Snapper
> commands are also available to monitor and delete snapshots. That’s how
> my Tumbleweed system is now running in less than 20GB, although I
> originally chose a larger partition size of 35GB.

My current root actually uses 32.2 GB, not counting specific tool
partitions nor home or data. And I mean actual use, not the size of the
partitions…

But I test systems with 8 or 9 GB total.

I recommend 50 GB to be safe (with btrfs), for the same usage that I
would recommend 25 with ext4. Disks are big nowdays… better reserve
lots of space now than resize later.

Me, I would have to use 90 if I switched to b.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

That’s fine. It’s not difficult to de-construct the reference manual’s “20GB”. Of course we wouldn’t need to guess if the assumptions and judgements were properly included, i.e normal best practice for estimates. It could be based on default installation of a standard release with ext4, a separate /home, and root partition of 10GB i.e. a minimum working system circa 12.x (arguably) but not Tumbleweed. Rule of thumb doubles it to 20GB for Btrfs with “saved snapshots”. However, that requires very aggressive cleanup of snapshots (as tested back on 12.3), as I more or less suggested.

Perhaps the manual should now include a worked example that more than adequately supports the current snapper config defaults. Any rule of thumb should include extra for contingency.

I recommend 50 GB to be safe (with btrfs), for the same usage that I
would recommend 25 with ext4. Disks are big nowdays… better reserve
lots of space now than resize later.

Unsafe IMO - how long is a piece of string. It’s up to you, but a recommendation based on a good view of the user’s requirements would be safer. :wink: