Btrfs Root ran out of space, via this forum i fixed it, are my settings ok pls?

English Install/Boot/Login
21

Quite some years ago I landed in a yes/no discussion re. fstrim, manual maintenance of SSD’s, mainly to avoid the much feared limited writes. Greg KH ( kernel maintainer ) stated clearly that there is no need for that, first because the system should ( and does ) take care of it, second because according to him the fear for the wearing of SSD’s was completely unnecessary. The latter meanwhile has proven him right, long term tests did not kill SSDs in no time, it took years of abusing them. On the first: from my first SSD ( I was one of the first to replace slow laptop HDDs by - at the time expensive - SSDs ) on I have treated SSDs no different than HDDs.
Don’t you think it would be a flaw in linux if such tweaks would still be needed to save hardware. Nah, linux is too good for that.

And yes, I know of all these tips and tricks sites re. SSD usage, asked some questions but never got a reply that made me change my mind.

22

Hi
Which is why I asked about encryption… :wink: Fix that and you should be good to go…

23

Thanks Knurpht. I have no technical basis on which to dispute your information, thus you’ll probably think the following rather silly…

More for the academic exercise now than anything else, in order to satisfy my curiosity about whether i can solve the puzzle of making fstrim become available in TW for a luks-encrypted ext4 partition, I’ll persist just a little longer on this experiment.

24

OK, but that’s another story, this kind of experiments have taught me a lot in the past, when I still had some old hardware to such things with/to :). Hope you have backups of everything dear or important.

25

I seem to have solved manually enabling fstrim in TW for my luks-encrypted ext4 /home partition, using a method buried deep down in the comments of dcurtisfra’s reference TRIM on LVM on LUKS on SSD, revisited – Just another Linux geek

Michael17 December, 2016 at 10:41 pm

Can confirm that

  • adding ‘rd.luks.options=discard’ to /etc/default/grub
  • running sudo grub2-mkconfig -o /boot/grub2/grub.cfg
  • rebooting
    did not solve it, but doing the following after reboot
  • add ‘luks,allow-discards’ to all encrypted volumes in /etc/crypttab
  • running sudo dracut –force
  • rebooting

did the trick on a clean Fedora 25 install with LUKS (no LVM).

…& so now:

linux-763v:~> **sudo fstrim --verbose /home**
[sudo] password for root:  
/home: 19.6 GiB (21030162432 bytes) trimmed
linux-763v:~>

So the final piece of the puzzle is how to automate this?

Does the fstrim.timer do this for me already, or do i have to initiate it somehow… or instead do i need to write a bash script to trim home & place it into /etc/cron.weekly & if so, what about dcurtisfra’s concern that potentially having the btrfs root trim & home trim running simultaneously via cron.weekly might be dangerous?

Sorry for all my questions.

26

Hi
If you run the command;


fstrim --verbose --all

You should see them all run including your /home. This will then be taken care of by the fstrim service, so no user interaction required.

27

Thanks Malcolm.

This is not quite what i expected:

linux-763v:~> sudo fstrim --verbose --all
[sudo] password for root:  
/home: 0 B (0 bytes) trimmed
/opt: 35.3 GiB (37874429952 bytes) trimmed
linux-763v:~>

Shouldn’t root itself also have shown there?

28

On Sat 22 Jul 2017 12:26:01 AM CDT, GooeyGirl wrote:

malcolmlewis;2830765 Wrote:
> Hi
> If you run the command;
> >
Code:

> >
> fstrim --verbose --all
>

> >
> You should see them all run including your /home. This will then be
> taken care of by the fstrim service, so no user interaction
> required.

Thanks Malcolm.

This is not quite what i expected:

Code:

linux-763v:~> sudo fstrim --verbose --all
[sudo] password for root:
/home: 0 B (0 bytes) trimmed
/opt: 35.3 GiB (37874429952 bytes) trimmed
linux-763v:~>

Shouldn’t root itself also have shown there?

Hi
What is the output from the command lsblk, the mount name is a bit
funky… /opt == /

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.74-18.20-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

29

Thanks. It’s:

