Why a bindfs rather than a symlink?

[danwdart]

Just wondered why we bother with bindfs rather than just using a symlink? Wouldn't a bindfs allow blocking until the persistent filesystem is mounted, and wouldn't it not have to wait until half way through the user's session start to be able to be used?

I'm just seeing a lot of things that aren't yet mounted on login even though I should see every mount first, e.g. desktop settings, wifi password keychains etc

[lovesegfault]

You mean for the home-manager module or for the NixOS module?

I use the latter extensively and haven't had any similar issues, so I wonder why you're seeing these delayed mounts.

#1 has a long discussion on improving our API to give users more control over how they want state exposed, but work on it has not yet begun.

[danwdart]

I mean the home-manager module, but I embed home-manager in the NixOS configuration by importing "${home-manager}/nixos" and then "${impermanence}/home-manager.nix" if that makes a difference.

Maybe items under ~ would be better managed by environment.persistence instead of inside home.persistence...

[talyz]

The reason for using bindfs over symlinks is that some applications don't work well with symlinks and either complain, replace the symlink or just refuse to start. A bind mount is much more transparent to the application, but real bind mounts can't be created by a user, so bindfs was chosen instead.

I'm not really sure what problems you're having with the bind mounts. They should be started with your user session as systemd user services. Do you mean that they're not yet started when you've logged in?

[nigelgbanks]

On Linux could regular binds be used instead? The performance hit from using fuse can be significant. For example the following is from within the directory at its bindfs mounted destination directory.

dd if=/dev/zero of=./test.img count=10 bs=1G
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 18.0036 s, 596 MB/s

The following is performance in the source directory:

dd if=/dev/zero of=./test.img count=10 bs=1G
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 5.633 s, 1.9 GB/s

It's about 4 times faster.

[talyz]

With #44 in place, you could use the regular NixOS module to replace the home-manager one completely, if you want to get rid of bindfs. The reason we can't use regular bind mounts in the home-manager module is that regular users aren't allowed to create them.

[danwdart]

Yes, bindfs is slow to copy/move between things that are really on the same FS as well.

I still don't know why we couldn't just symlink instead of bindfs though - I understand why not regular bind mount. Maybe there ought to be an option because some things like Steam don't start properly if you use ~/.steam with a bindfs (I already have ~/.local/share/Steam as one too) but will start with a symlink.

Should I use the NixOS one as you said in https://github.com/nix-community/impermanence/issues/42#issuecomment-954029089? How would I adapt my config - https://github.com/nix-community/impermanence/issues/42#issuecomment-895852965 - to use the NixOS one instead?

[talyz]

There were a few applications which didn't work with symlinks - GnuPG is the one I remember right now. There were also issues when you wanted to persist a directory and let home-manager handle some files in it, at least with the way the symlinking was implemented. bindfs should be more transparent to the applications, just like regular bind mounts are.

Sure, it's possible to support both, if necessary. I wasn't aware of any applications which had issues with bindfs and haven't tried using the module with Steam. What errors are you getting?

Going back to your original question, though, what do you mean with things not being mounted on login? The bind mounts are supposed to be set up early on login, before anything else starts in the session. Do they fail completely or do you mean some services start before them and can't access their files?

When using the NixOS module instead of the home-manager one, you would have to specify the whole user folder path for all the files and directories, but otherwise, usage should be the same. Something like this:

{
  environment.persistence."/persistent/home/talyz" = {
    directories = [
      "/home/talyz/Downloads"
      "/home/talyz/Music"
      "/home/talyz/Pictures"
      "/home/talyz/Documents"
      "/home/talyz/.gnupg"
      "/home/talyz.ssh"
    ];
    files = [
      "/home/talyz/.screenrc"
    ];
  };
}

[nigelgbanks]

When using NixOS module the bind mounts are created as the root user which creates problems on subsequent writes into those folders if say your mounting into .config.

[talyz]

I've implemented proper support for users in the NixOS module in #70. This includes solving the permissions issue you mentioned, @nigelgbanks. It also allows for setting default ownership and mode for created directories in general, which is useful for directories used for storing secrets. Help testing it would be appreciated. If it works well enough, I think we could deprecate the home-manager module altogether.

[danwdart]

@talyz - That sounds really awesome! @nigelgbanks - I didn't have a problem with permission with the bind/btrfs mounts though, as the directories I was binding in were owned by me already. The only thing I couldn't do was delete the mounted directory (naturally).

[nigelgbanks]

I had a bit of an odd use case that I've since abandoned in which my home directory was a tmpfs filesystem, but I would bind mount folders like Downloads Projects and things like .config/spotify into the directory from an actual persistent disk. So some of the bind mounts were creating their parent folders. It was too much of a pain to maintain though so I've opt'd to make my home directory the bind mount which is fine.

[etu]

I had a bit of an odd use case that I've since abandoned in which my home directory was a tmpfs filesystem, but I would bind mount folders like Downloads Projects and things like .config/spotify into the directory from an actual persistent disk.

You know, this isn't an odd use-case at all. In the rest of the world, it may sound odd. But this project was mainly created around this use-case :wink: