28 December 2019

BTRFS filesystem full, now what?

The mileage may vary, but I try to update this post.

Is your filesystem really full? Mis-balanced metadata and/or data chunks

Below, you'll see how to rebalance data blocks and metadata, and you are unlucky enough to get a filesystem full error before you balance, try running this first:
# btrfs balance start -musage=0 /path
# btrfs balance start -dusage=0 /path
 
A null rebalance will help in some cases, if not read on.
Also, if you are really unlucky, you might get in a no more space error that requires adding a temporary block device to your filesystem to allow balance to run. See below for details.

Pre-emptively rebalancing your filesystem

In an ideal world, btrfs would do this for you, but it does not. I personally recommend you do a rebalance weekly or nightly as part of of a btrfs scrub cron job. See the btrfs-scrub script.

Is your filesystem really full? Misbalanced metadata

Unfortunately btrfs has another failure case where the metadata space can fill up. When this happens, even though you have data space left, no new files will be writeable.
In the example below, you can see Metadata DUP 9.5GB out of 10GB. Btrfs keeps 0.5GB for itself, so in the case above, metadata is full and prevents new writes.
One suggested way is to force a full rebalance, and in the example below you can see metadata goes back down to 7.39GB after it's done. Yes, there again, it would be nice if btrfs did this on its own. It will one day (some if it is now in 3.18).
Sometimes, just using -dusage=0 is enough to rebalance metadata (this is now done automatically in 3.18 and above), but if it's not enough, you'll have to increase the number.
# btrfs fi df .
Data, single: total=800.42GiB, used=636.91GiB
System, DUP: total=8.00MiB, used=92.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=10.00GiB, used=9.50GiB
Metadata, single: total=8.00MiB, used=0.00

legolas:/mnt/btrfs_pool2# btrfs balance start -v -dusage=0 /mnt/btrfs_pool2
Dumping filters: flags 0x1, state 0x0, force is off
  DATA (flags 0x2): balancing, usage=0
  Done, had to relocate 91 out of 823 chunks

legolas:/mnt/btrfs_pool2# btrfs fi df .
Data, single: total=709.01GiB, used=603.85GiB
System, DUP: total=8.00MiB, used=88.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=10.00GiB, used=7.39GiB
Metadata, single: total=8.00MiB, used=0.00

Are you using space_cache?

Probably you've maded a massive copy like a Tb copy with features like space_cache enabled. While space_cache is nice and accelerate things up, you'll probably need to empty this cache. It's easier than you think:

# mount -o remount,clear_cache
# sync
# reboot 

26 October 2019

Make the Macbook touchpad works like MacOS (a modern and definitive guide)

There's a lot of tutorials about that on the internet, I'll try to be as much distribution-agnostic as possible. If your distribution doesn't the package that I'm talking about, you should search elsewhere or compile yourself.

Requirements:

A working Xorg (not sure if works with wayland) and a working DE/WM
xbindkeys
xdotool
dispad
mtrack driver

Recipe:

Uninstall whatever the touchpad driver you're using, like synaptics, and install mtrack. And use the following configuration for that (in /etc/X11/xorg.conf or /etc/X11/xorg.conf.d/10-mtrack.conf):

