linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Colin Walters <walters@verbum.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>,
	xfs <linux-xfs@vger.kernel.org>
Cc: "linux-fsdevel" <linux-fsdevel@vger.kernel.org>,
	"linux-ext4" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] vfs: freeze filesystems just prior to reboot
Date: Fri, 19 May 2017 10:00:31 -0400	[thread overview]
Message-ID: <1495202431.1896310.982081664.066926F8@webmail.messagingengine.com> (raw)
In-Reply-To: <20170519002032.GA21202@birch.djwong.org>

On Thu, May 18, 2017, at 08:20 PM, Darrick J. Wong wrote:

> Therefore, add a reboot hook to freeze all filesystems (which in general
> will induce ext4/xfs/btrfs to checkpoint the log) just prior to reboot.
> This is an unfortunate and insufficient workaround for multiple layers
> of inadequate external software, but at least it will reduce boot time
> surprises for the "OS updater failed to disengage the filesystem before
> rebooting" case.

As a maintainer of one of those userspace tools (https://github.com/ostreedev/ostree),
which I don't think is the one in question here, but likely has the same
issue - I'd like to have some sort of API to fix this - maybe flush the journal *without*
remounting r/o?

Unlike the case you're talking about with rebooting into a special
update mode, libostree constructs a new root with hardlinks while
the system is running.  Hence, system downtime is just reboot, like
dual-partition update systems, except we're more flexible.

Although hm...I guess an API to flush the journal would only narrow
the race.

Is the single partition case really just doomed?  

  parent reply	other threads:[~2017-05-19 14:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19  0:20 [PATCH] vfs: freeze filesystems just prior to reboot Darrick J. Wong
2017-05-19  8:29 ` Amir Goldstein
2017-05-19 18:58   ` Darrick J. Wong
2017-05-19 14:00 ` Colin Walters [this message]
2017-05-19 15:27   ` Theodore Ts'o
2017-05-19 16:34     ` Colin Walters
2017-05-19 16:48       ` Colin Walters
2017-05-19 18:20       ` Theodore Ts'o
2017-05-19 19:41     ` Darrick J. Wong
2017-05-23 11:10     ` Jan Kara
2017-05-19 19:01   ` Darrick J. Wong
2017-08-03 20:24     ` Colin Walters
2017-08-05 14:16       ` Christoph Hellwig
2017-08-05 15:45         ` Darrick J. Wong
2017-08-11 10:02           ` Christoph Hellwig
2017-08-11 16:26             ` Darrick J. Wong
2017-08-11 16:27               ` Christoph Hellwig

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=1495202431.1896310.982081664.066926F8@webmail.messagingengine.com \
    --to=walters@verbum.org \
    --cc=darrick.wong@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).