All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Takashi Sato <t-sato@yk.jp.nec.com>
Cc: linux-fsdevel@vger.kernel.org, dm-devel@redhat.com,
	viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org,
	xfs@oss.sgi.com, hch@infradead.org, axboe@kernel.dk,
	mtk.manpages@googlemail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] Implement generic freeze feature
Date: Thu, 21 Aug 2008 12:58:41 -0700	[thread overview]
Message-ID: <20080821125841.a04a706f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080818212819t-sato@mail.jp.nec.com>

On Mon, 18 Aug 2008 21:28:19 +0900
Takashi Sato <t-sato@yk.jp.nec.com> wrote:

> The ioctls for the generic freeze feature are below.
> o Freeze the filesystem
>   int ioctl(int fd, int FIFREEZE, arg)
>     fd: The file descriptor of the mountpoint
>     FIFREEZE: request code for the freeze
>     arg: Ignored
>     Return value: 0 if the operation succeeds. Otherwise, -1
> 
> o Unfreeze the filesystem
>   int ioctl(int fd, int FITHAW, arg)
>     fd: The file descriptor of the mountpoint
>     FITHAW: request code for unfreeze
>     arg: Ignored
>     Return value: 0 if the operation succeeds. Otherwise, -1
> 
>
> ...
>
> --- linux-2.6.27-rc2.org/include/linux/fs.h	2008-08-06 13:49:54.000000000 +0900
> +++ linux-2.6.27-rc2-freeze/include/linux/fs.h	2008-08-07 08:59:54.000000000 +0900
> @@ -226,6 +226,8 @@ extern int dir_notify_enable;
>  #define BMAP_IOCTL 1		/* obsolete - kept for compatibility */
>  #define FIBMAP	   _IO(0x00,1)	/* bmap access */
>  #define FIGETBSZ   _IO(0x00,2)	/* get the block size used for bmap */
> +#define FIFREEZE	_IOWR('X', 119, int)	/* Freeze */
> +#define FITHAW		_IOWR('X', 120, int)	/* Thaw */

FIFREEZE is 119, but a few lines above we have

#define BLKDISCARD _IO(0x12,119)

Should we be using 120 and 121 here?

>  #define	FS_IOC_GETFLAGS			_IOR('f', 1, long)
>  #define	FS_IOC_SETFLAGS			_IOW('f', 2, long)
> @@ -574,6 +576,10 @@ struct block_device {
>  	 * care to not mess up bd_private for that case.
>  	 */
>  	unsigned long		bd_private;
> +	/* The counter of freeze processes */
> +	int			bd_freeze_count;
> +	/* Semaphore for freeze */
> +	struct semaphore	bd_freeze_sem;

"freeze" is not an adequate description of what this protects.  I think
it's only the modification and testing of bd_freeze_count, isn't it?

If so, all this could be done more neatly by removing the lock,
switching to atomic_t and using our (rich) atomic_t operations.

otoh, perhaps it protects more than this, in which case the lock
can/should be switched to a `struct mutex'?



  reply	other threads:[~2008-08-21 19:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18 12:28 [PATCH 1/3] Implement generic freeze feature Takashi Sato
2008-08-18 12:28 ` Takashi Sato
2008-08-21 19:58 ` Andrew Morton [this message]
2008-08-22  7:09   ` Andreas Dilger
2008-08-29  9:36   ` Takashi Sato
2008-08-29  9:36     ` Takashi Sato
2008-08-29  9:36     ` Takashi Sato
2008-08-22 18:14 ` Christoph Hellwig
2008-08-29  9:37   ` Takashi Sato
2008-08-29  9:37     ` Takashi Sato
2008-08-29  9:37     ` Takashi Sato
2008-09-04 16:55 ` Eric Sandeen
2008-09-04 16:55   ` Eric Sandeen
2008-09-11 10:58   ` Takashi Sato
2008-09-11 10:58     ` Takashi Sato
2008-09-11 10:58     ` Takashi Sato
  -- strict thread matches above, loose matches on Subject: below --
2008-09-08 11:52 Takashi Sato
2008-09-08 17:10 ` Christoph Hellwig
2008-09-11 11:11   ` Takashi Sato
2008-09-11 11:11     ` Takashi Sato
2008-09-11 11:11     ` Takashi Sato
2008-09-11 11:11     ` Takashi Sato
2008-07-22  9:37 Takashi Sato
2008-07-22  9:37 ` Takashi Sato
2008-07-22  9:37 ` Takashi Sato
2008-06-30 12:23 Takashi Sato
2008-07-01  8:08 ` Christoph Hellwig
2008-06-24  6:59 Takashi Sato
2008-06-24  6:59 ` Takashi Sato
2008-06-24 21:48 ` Andrew Morton
2008-06-27 11:33   ` Takashi Sato
2008-06-27 11:33     ` 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=20080821125841.a04a706f.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@googlemail.com \
    --cc=t-sato@yk.jp.nec.com \
    --cc=viro@ZenIV.linux.org.uk \
    --cc=xfs@oss.sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.