All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Steve Dickson <SteveD@RedHat.com>,
	Lennart Poettering <mzxreary@0pointer.de>,
	systemd-devel@freedesktop.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfs.man: document incompatibility between "bg" option and systemd.
Date: Fri, 09 Jun 2017 07:54:09 +1000	[thread overview]
Message-ID: <874lvqb0xq.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20170608153649.GB8625@fieldses.org>

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

On Thu, Jun 08 2017, J. Bruce Fields wrote:

> On Thu, Jun 08, 2017 at 03:16:52PM +1000, NeilBrown wrote:
>> So I think I've found a solution for systemd to handle "bg" nfs mounts
>> correctly.   I'll submit some pull requests for consideration.
>
> Out of curiosity, after that change is there still any reason you'd
> recommend any new user actually use "bg" (as opposed to an automount)?

Me? Recommend?  Who would listen?  Who would even hear?
For the last few years I've been recommending that automount should
be used for *all* NFS mounts at every opportunity.  I think I've had two
opportunities.

But no, I would not recommend "bg".  I would recommend automount and
then when they reported problems,  I would help fix them.

I would be much happier recommending automount if it were easier.
Setting up /etc/auto.direct with automountd is fairly easy, but you need
to actually enable it but modifying auto.master or auto.master.d, which
is slightly annoying.

systemd does make it easier to do direct mounts, but it is ugly.
You need to include "comment=systemd.automount" or "x-systemd.automount"
in /etc/fstab instead of just "automount" or "ondemand".  I understand
exactly why they did that and I cannot fault the logic.  But it still
looks clumsy.

With systemd, you cannot divorce the timeout that an application has to
wait when accessing the mountpoint while the server is down, from the
timeout imposed on the mount program.  i.e., mount cannot keep trying
in the background. - that could be useful if you want really-short
timeouts... at least it seems to me that they should be separate.

The timeout is configured differently if mounting from a device, or
mounting from anything else such as NFS.  The first uses
x-systemd.device-timeout.  The other needs x-systemd.mount-timeout.


But I'm ranting... I should probably shut up and send patches.
A generator for /etc/fstab.auto??

>
> I appreciate the effort to keep existing systems working, I'm just
> curious.

Compatibility with existing practice is certainly the main driver.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-06-08 21:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26  2:46 systemd and NFS "bg" mounts NeilBrown
2017-05-29 13:38 ` [systemd-devel] " Lennart Poettering
2017-05-29 22:05   ` NeilBrown
2017-05-29 22:19   ` [PATCH] nfs.man: document incompatibility between "bg" option and systemd NeilBrown
2017-05-30  4:47     ` Niels de Vos
2017-05-30  7:40     ` [systemd-devel] " Michael Biebl
2017-05-30  8:55       ` NeilBrown
2017-05-30  9:15         ` Michael Biebl
2017-05-30 12:45           ` Lennart Poettering
2017-05-30 12:43     ` Lennart Poettering
2017-06-06 18:07     ` Steve Dickson
2017-06-06 19:57       ` [systemd-devel] " Michael Biebl
2017-06-07  8:13         ` Lennart Poettering
2017-06-07  9:42           ` Steve Dickson
2017-06-06 21:49       ` NeilBrown
2017-06-07 10:08         ` Steve Dickson
2017-06-07 12:02           ` Lennart Poettering
2017-06-07 19:48             ` Steve Dickson
2017-06-08  5:16               ` NeilBrown
2017-06-08 15:36                 ` J. Bruce Fields
2017-06-08 21:54                   ` NeilBrown [this message]
2017-06-08 20:24                 ` Steve Dickson
2017-06-07  8:12       ` Lennart Poettering
2017-06-07 10:04         ` Steve Dickson
2017-06-07 16:08           ` J. Bruce Fields
2017-06-08 20:34             ` Steve Dickson
2017-07-04 22:20     ` NeilBrown
2017-07-10 15:26       ` Steve Dickson
2017-07-10 22:56         ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874lvqb0xq.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=SteveD@RedHat.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mzxreary@0pointer.de \
    --cc=systemd-devel@freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.