Can the rapiddisk-on-boot script be used for drives besides /?

[8465231]

Ok, so I think I have a system pretty much working for rapiddisk testing.

I now have an issue where if I reboot the system I can not start rapiddisk since the mount point is locked due to being in use.

Can the on-boot script be used for drives besides root? I need to mount the raided LVM partition and then add the rapiddisk before services are started like docker.

[pkoutoupis]

I will need to differ to @matteotenca on this one.

[matteotenca]

Ok, so I think I have a system pretty much working for rapiddisk testing.

I now have an issue where if I reboot the system I can not start rapiddisk since the mount point is locked due to being in use.

Can the on-boot script be used for drives besides root? I need to mount the raided LVM partition and then add the rapiddisk before services are started like docker.

The latest version of rapiddisk-on-boot allows to add many mappings upon boot time. The configurations are saved to etc and can be different for every kernel installed. For example, you can instruct it to create any number of mappings upon boot, between a ramdisk of choosen size, created upon boot, and an existing block device - exactly what you're asking for. You can handle this using the script, or creating an appropriate config file in etc bypassing the tool (initramfs must be recreated, though, after the changes).

This new version will be merged into the main branch asap, as far ad @pkoutoupis Petros will accept it.

As of today, I suggested Petros to postpone the merge of the new version of rapiddisk-on-boot, since I did not write documentation yet and since I did not double-checked for major bugs.

It is usable and works, it does not support drakut based distros, yet, but is not a real problem to extend the compatibility.

If you want to give it a try, there is a branch with the new version - but beware, it is not up to date with the latest master branch of rapiddisk. This means you should discard everything but the folder with the script. BEWARE: it still beta.

You can find it here: https://github.com/matteotenca/rapiddisk/tree/rpdsk-on-boot/multi_mappings

Let me know what you think.

Regards

[8465231]

Cool, I will look into that if I have time later, I ended up hobbling together my own service wrapped script to handle the rapiddisk mounting just after fstab so that the LVM volume would exist to be mapped.

It is working so far but it is not elegant lol.

[8465231]

A problem that I need to solve is related to the writeback caches: under Ubuntu, I have to find the right place (systemd-wise) to send a flush command before unmount. I managed to do it with mapping involving root, but other writeback mappings, when unmounted, may still hold unflushed data.

Interesting, I am also using ubuntu but have not gotten to the unmounting part of testing yet.

What is the command for flushing the data out of ram anyways? I had not noticed a command for this and just kind of assumed it was handled during the umount.

Please post what you find here.

[matteotenca]

What is the command for flushing the data out of ram anyways? I had not noticed a command for this and just kind of assumed it was handled during the umount.

The writeback mode is handled by an external kernel module called dm-cache. To force the write of the data to disk, a tool named dmsetup must be used. Read the man page for details, but long story short the command is:

$ dmsetup message <complete path to the rapiddisk device to be flushed> 0 flush

Example:

$ dmsetup message /dev/mapper/rc-wb_rc-wa_sda2 0 flush

I suggest you to read this comment too: write-around plus write-back caches

[8465231]

The writeback mode is handled by an external kernel module called dm-cache. To force the write of the data to disk, a tool named dmsetup must be used. Read the man page for details, but long story short the command is:

$ dmsetup message <complete path to the rapiddisk device to be flushed> 0 flush

Example:

$ dmsetup message /dev/mapper/rc-wb_rc-wa_sda2 0 flush

I suggest you to read this comment too: write-around plus write-back caches

I thought that the writeback used dm-writechache? Does the dmsetup work for that as well I guess?

Thanks for the heads up, I will look into this

[matteotenca]

I thought that the writeback used dm-writechache? Does the dmsetup work for that as well I guess?

Sorry, my fault, you're right, dm-writechache is used!

Thanks for the heads up, I will look into this

You're welcome!

[8465231]

Was just going to post my solution to the shutdown script, I am sure there are better options but this seems to be working:

#!/bin/sh
dmsetup message /dev/mapper/rc-wb_vast_data 0 flush

umount -v /dev/mapper/rc-wb_vast_data
rapiddisk -u rc-wb_vast_data
rapiddisk -d rd0

And to run it at the right time this service seems to do the trick

nano /etc/systemd/system/rapiddisk-stop.service

paste below into that file

[Unit]
Description=stop rapiddisk filesystem
DefaultDependencies=no
Before=shutdown.target reboot.target

[Service]
ExecStart=path/to/rapiddisk-stop.sh
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=shutdown.target reboot.target

Seems to be working in my testing so far.