LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: t-sato@yk.jp.nec.com
To: Eric Sandeen <sandeen@redhat.com>, Christoph Hellwig <hch@infradead.org>
Cc: 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: Tue, 19 Feb 2008 20:27:06 +0900	[thread overview]
Message-ID: <20080219202706t-sato@mail.jp.nec.com> (raw)
In-Reply-To: <47B5A088.6050801@redhat.com>


Hi,

>#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.

Thank you for good information.
I will elevate XFS_IOC_FREEZE and XFS_IOC_THAW to the VFS.

>> 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.

I see.

>> 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?

My following freeze ioctl never perform the timeout when 0 is specified
as timeval.  So, existent applications which don't expect the timeout
can stay frozen with 0.
 int ioctl(int fd, int FIFREEZE, long *timeval);
    fd:file descriptor of mountpoint
    FIFREEZE:request cord for freeze
    timeval:timeout period (second)

And how about adding the new ioctl to reset the timeval like below?
(Dmitri proposed this idea before.)
 int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval);
    fd:file descriptor of mountpoint
    FIFREEZE_RESET_TIMEOUT:request cord for reset of timeout period 
    timeval:new timeout period
This is useful for the application to set the timeval more accurately.
For example, the freezer resets the timeval to 10 seconds every 5
seconds.  In this approach, even if the freezer causes a deadlock
by accessing the frozen filesystem, it will be solved by the timeout
in 10 seconds and the freezer can recognize that at the next reset
of timeval.

Any comments are very welcome.

Cheers, Takashi

  reply	other threads:[~2008-02-19 11:28 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
2008-02-19 11:27               ` t-sato [this message]
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=20080219202706t-sato@mail.jp.nec.com \
    --to=t-sato@yk.jp.nec.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=sandeen@redhat.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).