linux-763v:~> lsblk
NAME                                                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                                            8:0    0 238.5G  0 disk   
├─sda1                                                         8:1    0     1M  0 part   
├─sda2                                                         8:2    0   210M  0 part  /boot/efi
├─sda3                                                         8:3    0    50G  0 part  /var/crash
├─sda4                                                         8:4    0     4G  0 part   
│ └─cr_ata-SAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960-part4 254:0    0     4G  0 crypt [SWAP]
└─sda5                                                         8:5    0   180G  0 part   
  └─cr_ata-SAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960-part5 254:1    0   180G  0 crypt /home
sr0                                                           11:0    1  1024M  0 rom    
linux-763v:~>
30

Hi
So /dev/sda3 aka / and now is /var/crash ( a cosmetic bug) if it trimmed now instead of /opt it would be /var/crash. All is good then…

31

Thank you… but once more sorry i’m struggling to understand [albeit by the [i]end of my post i might finally have seen the light…?].

Yes, when i did the installation i certainly did organise Lappy’s partitions such that sda3 was root, with fs of btrfs.

But why is it showing up here as /var/crash & not simply / ?

Given that now as of a few days ago my Tower is also running TW, i checked its lsblk, & was surprised/confused/cranky to see that it also reports not as root but as something else again *:

linux-3l20:~> lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0 232.9G  0 disk   
├─sda1        8:1    0   156M  0 part  /boot/efi
├─**sda2        8:2    0    60G  0 part  /var/spool**
└─sda3        8:3    0   160G  0 part   
  └─cr_home 254:1    0   160G  0 crypt /home
sdb           8:16   0   1.8T  0 disk   
├─sdb1        8:17   0     4G  0 part   
│ └─cr_swap 254:0    0     4G  0 crypt [SWAP]
├─sdb2        8:18   0    36G  0 part  /SeagateSpare
└─sdb3        8:19   0   1.8T  0 part  /Seagate
sr0          11:0    1  1024M  0 rom    
linux-3l20:~>

I note that in both Lappy & Tower now, if i run df -h, i do see the expected root association… along with a list of other stuff [including the specific item named in each PC’s respective [i]lsblk*]:

Lappy:

