Zygo / bees

Best-Effort Extent-Same, a btrfs dedupe agent
GNU General Public License v3.0
692 stars 56 forks source link

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

Open nitroxis opened 11 months ago

nitroxis commented 11 months ago

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 commented 11 months ago

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
kakra commented 11 months ago

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.

Connor22 commented 10 months ago

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

kakra commented 7 months ago

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 to the service. You can use systemctl edit beesd@.service (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.