Re: service directory on NFS-mounted filesystem

From: Jameson Graef Rollins <jrollins_at_finestructure.net>
Date: Tue, 17 Sep 2013 19:43:04 -0700

On Tue, Sep 17 2013, Laurent Bercot <ska-supervision_at_skarnet.org> wrote:
>> A FIFO special file (a named pipe) is similar to a pipe, except
>> that it is accessed as part of the file system. It can be opened
>> by multiple processes for reading or writing. When processes are
>> exchanging data via the FIFO, the kernel passes all data inter‐
>> nally without writing it to the file system. Thus, the FIFO spe‐
>> cial file has no contents on the file system; the file system
>> entry merely serves as a reference point so that processes can
>> access the pipe using a name in the file system.
>
> That means you aren't storing any data into the filesystem. The metadata,
> however, still needs to be accessed. When you're resolving
> /mnt/nfs/fifo, you're still performing a NFS query, and if the NFS server
> happens to be down at that moment, whoopsie-boopsie.
> Once your file descriptors are open, though, you're probably safe.

Thanks, Laurent. This is the kind of consideration I was looking for.

On Tue, Sep 17 2013, Laurent Bercot <ska-supervision_at_skarnet.org> wrote:
> Original daemontools, runit and s6 all work on read-only
> filesystems: you just have to have a "supervise" symlink
> (and also an "event" symlink in the case of s6-supervise) pointing
> to a writable filesystem. This symlink can even be dangling at
> boot time, for instance pointing to a RAM filesystem that is only
> created during initialization.

But upon further consideration, making the supervise directories
symlinks to a tmpfs, as you suggest here, will work for my needs and
will probably end up being more robust.

Thanks for all the suggestions.

jamie.



Received on Wed Sep 18 2013 - 02:43:04 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:18 UTC