| |||||||||||||
Linux Storage and Filesystem workshop, day 1Linux Storage and Filesystem workshop, day 1Posted Apr 7, 2009 22:05 UTC (Tue) by dberkholz (subscriber, #23346)Parent article: Linux Storage and Filesystem workshop, day 1
One possible solution to this problem is to simply decree that union mounts cannot be exported via NFS. It's not clear that there is a plausible use case for this kind of export in any case.Imagine an LTSP server or another cluster fileserver that wants to ship out a shared base filesystem with host- or class-specific "overlays" for different roles.
(Log in to post comments)
Linux Storage and Filesystem workshop, day 1 Posted Apr 8, 2009 1:11 UTC (Wed) by ewan (subscriber, #5533) [Link]
I'd have thought the usual approach to that would be to export the
read-only base and the host specific overlay and unify them on the client, not union mount the two on the server and export the result.
Linux Storage and Filesystem workshop, day 1 Posted Apr 8, 2009 4:50 UTC (Wed) by jamesh (guest, #1159) [Link]
If the union is done on the client, then modifying to a file stored in the base layer would involve reading the file contents over the network, then writing it back to the server over the network again.
A union performed on the server would only result in local IO when copying the file between layers.
I'm not sure how much of a difference this would make though, since it'd only really hit renames of files in the base layer or partial modification of files. Neither the "truncate and overwrite" or "write to a temporary file and rename over old" methods of writing files would show much difference between server and client side unions.
|
|||||||||||||