Re: Re: Preventing writes to the underlying directory when a mounted filesystem disappears

Hi,

On Mon, Jul 27, 2026 at 11:06:13AM -0300, Marcelo Laia wrote:
> The motivation here is a little different. I'm trying to understand how
> Linux behaves when the target filesystem unexpectedly disappears and how
> to prevent applications from silently falling back to the underlying
> filesystem.

In practice I don't think that is a problem that happens. If you
uncleanly yank a storage device, power it off or whatever, it is
filesystem-dependent but what tends to happen is:

- I/O either blocks forever or eventually returns an I/O error
- I/O errors force the filesystem read-only
- Later writes fail instantly due to read-only FS, reads may still block
  or return I/O error.

The filesystem doesn't get unmounted. The block device node itself may
or may not still be there. Given that rsyslogd would have files open
inside that broken/missing block device, it is actually very possible
that you would not then be able to cleanly stop or start rsyslogd from
then on.

So this question of, "what if the underlying mount point is exposed?"
can only really apply either before the filesystem is mounted or if the
filesystem becomes cleanly unmounted due to user action. These are
different problems to device failure. 

Storage redundancy is the correct way to guard against device failure.
For the misconfiguration case I'd probably look at if there is a systemd
dependency type that forcibly stops the rsyslogd service if the specific
mount unit is not active, but I might not try very hard with this one as
it's not going to be easy for a user to cleanly unmount such a
filesystem once rsyslogd is logging to it )it will be in use).

Thanks,
Andy