From: "Takashi Sato" <t-sato@yk.jp.nec.com>
To: "Theodore Tso" <tytso@MIT.EDU>, <linux-ext4@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] ext3 freeze feature
Date: Fri, 8 Feb 2008 19:48:25 +0900 [thread overview]
Message-ID: <01cd01c86a40$21d49410$41a8400a@bsd.tnes.nec.co.jp> (raw)
In-Reply-To: <20080125133329.GB8184@mit.edu>
Hi,
Ted wrote:
> And I do agree that we probably should just implement this in
> filesystem independent way, in which case all of the filesystems that
> support this already have super_operations functions
> write_super_lockfs() and unlockfs().
>
> So if this is done using a new system call, there should be no
> filesystem-specific changes needed, and all filesystems which support
> those super_operations method functions would be able to provide this
> functionality to the new system call.
OK I would like to implement the freeze feature on VFS
as the filesystem independent ioctl so that it can be
available on filesystems that have already had write_super_lockfs()
and unlockfs().
The usage for the freeze ioctl is the following.
int ioctl(int fd, int FIFREEZE, long *timeval);
fd:file descriptor of mountpoint
FIFREEZE:request cord for freeze
timeval:timeout period (second)
And the unfreeze ioctl is the following.
int ioctl(int fd, int FITHAW, NULL);
fd:file descriptor of mountpoint
FITHAW:Request cord for unfreeze
I think we need the timeout feature which thaws the filesystem
after lapse of specified time for a fail-safe in case the freezer
accesses the frozen filesystem and causes a deadlock.
I intend to implement the timeout feature on VFS.
(This is realized by registering the delayed work which calls
thaw_bdev() to the delayed work queue.)
Any comments are very welcome.
Cheers, Takashi
next prev parent reply other threads:[~2008-02-08 10:50 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-25 10:59 Takashi Sato
2008-01-25 11:17 ` Pekka Enberg
2008-01-25 12:42 ` Takashi Sato
2008-01-26 5:17 ` David Chinner
2008-01-26 19:10 ` Christoph Hellwig
2008-01-25 12:18 ` Dmitri Monakhov
2008-01-25 13:33 ` Theodore Tso
2008-01-25 16:34 ` Eric Sandeen
2008-01-25 16:42 ` Theodore Tso
2008-02-02 13:52 ` Pavel Machek
2008-01-28 13:13 ` Takashi Sato
2008-02-01 3:03 ` Kazuto Miyoshi
2008-01-31 8:53 ` Daniel Phillips
2008-02-07 1:05 ` Takashi Sato
2008-02-08 10:48 ` Takashi Sato [this message]
2008-02-08 13:26 ` Andreas Dilger
2008-02-08 14:59 ` Christoph Hellwig
2008-02-15 11:51 ` Takashi Sato
2008-02-15 14:24 ` Eric Sandeen
2008-02-19 11:27 ` t-sato
2008-02-26 8:20 ` [RFC] ext3 freeze feature ver 0.2 Takashi Sato
2008-02-26 16:39 ` Eric Sandeen
2008-02-26 17:08 ` Andreas Dilger
2008-02-27 8:31 ` Takashi Sato
2008-03-07 9:13 ` [RFC] freeze feature ver 1.0 Takashi Sato
2008-02-16 13:25 ` [RFC] ext3 freeze feature Christoph Hellwig
2008-02-13 8:23 ` Takashi Sato
2008-01-26 5:35 ` David Chinner
2008-01-26 5:39 ` David Chinner
2008-01-28 13:07 ` Takashi Sato
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='01cd01c86a40$21d49410$41a8400a@bsd.tnes.nec.co.jp' \
--to=t-sato@yk.jp.nec.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome