[fhs-discuss] FHS exported filesystems

Tony Travis ajt at minke.ukfsn.org
Mon May 16 07:45:17 PDT 2011


On 16/05/11 15:15, Christoph Anton Mitterer wrote:
> Hi.
>
> First I don't think that FHS is very much tailored on single machines.
> Actually having things like /usr, /etc, /var makes it possible to have
> some parts (e.g. the packages) on a remote machine bug everything that's
> locally required (locks, pid files, config) locally.

Hi, Chris.

I'm particularly interested in 'servents' (hosts that are both clients 
and servers, as in the /export/home example). This is different to the 
conventional server-only or client-only host that you might be thinking 
about. What is different, is that the servent needs to mount it's own 
exported/shared filesystems in the same way as any other client does.

> On Mon, 16 May 2011 12:47:41 +0100, Tony Travis<ajt at minke.ukfsn.org>
> wrote:
>> This man page describes how /export is used under FreeBSD/SunOS:
> I personally don't like the idea of having a separate hierarchy for
> exported stuff.
> IMHO this belongs (at least in many cases) to /srv.

I'm not arguing the point, but simply observing that /export is still 
widely used for this purpose on NFS 'servers' as well as servents. The 
FHS update is an opportunity to consider how we might recommend network 
filesystems to be exported/shared and mounted in peer NFS networks.

> Especially it's questionable how exported filesystems differ from other
> things that are _conceptually_ also "exported", e.g. HTTP data, or take a
> SVN or CVS repository. These should likely go to /srv and one can in
> principle also mount them as filesystem (e.g. via FUSE in Linux).

My point is that if a host mounts, as a client, a filesystem that it 
also exports as a server then the local mountpoint must (obviously) be 
different. This was solved long ago in BSD/SunOS by mounting the 
directories to be served on /export, and using the NFS automounter or 
static NFS mounts to mount the exported directories on the same target 
directory on all hosts, including the host serving the filesystem.

> I'd say people should either put this in /srv or just make their own
> /<something>  if they really think they need to,.. e.g. something like
> /data/videos, /data/music .

Making your own /<something> is not really in the spirit of the FHS ;-)

> Actually it might be worth adding a /data hierarchy for this. Whether this
> is then exported or not is irrelevant.

Interestingly, this is exactly what I have done using "sshfs" and the 
linux automounter on the WAN. However, you are wrong that it doesn't 
matter if it is exported or not for the same reason that it matters on 
the LAN. In my case, I have:

   host1:/home/data -> /data/host1

Where /data is an auto-mountpoint for all of the hosts in the network.

I did consider using /export/data, but these are 'Bio-Linux' systems 
that assume /home is a directory (as opposed to an auto-mountpoint).

   http://nebc.nerc.ac.uk/tools/bio-linux/bio-linux-6.0

> The more I consider it, the more I like it (/data).
> If you export a whole filesystem this is either:
> a) any data
> b) something used on another system by some service (e.g. you have your
> maildirs from a pop3/imap server) stored on an NFS area.
>
> For a) I'd prefer having /data instead of /export.
> For b) I'd personally tend to use /srv

One of the virtues of using /export (or /srv) is that you can do e.g:

   /export/home
   /export/data
   /export/db
   ...

Bye,

   Tony.


More information about the fhs-discuss mailing list