bees icon indicating copy to clipboard operation
bees copied to clipboard

beesd script can't handle BEESHOME on a non-btrfs filesystem

Open nitroxis opened this issue 1 year ago • 4 comments

Hi,

currently, the beesd helper script always tries to create $BEESHOME as a subvolume (or checks whether it is one). However, it should be fine to have $BEESHOME set to e.g. a ext4 root partition, while bees is deduping a separate btrfs HDD, or am I mistaken? The docs seem to support this assumption

nitroxis avatar Dec 26 '23 21:12 nitroxis

Proposal for changing the check:

BEESHOME_FSTYPE=$(stat -f -c %T "$BEESHOME")
if [ "$BEESHOME_FSTYPE" = "btrfs" ]; then
    if [ ! -d "$BEESHOME" ]; then
        INFO "Create subvol $BEESHOME for store bees data"
        btrfs sub cre "$BEESHOME"
    else
        btrfs sub show "$BEESHOME" &> /dev/null || ERRO "$BEESHOME MUST BE A SUBVOL!"
    fi
else
    mkdir -p "$BEESHOME"
fi

nitroxis avatar Dec 26 '23 21:12 nitroxis

Yeah, it should be completely fine running the hash file on non-btrfs filesystems. I'm running it the same way here - actually by NOT using the beesd wrapper. Maybe create a PR so it gets merged.

kakra avatar Dec 27 '23 15:12 kakra

Adding onto the script change, I also needed to make sure that the script had access to the volume (such as adding ReadWritePaths=/var/.beeshome underneath the [service] header of the systemd service file) to get it working

Connor22 avatar Feb 04 '24 03:02 Connor22

If you are using customized configs (like a beeshome path differing from defaults), you should create a systemd override file instead to add the needed configs tp the service. You can use systemctl edit [email protected] (or whatever your service is called) to create per-service or even per-instance settings. This way, your individual customizations won't be overwritten by updates.

I'm pretty sure /var/.beeshome is a non-default setting.

kakra avatar Apr 22 '24 10:04 kakra