linux-763v:~> **df -h**
Filesystem                                                            Size  Used Avail Use% Mounted on
devtmpfs                                                              3.8G  8.0K  3.8G   1% /dev
tmpfs                                                                 3.8G   52M  3.8G   2% /dev/shm
tmpfs                                                                 3.8G  1.8M  3.8G   1% /run
tmpfs                                                                 3.8G     0  3.8G   0% /sys/fs/cgroup
**/dev/sda3                                                              50G   18G   33G  35% /**
tmpfs                                                                 256M   22M  235M   9% /tmp
/dev/sda2                                                             207M   512  207M   1% /boot/efi
/dev/sda3                                                              50G   18G   33G  35% /boot/grub2/x86_64-efi
/dev/sda3                                                              50G   18G   33G  35% /var/lib/libvirt/images
/dev/sda3                                                              50G   18G   33G  35% /usr/local
/dev/sda3                                                              50G   18G   33G  35% /var/tmp                                  
/dev/sda3                                                              50G   18G   33G  35% /var/lib/pgsql                            
/dev/sda3                                                              50G   18G   33G  35% /var/cache                                
/dev/sda3                                                              50G   18G   33G  35% /var/spool                                
/dev/sda3                                                              50G   18G   33G  35% /var/lib/mailman
/dev/sda3                                                              50G   18G   33G  35% /var/lib/mysql
/dev/sda3                                                              50G   18G   33G  35% /boot/grub2/i386-pc
/dev/sda3                                                              50G   18G   33G  35% /opt
/dev/sda3                                                              50G   18G   33G  35% /var/log
/dev/sda3                                                              50G   18G   33G  35% /.snapshots
/dev/sda3                                                              50G   18G   33G  35% /srv
/dev/sda3                                                              50G   18G   33G  35% /var/lib/named
/dev/sda3                                                              50G   18G   33G  35% /var/opt
/dev/sda3                                                              50G   18G   33G  35% /var/lib/mariadb
/dev/sda3                                                              50G   18G   33G  35% /var/lib/machines
/dev/sda3                                                              50G   18G   33G  35% /var/crash
/dev/mapper/cr_ata-SAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960-part5  177G  159G   17G  91% /home
tmpfs                                                                 772M   20K  772M   1% /run/user/1000
linux-763v:~>

Tower:

linux-3l20:~> **df -h**
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs              16G  8.0K   16G   1% /dev
tmpfs                 16G  459M   15G   3% /dev/shm
tmpfs                 16G  2.0M   16G   1% /run
tmpfs                 16G     0   16G   0% /sys/fs/cgroup
**/dev/sda2             61G   13G   48G  21% /**
tmpfs                2.0G  298M  1.8G  15% /tmp
/dev/sda1            156M  4.6M  152M   3% /boot/efi
/dev/sda2             61G   13G   48G  21% /var/tmp
/dev/sda2             61G   13G   48G  21% /.snapshots
/dev/sda2             61G   13G   48G  21% /usr/local
/dev/sda2             61G   13G   48G  21% /srv
/dev/sda2             61G   13G   48G  21% /var/cache
/dev/sda2             61G   13G   48G  21% /boot/grub2/x86_64-efi
/dev/sda2             61G   13G   48G  21% /var/lib/mysql
/dev/sda2             61G   13G   48G  21% /var/log
/dev/sda2             61G   13G   48G  21% /var/lib/pgsql
/dev/sda2             61G   13G   48G  21% /var/lib/mariadb
/dev/sda2             61G   13G   48G  21% /var/lib/machines
/dev/sda2             61G   13G   48G  21% /boot/grub2/i386-pc
/dev/sda2             61G   13G   48G  21% /var/lib/libvirt/images
/dev/sdb2             36G   70M   36G   1% /SeagateSpare
/dev/sda2             61G   13G   48G  21% /var/lib/named
/dev/sda2             61G   13G   48G  21% /opt
/dev/sda2             61G   13G   48G  21% /var/opt
/dev/sda2             61G   13G   48G  21% /var/crash
/dev/sda2             61G   13G   48G  21% /var/lib/mailman
/dev/sda2             61G   13G   48G  21% /var/spool
/dev/sdb3            1.8T  778G  927G  46% /Seagate
/dev/mapper/cr_home  160G   21G  140G  13% /home
tmpfs                3.1G   44K  3.1G   1% /run/user/1000
linux-3l20:~>

Um, sorry, but the only part of this that i can grasp is “All is good then”… i just don’t yet see why it’s apparently ok :\

Lappy [as done [i]now whilst writing this post]:

linux-763v:~> **sudo fstrim --verbose --all**
[sudo] password for root:  
/home: 0 B (0 bytes) trimmed
**/var/crash: 32.3 GiB (34721116160 bytes) trimmed**
linux-763v:~>

Oh, exactly as you predicted. [scratches head…]

Aha… [desperate leap of deductive guesswork follows]… do these results possibly mean that the other day/night, the only thing needing to be trimmed within root was /opt, whereas today only /var/crash needs trimming & if that logic is valid, then next week it might be something else again within root]?

I have not yet set up trimming in Tower, but will do that today, then observe the outcome.

32

On Tue 25 Jul 2017 04:26:01 AM CDT, GooeyGirl wrote:

Thank you… but once more sorry i’m struggling to understand [albeit by
the -end- of my post i -might- finally have seen the light…?].
Oh, exactly as you predicted. -[scratches head…]-

<snip>
Oh, exactly as you predicted. -[scratches head…]-

Aha… -[desperate leap of deductive guesswork follows]-… do these
results possibly mean that the other day/night, the -only- thing needing
to be trimmed within root was -/opt-, whereas today only -/var/crash-
needs trimming & if that logic is valid, then next week it might be
something else again within root]?

Hi
No, like I said a bug in the way fstrim (lsblk and probably others)
handles the output of the mountpoint (subvolume) it’s acting (as in
trimming) on /dev/sda3 aka / just telling you the LAST /etc/fstab entry
for sda3.

