LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Takashi Sato <t-sato@yk.jp.nec.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Andreas Dilger <adilger@sun.com>, 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, 15 Feb 2008 08:24:08 -0600 [thread overview]
Message-ID: <47B5A088.6050801@redhat.com> (raw)
In-Reply-To: <79B050214DA541F9A8B193C7AACC3C7B@nsl.ad.nec.co.jp>
Takashi Sato wrote:
> Hi,
>
> Christoph Hellwig wrote:
>> On Fri, Feb 08, 2008 at 08:26:57AM -0500, Andreas Dilger wrote:
>>> You may as well make the common ioctl the same as the XFS version,
>>> both by number and parameters, so that applications which already
>>> understand the XFS ioctl will work on other filesystems.
>> Yes. In facy you should be able to lift the implementations of
>> XFS_IOC_FREEZE and XFS_IOC_THAW to generic code, there's nothing
>> XFS-specific in there.
>
> According to Documentation/ioctl-number.txt,
> XFS_IOC_XXXs (_IOWR('X', aa, bb)) are defined for XFS like below.
> From Documentation/ioctl-number.txt:
> ----------------------------------------------------------------------------
> Code Seq# Include File Comments
> ========================================================
> : :
> 'X' all linux/xfs_fs.h
> ----------------------------------------------------------------------------
It also says:
'f' 00-1F linux/ext2_fs.h
and yet include/linux.h has:
#define FS_IOC_GETFLAGS _IOR('f', 1, long)
#define FS_IOC_SETFLAGS _IOW('f', 2, long)
as generic vfs ioctls. These ioctls started out as
EXT2_IOC_SETFLAGS/EXT2_IOC_GETFLAGS but they were generically useful,
other filesystems picked them up, and they were "elevated" to the vfs.
> So XFS_IOC_FREEZE and XFS_IOC_THAW cannot be lifted to generic code simply.
It would be a simple matter of changing the documentation, I think.
> I think we should create new generic numbers for freeze and thaw
> like FIBMAP as followings.
> linux/fs.h:
> #define FIFREEZE _IO(0x00,3)
> #define FITHAW _IO(0x00,4)
>
> And xfs_freeze calls XFS_IOC_FREEZE with a magic number 1, but what is 1?
Looks like it's called "level" but it's probably a holdover, it doesn't
look like it's used.
> Instead, I'd like the sec to timeout on freeze API in order to thaw
> the filesystem automatically. It can prevent a filesystem from staying
> frozen forever.
> (Because a freezer may cause a deadlock by accessing the frozen filesystem.)
I'm still not very comfortable with the timeout; if you un-freeze on a
timer, how do you know that the work for which you needed the fileystem
frozen is complete? How would you know if your snapshot was good if
there's a possibility that the fs unfroze while it was being taken?
Thanks,
-Eric
> Any comments are very welcome.
>
> Cheers, Takashi
>
next prev parent reply other threads:[~2008-02-15 14:24 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
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 [this message]
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=47B5A088.6050801@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@sun.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=t-sato@yk.jp.nec.com \
--cc=tytso@MIT.EDU \
--subject='Re: [RFC] ext3 freeze feature' \
/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
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).