You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to add some doc around how to mount juicefs on boot with local cache.
Why is this needed:
I have 2 scripts to do this:
# Then enabled on boot:
# sudo systemctl enable jfs.mount
# Check status:
# systemctl status jfs.mount
#
# Remember, the file name jfs.mount must match the mount point /jfs.
# If you change the mount point, you must change the file name.
[Unit]
Description = juicefs on /jfs
After=network-online.target
[Install]
WantedBy = multi-user.target
[Mount]
What=redis://10.225.112.101:6379/1
Where=/jfs
Type=myjuicefs
I name the script jfs.mount and put it in /usr/lib/systemd/system
Then, I have a file called /sbin/mount.myjuicefs looks like this:
#!/bin/sh
# This only works on boot. We don't support mount/umounting multiple times within a boot
# because we don't have code to enumerate all the cache stuff and umount them.
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/file.json
if [ ! -f $GOOGLE_APPLICATION_CREDENTIALS ]; then
echo "Google application credentials file not found"
exit 1
fi
if mount | grep /cache >/dev/null; then
echo "Some cache disks are already mounted! Umount them and rerun this script!"
exit 1
fi
cache_dirs=""
cache_size=0
ssdid=1
for disk in /dev/nvme?n*; do
# skip disks already have partitions
echo $disk
if sudo fdisk -l $disk | grep -i gpt >/dev/null; then
echo "skipping $disk"
fi
mkfs.ext4 -F $disk || exit 1
mkdir -p /cache$ssdid || exit 1
mount $disk /cache$ssdid || exit 1
chown -R $USER:$USER /cache$ssdid || exit 1
touch /cache$ssdid/THIS_IS_A_CACHE_DIR_DONT_PUT_DATA_HERE || exit 1
if [ -z "$cache_dirs" ]; then
cache_dirs=/cache$ssdid
else
cache_dirs=$cache_dirs:/cache$ssdid
fi
cache_size=$((cache_size+300000))
ssdid=$((ssdid+1))
done
# $1: redis://10.225.112.101:6379/1
# $2: /jfs
# -d is for background
juicefs mount -d -o allow_other,allow_root --cache-dir $cache_dirs --cache-size $cache_size --writeback "$1" "$2"
after this, it will wipe and create local cache disks on boot everytime. it works for local ssds in the google cloud.
The text was updated successfully, but these errors were encountered:
Sorry I don't understand exactly what you want. The script doesn't appear to be generic, but rather customized for your environment. If you are looking for advice to mount JuiceFS at boot time, you may take a look at this page.
Hi Sandy, thanks for the pointer to that page. It is a very helpful page. However, there are few things to be improved on it:
I don't think the systemd script has "After=network-online.target" line that make sure it is invoked after network is up. For me, without it, the mount can fail.
For local cache, which is an important reason for using juicefs, there isn't much instructions
2.1 when local cache disk is already formatted, the doc needs to ensure the mount order is correct
2.2 when local cache disk needs to be formatted on boot (very common), custom script is needed
So, I think the situation I have is not unique to me. It is very common. It is a situation for all google cloud users. Perhaps other cloud users have the same issue. Therefore, I think the doc should be enhanced to cover those.
We use the _netdev option in the fstab to make sure that the mount happens after the the network and local disks are ready. As for automatically formatting the local disk on boot, that's beyond the capability of JuiceFS, you'd better write the script according to your own needs.
What would you like to be added:
I would like to add some doc around how to mount juicefs on boot with local cache.
Why is this needed:
I have 2 scripts to do this:
I name the script
jfs.mount
and put it in/usr/lib/systemd/system
Then, I have a file called
/sbin/mount.myjuicefs
looks like this:after this, it will wipe and create local cache disks on boot everytime. it works for local ssds in the google cloud.
The text was updated successfully, but these errors were encountered: