xfs
[Top] [All Lists]

Re: [RFC PATCH 1/3] Implement generic freeze feature

To: Takashi Sato <t-sato@xxxxxxxxxxxxx>
Subject: Re: [RFC PATCH 1/3] Implement generic freeze feature
From: Andreas Dilger <adilger@xxxxxxx>
Date: Mon, 19 May 2008 21:57:12 -0600
Cc: "linux-ext4@xxxxxxxxxxxxxxx" <linux-ext4@xxxxxxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>, "dm-devel@xxxxxxxxxx" <dm-devel@xxxxxxxxxx>, "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>
In-reply-to: <20080514170625t-sato@xxxxxxxxxxxxxxx>
References: <20080514170625t-sato@xxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.17 (2007-11-01)
On May 14, 2008  17:06 +0900, Takashi Sato wrote:
> +static int ioctl_freeze(struct file *filp)
> +{
> +     struct super_block *sb = filp->f_path.dentry->d_inode->i_sb;
> +
> +     if (!capable(CAP_SYS_ADMIN))
> +             return -EPERM;
> +
> +     /* If filesystem doesn't support freeze feature, return. */
> +     if (sb->s_op->write_super_lockfs == NULL)
> +             return -EINVAL;

Should this be EINVAL, or EOPNOTSUPP?  Usually EINVAL means there is
something wrong with the passed ioctl parameters (e.g. bad value),
while EOPNOTSUPP is "operation not supported" and makes more sense.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.


<Prev in Thread] Current Thread [Next in Thread>