Section "InputClass"
        MatchIsTouchpad "on"
        Identifier      "Touchpads"
        MatchDevicePath "/dev/input/event*"
        Driver          "mtrack"
        # The faster you move, the more distance pointer will travel, using "polynomial" profile
        Option          "AccelerationProfile" "2"
        # Tweak cursor movement speed with this
        Option          "Sensitivity" "0.08"
        # Pressure at which a finger is detected as a touch
        Option          "FingerHigh" "5"
        # Pressure at which a finger is detected as a release
        Option          "FingerLow" "5"
        # I often use thumb to press down the physical button, so let's not ignore it
        Option          "IgnoreThumb" "true"
        Option          "ThumbRatio" "70"
        Option          "ThumbSize" "25"
        # Ignore palm, with palm takes up to 30% of your touch pad
        Option          "IgnorePalm" "true"
        Option          "PalmSize" "30"
        # Trigger mouse button when tap: 1 finger - left click, 2 finger - right click, 3 - middle click
        Option          "TapButton1" "1"
        Option          "TapButton2" "3"
        Option          "TapButton3" "2"
        Option          "TapButton4" "0"
        Option          "ClickTime" "25"
        # Disable tap-to-drag, we're using three finger drag instead
        Option          "TapDragEnable" "false"
        # While touching the touch pad with # fingers, press the touchpad physical click button
        Option          "ClickFinger1" "1"
        Option          "ClickFinger2" "3"
        Option          "ClickFinger3" "2"
        Option          "ButtonMoveEmulate" "false"
        Option          "ButtonIntegrated" "true"
        # The momentum after scroll fingers released
        Option          "ScrollCoastDuration" "300"
        Option          "ScrollCoastEnableSpeed" ".1"
        # Natural scrolling with two fingers
        Option          "ScrollSmooth" "true"
        Option          "ScrollUpButton" "5"
        Option          "ScrollDownButton" "4"
        Option          "ScrollLeftButton" "6"
        Option          "ScrollRightButton" "7"
        # Tweak scroll sensitivity with ScrollDistance, don't touch ScrollSensitivity
        Option          "ScrollDistance" "250"
        Option          "ScrollClickTime" "10"
        # Three finger drag
        Option          "SwipeDistance" "1"
        Option          "SwipeLeftButton" "1"
        Option          "SwipeRightButton" "1"
        Option          "SwipeUpButton" "1"
        Option          "SwipeDownButton" "1"
        Option          "SwipeClickTime" "0"
        Option          "SwipeSensitivity" "1500"
        # Four finger swipe, 8 & 9 are for browsers navigating back and forth respectively
        Option          "Swipe4LeftButton" "9"
        Option          "Swipe4RightButton" "8"
        # Mouse button >= 10 are not used by Xorg, so we'll map them with xbindkeys and xdotool later
        Option          "Swipe4UpButton" "11"
        Option          "Swipe4DownButton" "10"
        # Mouse buttons triggered by 2-finger pinching gesture
        Option          "ScaleDistance" "300"
        Option          "ScaleUpButton" "12"
        Option          "ScaleDownButton" "13"
        # Mouse buttons trigger by 2-finger rotating gesture, disabled to enhance the pinch gesture
        Option          "RotateLeftButton" "0"
        Option          "RotateRightButton" "0"
EndSection


By now, your trackpad will be working with a lot better. Pay attention to the comments if you need to customize. Now we'll create a map for what we still need. You can adjust the modifiers to fit your needs, or just remap then in your DE/WM. Create a $HOME/.xbindkeysrc with this:

# Next Workspace (Swipe4Left)
"xdotool key --clearmodifiers Control_L+Alt_L+Left"
   b:8
# Previous Workspace (Swipe4Right)
"xdotool key --clearmodifiers Control_L+Alt_L+Right"
   b:9
# Desktop Grid (Swipe4Down)(F4 key)
"xdotool key --clearmodifiers XF86LaunchA"
   b:11
# Toggle Present Windows (Current Desktop) (Swipe4Up)(F5 key)
"xdotool key --clearmodifiers XF86LaunchB"
   b:10
# Zoom in
"xdotool key ctrl+21"
   b:12
# Zoom out
"xdotool key ctrl+20"
   b:13


Dispad have a better touchpad-ignore than mtrack, so we're using it. Create this configuration at $HOME/.dispad (I know, it could be .dispadrc but the default is .dispad so I'll keep it):

# name of the property used to enable/disable the trackpad
property = "Trackpad Disable Input"
# the value used to enable the trackpad
enable = 0
# the value used to disable the trackpad
disable = 1
# whether or not modifier keys disable the trackpad
modifiers = false
# how long (in ms) to sleep between keyboard polls
poll = 48
# how long (in ms) to disable the trackpad after a keystroke
delay = 500


With the files in place, now we need to create a $HOME/.xprofile:

xbindkeys -f $HOME/.xbindkeysrc
dispad -c $HOME/.dispad

Reboot

Sources used:

https://int3ractive.com/2018/09/make-the-best-of-MacBook-touchpad-on-Ubuntu.html
https://bill.harding.blog/2017/12/27/toward-a-linux-touchpad-as-smooth-as-macbook-pro/

26 September 2019

The fragmentation

Since  a lot of stupid people loves to say that all the time, let me explain using your falacies arguments.

Too many package managers

