Page MenuHomeSoftware Heritage

somerset: please mount /srv/softwareheritage/scratch
Closed, MigratedEdits Locked

Description

Can we mount the scratch space on somerset? I do data exports from postgres on that machine from time to time (as it's the DB replica) and it would be useful to pipe them directly to the shared scratch space.

Note that the mount line for all of space is in /etc/fstab, but it is noauto. Also, it is above the postgres mount point in the FS hierarchy, so I think it should be mounted first to avoid shadowing it.

Event Timeline

zack triaged this task as Wishlist priority.May 13 2020, 10:27 AM
zack created this task.

You had written "belvedere" in the task description but I'm assuming you meant "somerset" instead.

(I'll skip the rant about wanting to get rid of NFS, as I don't have anything better to suggest)

Automatic nfs mounts in lxc containers are a pain. Theoretically, lxc containers are not supposed to be allowed to mount anything; mounts should happen in the container host; but nfs doesn't really cross container boundaries that well because of quirks of uid mapping. So we've hacked the proxmox apparmor profile to allow nfs mounts within the container.

I think this was set to use systemd's automount, but I think systemd also detects that it's running in a container, and avoids doing any mounts on boot.

We should probably add a systemd unit to do mount -a in late boot so nfs can start up.

I've dropped noauto from fstab now; I can confirm that running mount -a after boot makes the mount point show up.

I've also added the /srv/softwareheritage/scratch -> /srv/storage/space symlink.

I see that a bunch of mount* units are masked on that system, I'll investigate further before just adding another unit to mount -a.

In T2404#44390, @olasd wrote:

I see that a bunch of mount* units are masked on that system, I'll investigate further before just adding another unit to mount -a.

Looks like red herrings (from the legacy initscripts package).