Run the command mount then lsblk commands and your last sda3 entry will
be the same mountpoint.

Nothing to worry about, for example df command doesn’t work properly
with btrfs either…

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.74-18.20-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

33

Here’s Tower’s results, having now apparently successfully also setup fstrim for its /home [although, maybe i didn’t need to apply that special method given unlike on Lappy [[i]ext4] i created my Tower’s new TW /home as xfs, & i recall earlier you said that your one trims fine].

linux-Tower:~> **sudo fstrim --verbose --all**
[sudo] password for root:  
/home: 139.6 GiB (149880913920 bytes) trimmed
/boot/grub2/i386-pc: 48.4 GiB (51966222336 bytes) trimmed

linux-Tower:~> **lsblk**
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0 232.9G  0 disk   
├─sda1        8:1    0   156M  0 part  /boot/efi
├─sda2        8:2    0    60G  0 part  /boot/grub2/i386-pc
└─sda3        8:3    0   160G  0 part   
  └─cr_home 254:1    0   160G  0 crypt /home
sdb           8:16   0   1.8T  0 disk   
├─sdb1        8:17   0     4G  0 part   
│ └─cr_swap 254:0    0     4G  0 crypt [SWAP]
├─sdb2        8:18   0    36G  0 part  /SeagateSpare
└─sdb3        8:19   0   1.8T  0 part  /Seagate
sr0          11:0    1  1024M  0 rom    
linux-Tower:~>

Gosh, lsblk for root really is some fine random number generator, isn’t it, teehee.

EDIT: Ah, we posted at about the same time, so i’ve only just now seen your reply.

34

Thanks Malcolm.

Well, you told me before, but in all honesty i did not understand what your “cosmetic bug” expression actually meant. Anyway, i will satisfy myself from now on with the approach that as long as i see “/”, irrespective of whether anything follows after, all i need to take away from it is that yes, root is being trimmed & now so is /home].

35

Just to revisit this – the green text – i have just realised following a review of this whole thread, that the other day in Lappy & tonight also in Tower, i made this edit in /etc/sysconfig/btrfsmaintenance:

# Frequency of periodic trim. Off by default so it does not collide with# fstrim.timer . If you do not use the timer, turn it on here. The recommended
# period is 'weekly'.
#BTRFS_TRIM_PERIOD="none"
**BTRFS_TRIM_PERIOD="weekly"**

So, given the #comment line warns of a possible collision, & given that you have confirmed to me that my Timer is on, & will automatically take care of the trimming, my [red font] edit is wrong, isn’t it, & needs to be deleted…?

linux-Tower:~> systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2017-07-25 20:46:12 AEST; 1h 30min ago
Docs: man:fstrim

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
linux-Tower:~>

36

Hi
Yes, remove your cron entry and just leave the service to deal with trim…

You should be all good to go now with your base system setup… :wink:

Oh, fyi there is a thread on the Factory Mailing list with a few tools for btrfs backup, called partclone (in the release)…

I just pushed cronopete to the Archiving development repo if that’s something of interest for you /home to a USB device…?
http://www.rastersoft.com/programas/cronopete.html

37

Thank you for letting me know. I’ll review those pages as time permits. Re data backups, i use BackInTime & have been most happy with it… but i’m always interested to find better backup tools if available [for me the progression has been [i]Areca Backup –> luckyBackup –> BiT…].

Thanks. I did [or undid] it on both PCs, but this is from Tower after first editing /etc/sysconfig/btrfsmaintenance again to delete my superfluous red-font as per earlier post, & uncomment-out the “none” line]:

linux-Tower:~> **systemctl start btrfsmaintenance-refresh.service**