No, there's not "too many package managers", this is called choice. You can CHOOSE what use it. Like portage? Use gentoo. Like apt? Use a debian-oriented one. And the list goes on. Don't like rpm? Then use something that doesn't use it and be happy. No one is obligated to use something just because you like it. Having choices is good for everyone, maybe not for you. 

Too many desktop managers/window managers

Again, you can choose one that suits you better. You can even use one that the configuration is done inside the code. It's good to have choices, and there's a plenty out there.

Too many init systems

Any decent distribution let's you choose what init you want, and you use what is easy/better for you. Even so, most distributions that uses, let say, systemd, there's an alternative without it.

Too many tools

For what job? Some tools have alternatives, some with a lot of features but not everyone wants lots of features. For example, I like syslog-ng better for a syslog, but there's simple ones. 

Final thoughts

I understand, people that born limited are unable to understand how is "having choices". Maybe you don't want to choose, maybe you want that the world turns around you, maybe you want that everyone make the exact same choices as you. Maybe you should stick to windows and stop talking this bullshit everywhere. Or even better, move to some place that everyone is forced to do the same.

11 September 2019

Recovery a freebsd after whatever problem

If you had any trouble with your install (ndis module someone), there's an easy way to fix it.
  1. Boot your pendrive/cdrom/dvd/whatever with the freebsd install
  2. Enter the shell or start the LiveCD option (livecd is root without any password)
  3. Create a directory where you can import your zfs pool: mkdir /tmp/zroot
  4. Import your zpool there: zpool import -fR /tmp/zroot zroot 
  5. Need access to /? No problem: mkdir /tmp/root && mount -t zfs zroot/ROOT/default /tmp/root
  6. When you're done, unmount everything: zpool export zroot 
  7. Reboot
Messed up your bootloader? No problem (this is for EFI boot):
  1. Check your partition table to see what number is your EFI partition: gpart show
  2. Re-setup your EFI partition: gpart bootcode -p /boot/boot1.efifat -i 1 ada0
  3. Check if ada0p1 is FAT just to be sure: file -s /dev/ada0p1
  4. Setup bootcode (-i3 if your zfs is ada0p3): gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0


05 September 2019

Organizing your clusterfuck collection of wallpapers

I have a directory filled with wallpapers that syncs with my devices, so I can use a random wallpaper (usually, change at boot or every 24h, whatever comes first). For the sake of organization, let's make this straight:

First, convert everything to png, because why not?


find . -name "*.jpg" -exec mogrify -format png {} \;

Double check your files and then delete the remaining jpgs (or whatever format you're converting):

rm *.jpg

Now, let's organize by number:

num=0; for i in *; do mv "$i" "$(printf '%04d' $num).${i#*.}"; ((num++)); done
 
If you need to add more wallpapers to this directory, remember to change the num= to the last wallpaper of this directory +1.

21 August 2019

Can't unlock KDE Session

If for some reason you're unable to unlock your desktop, then probably is the permissions of kcheckpass. You have two choices:

1) Reinstall kde-plasma/kscreenlocker
2) Check the permissions of /usr/lib64/libexec/kcheckpass, it should be 4755 and owned by root:root
3) A more radical solution:
#!/bin/bash

# Screen locker broken in KDE with ConsoleKit
# See https://forums.gentoo.org/viewtopic-t-1046566.html
# and https://forums.gentoo.org/viewtopic-t-1054134.html

# Find which session is locked
session=Session$(ck-list-sessions | grep -B10 "x11-display = ':0" | grep -o -P '(?<=Session).*(?=:)')

# Create Bash script to unlock session
echo "#!/bin/bash" > $HOME/unlock.sh
echo "su -c 'dbus-send --system --print-reply --dest=\"org.freedesktop.ConsoleKit\" /org/freedesktop/ConsoleKit/$session org.freedesktop.ConsoleKit.Session.Unlock'" >> $HOME/unlock.sh
chmod +x $HOME/unlock.sh

# Run Bash script in another TTY
openvt -s -w $HOME/unlock.sh
 

30 July 2019

Filesystem benchmarks

