Systemd mountd - switching a filesystem under the hood

Schlunze · 2019-07-25 18:13:33

Hello,

i need your help guys. The plan was to reduce the power consumption of my home server.
It will be substituted from a pi4 with an attached a ssd most of the time. Sadly, there is not enough
discspace for all my media stuff @ the new mountpoint.

The idea was to copy the most important media files on the pi and export it for the local network 24/7
The old server, will be started if i need anyting else of my stuff.

Here is the schematic content of the exports:

old server:
/storage/Videos/A
/storage/Videos/B
/storage/Videos/C

new server:
/storage/Videos/A

Here is the config from the new pi4 so far.

#/etc/fstab
# bindmounts
/home/USER/Videos                    /storage/Videos             none    defaults,bind           0 0

#nfs-shares - currently experimenting with systemd mountd - options
192.168.2.2:/storage/Videos       /home/USER/Videos      nfs    rw,noauto,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.device-timeout=10,retry=0,soft,nolock        0 0

#/etc/exports
/storage/Videos                 192.168.2.0/24(rw,no_root_squash,no_subtree_check,nohide,fsid=0)

After systemctl daemon-reload the old share is mounted correctly @ the new mount point.
The export of the bind mount work as expected. (/storage/Videos/A,B,C is visible)

If the old server is turned off, the export seems to freeze. When the share is reachable again, freezing stops.
I expected that only the content of /home/USER/Videos (/storage/Videos/A) is visible in this state.

If you got a solution for this freeze problem, or a better strategy to archive someting similar, please let me know.

Greetings

Last edited by Schlunze (2019-07-26 18:24:21)

seth · 2019-07-25 20:51:47

You mean like the servers share an IP (192.168.2.2) and you intend to silently switch them under the hood??
Don't.
It's not gonna work and you risk data integrity at best.

What you could do instead would be to turn the Pi into a hub for the oldserver™ ie. mount B & C from the oldserver™ next to the A on the Pi. You'd then always talk to the Pi and that will use the oldserver™ as a conditional source.

Schlunze · 2019-07-26 18:12:56

Hello,

yes exactly "switching a filesystem under the hood" is very much of that i want to achive.
This thread should get a new Headline. Thanx for that seth.

But im not that kind of linux pro and need advice.

#Mountpoints under the hood

new source	192.168.2.6:/storage/Videos	#nfs export for local network
desired source	/home/USER/Videos		#mp for new nfs source, bindmount ro?
old source	192.168.2.2:/storage/Videos 	#mp for new nfs source ro, rw possible?

My clients should be fed from new source
The desired source should be switched to old source "under the hood"
if old source is avalible in the local network
and back if not.

Is it possible with Systemd mountd?

@ seth: dont know i understand your cause about data integrety right.
Do you mean in case of a lost connection or power failure? Maybe mount ro is a solution.

Edit config files on two servers every time i add or remove A´s sounds not very comfortable if i get it right.

Config files:
A´s /etc/fstab @ the desired source
BC´s /etc/exports @ old source

mount both sources (desired and old) @ new source (export with crossmnt or nohide option?)

Greetings

Last edited by Schlunze (2019-07-26 19:26:13)

seth · 2019-07-26 19:12:55

You have to understand that those are not the same filesystems. You might randomly have the same path names and data there, but they're still different disks, exports, inodes etc.
Any way to undermine those validity checks would run serious risk to compromise data (on writes at least, because of caching, deferred action etc.: you might end up writing parts on one and other parts onto the other server) - just don't event attempt that.

If anything, you'll have to unmount the share first, then switch the servers and have the automount, well, auto-mount the new share on further accesses. You cannot (and should by no means attempt) change the share while the filesystem is mounted.

My personal advice however stands and would be to turn the Raspi into a conditional hub for the oldserver™, ie. mount the oldserver™ exports on the raspi and mount the raspi exports everywhere else.

Schlunze · 2019-07-26 19:50:27

Thanks for the explanation with inodes, i think i get the point now. It is not wise to mount two sources @ one mountpoint.

My problem is, that the clients expect one nfs source because of a central database.
It is possible to export ro in my case, there is no no need to write on it directly.
In the first line im searching a workaround for that particular problem.

Your idea switching under the hood still sounds good to me,

Mounting one after another destination itself shoud be possible with systemd mountd i think
But i have no idea to automate the switching.

Last edited by Schlunze (2019-07-26 20:10:17)

seth · 2019-07-26 19:54:50

I'm not sure whether I actually successfully conveyed the message… are you german?

Schlunze · 2019-07-26 20:10:54

seth wrote:

I'm not sure whether I actually successfully conveyed the message… are you german?

Yes and always to late...

seth · 2019-07-26 20:40:04

Zu spät? Edit: Ah, cause of the username ;-)

(This is basically a german summary of former statements, I'll summarize final conclusions)

Du kannst nicht einfach den Server austauschen. Das Dateisystem merkt sich, was genau da auf der anderen Seite exportiert wurde und es merkt, daß das nicht mehr das selbe ist. Ich wüßte auch nicht, daß sich dieser Abgleich einfach, etwa per Option, umgehen ließe - wenn, müßte man den NFS code patchen (was, wie gesgt, keine gute Idee ist. Unter anderem wirst Du Schwierigkeiten kriegen, wenn irgendein Kopiervorgang in egal welche Richtung auf dem einen System gestartet und auf dem anderen fortgesetzt werden soll)

Was Du machen kannst ist:
1. die NFS Partition unmounten bevor Du den einen Server abziehst und sie neu mounten nachdem der andere da ist.
2. Videos/B und Videos/C vom alten server per NFS auf dem Raspi unter /storage/Videos mounten. Du hast dann auf dem Raspi Videos/A, Videos/B und Videos/C wobei die letzen beiden nur funktionieren, solange der alte Server zur Verfügung steht. Auf dem client moutest Du dann ganz normal /home/USER/Videos vom Raspi, der merkt nichts von der Serverkaskade. Der alte Server und der Rapi müssen dafür natürlich unterschiedliche IPs haben
3. Du mountest 192.168.2.2:/storage/Videos/A nach /home/USER/Videos/A und 192.168.2.6:/storage/Videos/B und 192.168.2.6:/storage/Videos/C nach /home/USER/Videos/B und /home/USER/Videos/C

Mit den bind mounts hat das nichts zu tun - ein bind mount erlaubt es dir, ein Verzeichnis in einem anderen Verzeichnis zusätzlich zu haben, fast so als wäre ein Verzeichnis ein symlink auf das andere Verzeichnis. Im speziellen läßt Du /home/USER/Videos auf dem client auch unter /storage/Videos erscheinen.

Last edited by seth (2019-07-26 20:40:50)

Arch Linux

#1 2019-07-25 18:13:33

Systemd mountd - switching a filesystem under the hood

#2 2019-07-25 20:51:47

Re: Systemd mountd - switching a filesystem under the hood

#3 2019-07-26 18:12:56

Re: Systemd mountd - switching a filesystem under the hood

#4 2019-07-26 19:12:55

Re: Systemd mountd - switching a filesystem under the hood

#5 2019-07-26 19:50:27

Re: Systemd mountd - switching a filesystem under the hood

#6 2019-07-26 19:54:50

Re: Systemd mountd - switching a filesystem under the hood

#7 2019-07-26 20:10:54

Re: Systemd mountd - switching a filesystem under the hood

#8 2019-07-26 20:40:04

Re: Systemd mountd - switching a filesystem under the hood

Board footer