linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Lukas Czerner <lczerner@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Subject: RE: fs: Add FITRIM ioctl
Date: Thu, 28 Oct 2010 12:30:45 +0200	[thread overview]
Message-ID: <4CC950D5.8000603@panasas.com> (raw)

Lukas Czerner <lczerner@redhat.com> wrote:
> Gitweb:     http://git.kernel.org/linus/367a51a339020ba4d9edb0ce0f21d65bd50b00c9
> Commit:     367a51a339020ba4d9edb0ce0f21d65bd50b00c9
> Parent:     77ca6cdf0ab8a42f481ec997911bc89e79138723
> Author:     Lukas Czerner <lczerner@redhat.com>
> AuthorDate: Wed Oct 27 21:30:11 2010 -0400
> Committer:  Theodore Ts'o <tytso@mit.edu>
> CommitDate: Wed Oct 27 21:30:11 2010 -0400
> 

I've just noticed this patch. Was it posted to linux-fsdevel? Sorry
for missing it.

So I have a comment, and question.
---
>     fs: Add FITRIM ioctl
>     
>     Adds an filesystem independent ioctl to allow implementation of file
>     system batched discard support. I takes fstrim_range structure as an
>     argument. fstrim_range is definec in the include/fs.h and its
>     definition is as follows.
>     
>     struct fstrim_range {
>     	start;
>     	len;
>     	minlen;
>     }
>     
>     start	- first Byte to trim
>     len	- number of Bytes to trim from start
>     minlen	- minimum extent length to trim, free extents shorter than this
>     	  number of Bytes will be ignored. This will be rounded up to fs
>     	  block size.
>     

Was the range done so it could be called in parts, and progress displayed?

>     It is also possible to specify NULL as an argument. In this case the
>     arguments will set itself as follows:
>     
>     start = 0;
>     len = ULLONG_MAX;
>     minlen = 0;
>     
>     So it will trim the whole file system at one run.
>     
>     After the FITRIM is done, the number of actually discarded Bytes is stored
>     in fstrim_range.len to give the user better insight on how much storage
>     space has been really released for wear-leveling.
>     
>     Signed-off-by: Lukas Czerner <lczerner@redhat.com>
>     Reviewed-by: Dmitry Monakhov <dmonakhov@openvz.org>
>     Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> ---
>  fs/ioctl.c         |   39 +++++++++++++++++++++++++++++++++++++++
>  include/linux/fs.h |    8 ++++++++
>  2 files changed, 47 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index f855ea4..e92fdbb 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -530,6 +530,41 @@ static int ioctl_fsthaw(struct file *filp)
>  	return thaw_super(sb);
>  }
>  
> +static int ioctl_fstrim(struct file *filp, void __user *argp)
> +{
> +	struct super_block *sb = filp->f_path.dentry->d_inode->i_sb;
> +	struct fstrim_range range;
> +	int ret = 0;
> +
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EPERM;
> +
> +	/* If filesystem doesn't support trim feature, return. */
> +	if (sb->s_op->trim_fs == NULL)
> +		return -EOPNOTSUPP;
> +
> +	/* If a blockdevice-backed filesystem isn't specified, return EINVAL. */
> +	if (sb->s_bdev == NULL)
> +		return -EINVAL;
> +

What is the point of that? sb->s_bdev is not used anywhere in this code.
If an FS published an sb->s_op->trim_fs, it should know what it wants
No? Note that the FS in question does not even need to check. It already
knows if it's block based or not.

Thanks
Boaz

> +	if (argp == NULL) {
> +		range.start = 0;
> +		range.len = ULLONG_MAX;
> +		range.minlen = 0;
> +	} else if (copy_from_user(&range, argp, sizeof(range)))
> +		return -EFAULT;
> +
> +	ret = sb->s_op->trim_fs(sb, &range);
> +	if (ret < 0)
> +		return ret;
> +
> +	if ((argp != NULL) &&
> +	    (copy_to_user(argp, &range, sizeof(range))))
> +		return -EFAULT;
> +
> +	return 0;
> +}
> +
>  /*
>   * When you add any new common ioctls to the switches above and below
>   * please update compat_sys_ioctl() too.
> @@ -580,6 +615,10 @@ int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
>  		error = ioctl_fsthaw(filp);
>  		break;
>  
> +	case FITRIM:
> +		error = ioctl_fstrim(filp, argp);
> +		break;
> +
>  	case FS_IOC_FIEMAP:
>  		return ioctl_fiemap(filp, arg);
>  
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 63d069b..7008268 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -32,6 +32,12 @@
>  #define SEEK_END	2	/* seek relative to end of file */
>  #define SEEK_MAX	SEEK_END
>  
> +struct fstrim_range {
> +	uint64_t start;
> +	uint64_t len;
> +	uint64_t minlen;
> +};
> +
>  /* And dynamically-tunable limits and defaults: */
>  struct files_stat_struct {
>  	int nr_files;		/* read only */
> @@ -316,6 +322,7 @@ struct inodes_stat_t {
>  #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 */
> +#define FITRIM		_IOWR('X', 121, struct fstrim_range)	/* Trim */
>  
>  #define	FS_IOC_GETFLAGS			_IOR('f', 1, long)
>  #define	FS_IOC_SETFLAGS			_IOW('f', 2, long)
> @@ -1581,6 +1588,7 @@ struct super_operations {
>  	ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
>  #endif
>  	int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);
> +	int (*trim_fs) (struct super_block *, struct fstrim_range *);
>  };
>  
>  /*
> --
> To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

             reply	other threads:[~2010-10-28 10:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-28 10:30 Boaz Harrosh [this message]
2010-10-28 11:25 ` fs: Add FITRIM ioctl Christoph Hellwig
2010-10-29  9:50   ` Lukas Czerner
2010-10-29  8:58 ` Lukas Czerner

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=4CC950D5.8000603@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=lczerner@redhat.com \
    --cc=linux-fsdevel@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;
as well as URLs for NNTP newsgroup(s).