Ok, let's get this straight.
When I choose to use JFS, it's because some years ago I see with my own eyes how JFS is reliable in different scenarios and it still is. Yes, EXT4 is reliable too, but the performance isn't on par with JFS, but both offers a reliable and secure solution. XFS in other hand isn't that secure and reliable (it is to point), but offers a quite good performance. When kernel 5.0 came out, they talked a lot about how BTRFS is good now and, different from most people that rely on "everyone uses, so I'll use too" I want to test myself because I'm not the guy that relies on this  "everyone guy" opinion.
The host used for this test is my main desktop using gentoo linux with the last available kernel (5.2.4-gento0) and last available tools to date (i5-3470 on a gigabyte motherboard, 16gb of ram, sata3 1Tb hdd). The disk is entirely formated with the filesystem being tested. All filesystems are mounted using noatime and using bfq scheduler (bfq offers better performance for rotational disks than mq-deadline)). The IOZone tests was executed with a reboot before creating the new filesystem to test to exclude any possible bias.

Test 1: Creating a 1Gb file with dd=/dev/urandom of=test bs=1024 count=1M (in seconds):
JFSEXT4XFSBTRFSZFS
7.313.2914.214.5

Test 2: Cold reboot during the creation of the 1Gb file from one filesystem to another (5 times)

JFSEXT4XFSBTRFSZFS
Auto Fixed?5/55/53/54/54/5
Mounted rw without fixing01241
Wasn't able to fixing00121
Continue working with problems without reporting00121

Test 3: Copy a 1Gb file from one filesystem to another
JFSEXT4XFSBTRFSZFS
9s15s11s19s17s

Test 4: Cold reboot during mariadb heavy worload (5 times)

JFSEXT4XFSBTRFSZFS
Auto Fixed?5/55/54/54/54/5
Corrupted databases?NYYYN
Mounted rw with problemsNNYYN
Continue working with problems without reportingNNYYN

Test 5: Boot from EFI to lightdm, sata3 hdd, mounting / and /home (5 times)

JFSEXT4XFSBTRFSZFS
Normal0:280:491:011:301:27
After a cold reboot0:421:221:402:112:10

Test 6: Shutdown from lightdm to total shutdown (openrc) 
JFSEXT4XFSBTRFSZFS
0:150:210:410:580:42

Test 7: IOZone

My overall opinion:
  • JFS and EXT4 are good, performance wise and secure enough for daily usage.
  • XFS was polished through the years and the most awkward problems was taken off (data corruption with power loss and others), it's a good option but have some issues with performance depending of size and mass of data
  • ZFS is good but you need ram to have a good overall performance, I would suggest start with 16Gb for a desktop (this isn't a problem for a server, of course). Also, keep in mind that the mainline kernel doesn't support ZFS, it takes sometime for ZFS reach the last line (right now, ZOL supports up to 5.1.x). Also, despite the comparison of performance between ZFS and BTRFS seems to be similar, ZFS is far more stable and trustful.
  • By cpu/mem footprint in a copy, JFS is the lighter and ZFS the heavier. Of course, will also depend of how much data are you copying from where to where and kind of storage, but in overall, let's put this way: Copy lots of tiny files JFS > EXT4 > BTRFS > ZFS > XFS. Copy lots of big files: JFS/EXT4 > XFS > ZFS > BTRFS. Of course, the mileage will vary depending on the use case (it can be irrelevant with a full non-virtualized server with lots of ram and a good storage system).
  • Only use BTRFS if you like to restore backups often. To date, I can't trust BTRFS, not after seeing a filesystem having corruption with simple tests. -> http://lkml.iu.edu/hypermail/linux/kernel/1907.1/05873.html

Notes by 20190810:
  • XFS resolved the issues caused by power loss and metadata corruption. 
  • For XFS, the performance can benefit more with mq-deadline than bfs, afaik. Otherwise, use this recommendation in udev and don't forget to use noatime if you don't need it.
  • BTRFS still not ready, it can offer some benefits and performance, but the stability is still far from being acceptable, the auto-healing doesn't work as expected (like zfs, for instance) and scrub doesn't fix as expected in some scenarios. They're getting straight, a lot of this stuff seems to being fixed from 5.2 and beyond.
  • The fact of a filesystem receiving more kernel or userland updates doesn't mean it's more stable, or better, or whatever.
  • You SHOULD do your tests instead of talking bullshit like "everyone uses" or "it's an uncommon use". If the kernel supports it, it's supported. Period.