From: Christoph Hellwig <hch@infradead.org>
To: "Ted Ts'o" <tytso@mit.edu>,
Alan Stern <stern@rowland.harvard.edu>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Tejun Heo <tj@kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: Revoking filesystems [was Re: Sysfs attributes racing with unregistration]
Date: Thu, 5 Jan 2012 13:38:32 -0500 [thread overview]
Message-ID: <20120105183831.GA21565@infradead.org> (raw)
In-Reply-To: <20120105182752.GC26382@thunk.org>
On Thu, Jan 05, 2012 at 01:27:52PM -0500, Ted Ts'o wrote:
> Ideally, we should do both. The block device should call a
> notification function (probably run out of a workqueue context, to
> avoid locking issues) which tells the file system, "the block device
> is _gone_ and isn't coming back". Any attempts to read or write to
> the block device should return errors, since there maybe writeback
> happening in the background while the file system is shutting down
> file system mount. Once the file system is done, it can all a
> function which tells the block device layer that it's OK to release
> the block device and its related structures.
FYI: we have all the functionality for that available in XFS and would
just need to wire it up. It's also triggered if we get a write I/O
error for metadata (typically the log), so with a minim delay we
actually provide that behaviour already.
> In order for the file system to shut down the file system cleanly, it
> will need to access VFS-level revoke functionality that replaces file
> descriptors with ones that returns an error on reads and writes, and
> which does the right thing with mmap's[1], etc.
And that part is close to impossible to get right.
next prev parent reply other threads:[~2012-01-05 18:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 16:52 Sysfs attributes racing with unregistration Alan Stern
2012-01-04 17:18 ` Tejun Heo
2012-01-04 18:13 ` Eric W. Biederman
2012-01-04 19:41 ` Alan Stern
2012-01-05 3:07 ` Eric W. Biederman
2012-01-05 15:13 ` Revoking filesystems [was Re: Sysfs attributes racing with unregistration] Alan Stern
2012-01-05 15:32 ` Tejun Heo
2012-01-05 16:03 ` Eric W. Biederman
2012-01-05 16:44 ` Tejun Heo
2012-01-05 16:47 ` Alan Stern
2012-01-05 17:11 ` Tejun Heo
2012-01-05 18:27 ` Ted Ts'o
2012-01-05 18:36 ` Tejun Heo
2012-01-05 19:28 ` Ted Ts'o
2012-01-05 20:52 ` Tejun Heo
2012-01-06 6:25 ` Alexander E. Patrakov
2012-01-07 21:01 ` Revoking filesystems [was Re: Sysfs attributes racing withunregistration] Milton Miller
2012-01-05 20:43 ` Revoking filesystems [was Re: Sysfs attributes racing with unregistration] Eric W. Biederman
2012-01-05 20:55 ` Tejun Heo
2012-01-05 18:38 ` Christoph Hellwig [this message]
2012-01-05 15:52 ` Eric W. Biederman
2013-01-14 15:11 ` watchdog code anish kumar
2012-01-05 18:18 ` Revoking filesystems [was Re: Sysfs attributes racing with unregistration] Greg KH
2012-01-04 18:13 ` Sysfs attributes racing with unregistration Alan Stern
2012-01-04 18:20 ` Tejun Heo
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=20120105183831.GA21565@infradead.org \
--to=hch@infradead.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tj@kernel.org \
--cc=tytso@mit.edu \
/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.