linux-Tower:~> **systemctl status btrfsmaintenance-refresh.service**
● btrfsmaintenance-refresh.service - Update cron periods from /etc/sysconfig/btrfsmaintenance
   Loaded: loaded (/usr/lib/systemd/system/btrfsmaintenance-refresh.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2017-07-25 23:49:33 AEST; 25s ago
  Process: 14940 ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh (code=exited, status=0/SUCCESS)
 Main PID: 14940 (code=exited, status=0/SUCCESS)

linux-Tower:~> **sudo systemctl status btrfsmaintenance-refresh.service**
● btrfsmaintenance-refresh.service - Update cron periods from /etc/sysconfig/btrfsmaintenance
   Loaded: loaded (/usr/lib/systemd/system/btrfsmaintenance-refresh.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2017-07-25 23:49:33 AEST; 1min 2s ago
  Process: 14940 ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh (code=exited, status=0/SUCCESS)
 Main PID: 14940 (code=exited, status=0/SUCCESS)

Jul 25 23:49:33 linux-Tower systemd[1]: Starting Update cron periods from /etc/sysconfig/btrfsmaintenance...
Jul 25 23:49:33 linux-Tower btrfsmaintenance-refresh-cron.sh[14940]: Refresh script btrfs-scrub.sh for monthly
Jul 25 23:49:33 linux-Tower btrfsmaintenance-refresh-cron.sh[14940]: Refresh script btrfs-defrag.sh for none                                                      
Jul 25 23:49:33 linux-Tower btrfsmaintenance-refresh-cron.sh[14940]: Refresh script btrfs-balance.sh for weekly                                                   
Jul 25 23:49:33 linux-Tower btrfsmaintenance-refresh-cron.sh[14940]: **Refresh script btrfs-trim.sh for none**                                                        
Jul 25 23:49:33 linux-Tower systemd[1]: Started Update cron periods from /etc/sysconfig/btrfsmaintenance.                                                         
linux-Tower:~>

After that i visually confirmed in Dolphin that /etc/cron.weekly now once again only contains btrfs-balance, not also btrfs-trim anymore.

Re your remark –

should be all good to go now with your base system setup

…that’s also what i thought as well. On Lappy it seems to be true, but i’ve just discovered an anomaly on Tower that i fixed a day ago but is now wrong again. I’ll create a subsequent post in this thread for it, for cleanliness.

38

The anomaly…

Eight days ago on Lappy, & a couple of days ago on Tower, i’d edited /etc/sysctl.conf to add:

# Sharply reduce swap inclination
vm.swappiness=1


# Improve cache management
vm.vfs_cache_pressure=50

…& after rebooting verified that swappiness was indeed now 1.

Tonight, on a whim, i rechecked it on both PCs. Lappy remains correct:

linux-Lappy:~> **cat /proc/sys/vm/swappiness**
**1**
linux-Lappy:~> s

But somehow Tower has reverted to default:

linux-Tower:~> **cat /proc/sys/vm/swappiness**
**60**
linux-Tower:~>

…yet its /etc/sysctl.conf remains correct:

# Sharply reduce swap inclination
vm.swappiness=1
#
# Improve cache management
vm.vfs_cache_pressure=50
#

As seems to be tediously standard for me, i don’t understand what explains this anomaly / regression.

39

Hi
There is a difference in the files… :wink:

sysctl.conf is fussy… no carriage return line feed or the # at the end, your cursor after editing the file should be at the 0 (zero) on the last line…

40

Thanks Malcolm. Well, that is kinda interesting! The end of the story is now “they all lived happily ever after”:

linux-Tower:~> **cat /proc/sys/vm/swappiness
****1**
linux-Tower:~>

…but the middle of the story is confusing & contradictory. I had actually used the identical file contents on Lappy & Tower, & as i showed before Lappy had no hassles acknowledging that its Swappiness really had reduced to 1. But as i also showed before, that identical file in Tower [which a couple of days ago also resulted in post-reboot “1”], yesterday had reverted to 60… with [to say it again], the identical file.

Nevertheless i followed your hint accurately today & deleted everything in Tower’s version of the file after the “0” of

vm.vfs_cache_pressure=50

, rebooted, & voila now again result is “1”. However [repeating again], the other day it also was good, then went bad, so i wonder what it will do tomorrow… For now i have not bothered to edit that file in Lappy, as it still already generates “1”. Weird.