Closed lloydhazlett closed 9 years ago
Ubuntu calls this module overlayfs renaming it from what upstream calls it? Please post the output of:
find /lib/modules -name 'overlay*.ko*'
Seems like it:
$ find /lib/modules -name 'overlay*.ko*'
/lib/modules/3.13.0-43-generic/kernel/fs/overlayfs/overlayfs.ko
Further complicating things, I also noticed the version of overlayfs that is included appears to pre-date the workdir option, which was added and made required in overlayfs v22. OpenWrt dealt with this by mounting without it, and then retrying with workdir if the first attempt failed.
Interesting... so Ubuntu kernels must all use this pre v23 out-of-tree 'overlayfs' while other distros using kernel version 3.18+ use one called 'overlay' ... the psd will need an ability to determine which one it needs to use and act accordingly. As you see, I will need to use a different sync setup and a different mount command. For example, see https://github.com/graysky2/profile-sync-daemon/blob/master/common/profile-sync-daemon.in#L543-L548
Thoughts are welcome.
Example v23+:
mount -t overlay overlaid -olowerdir="$BACKUP",upperdir="$TMPRW",workdir="$TMPWK" "$TMP"
Example v22 and below:
mount -t overlayfs overlaid -olowerdir="$BACKUP",upperdir="$TMPRW" "$TMP"
How about testing /proc/filesystems
which lists filesystems supported by the running kernel? I think that's more what you intended when warning about the kernel version <=3.18. You could then assume overlayfs should mount without workdir, where overlay should mount with e.g.
$ grep overlayfs /proc/filesystems
nodev overlayfs
Yes, but only if the user has the module loaded prior to loading psd. I still can't think of a good way to have psd load it when a normal user calls it is parse mode (since non-root users cannot run modprobe).
Is having psd load the module for you essential? I'd assumed having it loaded already would be a prerequisite for using this feature.
True... let me play a bit and see. Are you willing to test under Ubuntu from the unstable branch?
I just tagged v5.60 (https://github.com/graysky2/profile-sync-daemon/releases/tag/v5.60) from my unstable branch which I have tested a bit in a 14.10 in a VM and on my main Arch box. The code seems to be working just fine.
Diffs: https://github.com/graysky2/profile-sync-daemon/compare/v5.59...v5.60
You can simply grab the main script (common/profile-sync-daemon.in) and put it into your /usr/bin dropping the .in suffix. Make it +x and you should be in business. Build the formal release if you want the new man page and reworded psd.conf though.
% psd p
Profile-sync-daemon v5.60 on Ubuntu 14.10
Daemon pid file is present.
Resync cronjob is present.
Overlayfs v22 is currently active.
Psd will manage the following per /var/run/psd.conf settings:
browser/psname: chromium/chromium
owner/group id: facade/1000
sync target: /home/facade/.config/chromium
tmpfs dir: /run/shm/facade-chromium
profile size: 8.8M
overlayfs size: 8.0M
browser/psname: firefox/firefox
owner/group id: facade/1000
sync target: /home/facade/.mozilla/firefox/vd1iqcbn.default-1395954548178
tmpfs dir: /run/shm/facade-firefox-vd1iqcbn.default-1395954548178
profile size: 14M
overlayfs size: 13M
browser/psname: firefox/firefox
owner/group id: facade/1000
sync target: /home/facade/.mozilla/firefox/u7fq8p97.number2
tmpfs dir: /run/shm/facade-firefox-u7fq8p97.number2
profile size: 12M
overlayfs size: 0
Can you please test it on your Ubuntu box with your setup and provide some feedback. Is it ready for prime time?
Have tested the unstable branch on 14.04 with firefox and chrome, all looks good to me :thumbsup:
For me as well. Released. Thanks for the suggestion. https://github.com/graysky2/profile-sync-daemon/releases/tag/v5.60 https://launchpad.net/~graysky/+archive/ubuntu/utils
Thanks for adding overlayfs support. Testing it on Ubuntu 14.04 (or 12.04 with the trusty kernel) fails though since the module name is overlayfs rather than just overlay. The trusty kernel is version 3.13 and it looks like Ubuntu may have had overlayfs support back through to 11.10, so the notes about requiring kernel version >=3.18 were a little misleading in this case.