From: Gregory Farnum <gfarnum@redhat.com>
To: John Spray <john.spray@redhat.com>
Cc: ceph-devel@vger.kernel.org, zyan@redhat.com, sage@redhat.com
Subject: Re: ceph-fuse remount issues
Date: Mon, 23 Feb 2015 00:14:18 -0500 (EST) [thread overview]
Message-ID: <133474621.9173173.1424668458008.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <54E66259.9040501@redhat.com>
----- Original Message -----
> From: "John Spray" <john.spray@redhat.com>
> To: ceph-devel@vger.kernel.org, zyan@redhat.com, "Gregory Farnum" <gfarnum@redhat.com>
> Sent: Thursday, February 19, 2015 2:23:21 PM
> Subject: ceph-fuse remount issues
>
>
> Background: a while ago, we found (#10277) that existing cache
> expiration mechanism wasn't working with latest kernels. We used to
> invalidate the top level dentries, which caused fuse to invalidate
> everything, but an implementation detail in fuse caused it to start
> ignoring our repeated invalidate calls, so this doesn't work any more.
> To persuade fuse to dirty its entire metadata cache, Zheng added in a
> system() call to "mount -o remount" after we expire things from our
> client side cache.
>
> However, this was a bit of a hack and has created problems:
> * You can't call mount -o remount unless you're root, so we are less
> flexible than we used to be (#10542)
> * While the remount is happening, unmounts sporadically fail and the
> fuse process can become unresponsive to SIGKILL (#10916)
>
> The first issue was maybe an acceptable compromise, but the second issue
> is just painful, and it seems like we might not have seen the last of
> the knock on effects -- upstream maintainers certainly aren't expecting
> filesystems to remount themselves quite so frequently.
Yeah. I looked at this briefly and switching to a conditional behavior based on kernel version shouldn't be too difficult; the actual change in behavior is a very short patch: https://github.com/ceph/ceph/commit/0827bb79ea5127e6763f6e904dfa1a3266046ffb
I'm going to try and integrate that in with my branch to warn on remount issues in the morning: https://github.com/ceph/ceph/pull/3681 (better version of that sitting on my computer now too)
> We probably have an opportunity to get something upstream in fuse to
> support a direct call to trigger the invalidation we want, if we can
> work out what that should look like. Thoughts?
Yes please. I don't really have the kernel VFS or FUSE interface experience here to offer up much off the top of my head, but I think this is something that FUSE ought to allow us to do. LSF/MM is coming up and Sage will be there, which is probably a good time to raise issues with people in the hallway or appropriate sessions.
-Greg
next prev parent reply other threads:[~2015-02-23 5:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 22:23 ceph-fuse remount issues John Spray
2015-02-23 5:14 ` Gregory Farnum [this message]
2015-02-26 8:28 ` 严正
2015-03-16 5:28 ` Sage Weil
2015-03-16 6:28 ` Yan, Zheng
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=133474621.9173173.1424668458008.JavaMail.zimbra@redhat.com \
--to=gfarnum@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=john.spray@redhat.com \
--cc=sage@redhat.com \
--cc=zyan@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox