[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070427101012.GA1714@infradead.org>
Date: Fri, 27 Apr 2007 11:10:12 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Theodore Tso <tytso@....edu>,
Nigel Cunningham <nigel@...el.suspend2.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Xavier Bestel <xavier.bestel@...e.fr>,
Pekka Enberg <penberg@...helsinki.fi>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.
On Thu, Apr 26, 2007 at 05:38:07PM -0400, Theodore Tso wrote:
> On Fri, Apr 27, 2007 at 06:08:01AM +1000, Nigel Cunningham wrote:
> > We tried that. It would need some work. IIRC remounting filesystems
> > read-only makes files become marked read-only. Perfectly sensible,
> > except that if you then remount the filesystem rw at resume time, all
> > those files are still marked ro and userspace crashes and burns. Not
> > unfixable, I'll agree, but there is more work to do there.
>
> There are other solutions, though. One is that we could export a
> system call interface which freezes a filesystem and prevents any
> further I/O. We mostly have something like that right now (via the
> the write_super_lockfs function in the superblock operations
> structure), but we haven't exported it to userspace.
It is exported on XFS ;-)
> We would also need a similar interface to freeze any block device I/O,
> in case you have a database running and doing direct I/O to a block
> device. (Or again, we could simply not support that case; how many
> people will be running running a database accessing a block deivce on
> their laptop?)
block device I/O uses generic_file*whateveriscurrenthere*_write, which
checks for the freeze flag, so the infrastructure for that is there
aswell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists