Make fstab changes persistent

Hi!

I have an external SSD drive that needs two changes in fstab to work as expected. First, there is the option “ssd” to make it load ssd optimizations. Additionally, “noauto” is removed to make it work as needed in my setup.

Desired fstab looks like:

UUID=xxx /mnt/xxx btrfs ssd,noatime,lazytime,rw,nofail,auto,x-systemd.automount

Here you can see the benefit of the ssd option:

root@DietPi:~# dmesg
[    7.230446] BTRFS info (device sda1): enabling ssd optimizations
[    7.230484] BTRFS info (device sda1): disk space caching is enabled
[    7.230496] BTRFS info (device sda1): has skinny extents

However, these changes only last until dietpi-drive_manager is launched again.

How can these changes be made persistent and survive drive_manager?

Actually this is how drive manager is working, to remove custom entries and replace it with default values :roll_eyes:. We are aware of these downside and planning to change the behaviour. However we don’t have an ETA.

Workaround would be not to use drive manager to configure fstab entries.

@MichaIng FYI

But this is only for BTRFS fs, right?

https://btrfs.wiki.kernel.org/index.php/FAQ

There are some optimizations for SSD drives, and you can enable them by mounting with -o ssd. As of 2.6.31-rc1, this mount option will be enabled if Btrfs is able to detect non-rotating storage.

Also the TRIM function has to be enabled seperatly, with the option discard (can inpact SSD performance) or the better way: use fstrim , which runs as a service.

Yes, the ssd option is for BTRFS. Ext4 doesn’t know it.

Regarding TRIM: either no mount option or “discard=async” for BTRFS.

1 Like

Regarding the ssd option: The driver is nowadays clever enough to autodetect via /sys/block/*/queue/rotational whether it is an SSD (or other flash drive) or not to set the flag/optimisations automatically. So this should usually not be requried.

The fstrim.timer is enabled by default to run fstrim.service once a week. So the discard=async option could be skipped if the drive’s free space isn’t fully rewritten once in a week.

But yes, I agree we need to change dietpi-drive_manager’s behaviour to not rewrite the whole /etc/fstab when you run it.

2 Likes

Sorry to drag up an old thread, but this would be amazing if possible.

Even better would be an options tab in dietpi-drive_manager, where you can add in various SMB options. This would mean you wouldn’t have to change the behaviour of it re-writing /etc/fstab if we didn’t have to manually modify it.

Found this today, i am just bumping. :eyes:

Hi,

I am having similiar woes and as I write this am thinking of going back raspbian. Trying to get LVM going it was easy when I did it in Raspbian first and then trying it in DietPi feels like the OS is just fighting me.

I moved the original to dietpi-drive_manager_auto
I replaced the /boot/dietpi/dietpi-drive_manager
with
#!/bin/bash
exit 0

To stop it auto generating the fstab file.
Now though the LVM file system is mounted read-only. I can’t see what is causing it in the journalctl -b logs. Only mount -o remount, rw / works. Will raise another post for that.

Our drive manager is overwriting /etc/fstab only if you open it. It is not doing this automatically. Therefore replacing drive manager script doesn’t make any sense. You simply don’t need to use it. That’s the limitation only.

For creating LVM should behave same way as on RPI OS.