1. 17

  2. 8
    1. 5

      I have been waiting for root volumes to be read only for a while. Then they can maybe ship updates as differential file system snapshots…

      1. 2

        Without knowing much about the implementation, the bidirectional wormholes look nice on the surface.

        1. 2

          I think a new take on bind and maybe union mounts would have been cooler.

          Symlinks already make things complicated, but now you have two types and who knows if there is the need for something like lstat(2) or additional flags for open(2) like O_NOFOLLOW.

          Edit: Firmlinks only work for volume groups is limiting compared to bind mounts. But I guess this is why they don’t really need extra syscalls or flags to deal with it because they are only intended to map to the “Data” volumes in volume groups.

        2. 2

          One thing I would really like to see being added is a file attribute to toggle the file-case sensitivity on a per-folder basis. Right now it’s possible to toggle it but only on a volume level which makes a few use-cases more difficult than necessary:

          It would allow to unpack tar archives without having to worry about file collision.

          I would have my ~/code folder be toggled as case-sensitive to make sure the software also works on Linux.

          And then toggle it back off on projects that don’t work,

          And slowly they can start marking more and more of the system as being case-sensitive while legacy software is being deprecated.

          1. 1

            Could somebody tell me if I’m understanding firmlinks correctly? They’re like a symbolic link in that they refer to somewhere else by name rather than inode, and as such can point across volumes. But for example let’s say /sys@ -> /usr/src/sys, then

            /sys/.. -> /

            instead of

            /sys/.. -> /usr/src

            which would be the case for a regular symlink.