public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v5 06/10] xfs: add XFS_IOC_FREE_EOFBLOCKS ioctl
Date: Tue, 23 Oct 2012 12:31:04 +1100	[thread overview]
Message-ID: <20121023013104.GJ4291@dastard> (raw)
In-Reply-To: <1349446636-8611-7-git-send-email-bfoster@redhat.com>

On Fri, Oct 05, 2012 at 10:17:12AM -0400, Brian Foster wrote:
> The XFS_IOC_FREE_EOFBLOCKS ioctl allows users to invoke an EOFBLOCKS
> scan. The xfs_eofblocks structure is defined to support the command
> parameters (scan mode).
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>  fs/xfs/xfs_fs.h     |   15 +++++++++++++++
>  fs/xfs/xfs_icache.c |    5 +++--
>  fs/xfs/xfs_icache.h |    2 +-
>  fs/xfs/xfs_ioctl.c  |   16 ++++++++++++++++
>  4 files changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_fs.h b/fs/xfs/xfs_fs.h
> index c13fed8..5f48b3e 100644
> --- a/fs/xfs/xfs_fs.h
> +++ b/fs/xfs/xfs_fs.h
> @@ -339,6 +339,20 @@ typedef struct xfs_error_injection {
>  
>  
>  /*
> + * Speculative preallocation trimming.
> + */
> +#define XFS_EOFBLOCKS_VERSION		1
> +struct xfs_eofblocks {
> +	__u32		eof_version;
> +	__u32		eof_flags;
> +	unsigned char	pad[12];
> +};

12 bytes of padding is a bit wierd at this point. It's 
problematic for 32bit userspace on 64 bit kernels, in that the size
of the structure can end up different (i.e. 20 bytes on 32b, 24 bytes
on 64b) depending on the architectures natural alignment.

I can also see that adding multiple extra variables to the structure
are quite likely (e.g. per-ag control, start/end inode numbers,
etc), so 12 bytes of padding really isn't sufficient, IMO. I'd tend
to pad out to, say, 128 bytes rather than 32, just in case. i.e:

	__u64		pad[15];

And then take away from this padding space as you add functioanlity
in fucture patches.

This extra padding means the version number won't need to increase
any time soon, as it will be a while before we run out of either
padding or flag space, instead of as soon as we add a new function
to the ioctl....

> +
> +/* eof_flags values */
> +#define XFS_EOF_FLAGS_SYNC		0x01	/* sync/wait mode scan */

I kind of prefer flags being defined by (1 << 0) style to keep
larger flag numbers concise, but that's not a big deal.

> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 0e0232c..ad4352f 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -42,6 +42,7 @@
>  #include "xfs_inode_item.h"
>  #include "xfs_export.h"
>  #include "xfs_trace.h"
> +#include "xfs_icache.h"
>  
>  #include <linux/capability.h>
>  #include <linux/dcache.h>
> @@ -1602,6 +1603,21 @@ xfs_file_ioctl(
>  		error = xfs_errortag_clearall(mp, 1);
>  		return -error;
>  
> +	case XFS_IOC_FREE_EOFBLOCKS: {
> +		struct xfs_eofblocks eofb;
> +		int flags;
> +
> +		if (copy_from_user(&eofb, arg, sizeof(eofb)))
> +			return -XFS_ERROR(EFAULT);
> +
> +		if (eofb.eof_version != XFS_EOFBLOCKS_VERSION)
> +			return -XFS_ERROR(EINVAL);

Checking that no unsupported flags are set here is necessary. Also,
checking the padding is zero is probably a good idea, as it will
force applications to zero the structure properly before being able
to use this interface properly....

> +		flags = (eofb.eof_flags & XFS_EOF_FLAGS_SYNC) ? SYNC_WAIT : SYNC_TRYLOCK;

Line if a bit too long. However, would it be better to place this
inside xfs_icache_free_eofblocks()?

> +		error = xfs_icache_free_eofblocks(mp, flags, &eofb);

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2012-10-23  1:29 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 14:17 [PATCH v5 00/10] speculative preallocation inode tracking Brian Foster
2012-10-05 14:17 ` [PATCH v5 01/10] xfs: add EOFBLOCKS inode tagging/untagging Brian Foster
2012-10-05 14:17 ` [PATCH v5 02/10] xfs: support a tag-based inode_ag_iterator Brian Foster
2012-10-05 14:17 ` [PATCH v5 03/10] xfs: create helper to check whether to free eofblocks on inode Brian Foster
2012-10-23  0:58   ` Dave Chinner
2012-10-05 14:17 ` [PATCH v5 04/10] xfs: make xfs_free_eofblocks() non-static, return EAGAIN on trylock failure Brian Foster
2012-10-05 14:17 ` [PATCH v5 05/10] xfs: create function to scan and clear EOFBLOCKS inodes Brian Foster
2012-10-23  1:01   ` Dave Chinner
2012-10-05 14:17 ` [PATCH v5 06/10] xfs: add XFS_IOC_FREE_EOFBLOCKS ioctl Brian Foster
2012-10-11 14:13   ` Ben Myers
2012-10-11 22:35     ` Brian Foster
2012-10-15 22:46       ` Ben Myers
2012-10-15 23:49         ` Dave Chinner
2012-10-16  1:39           ` Dave Chinner
2012-10-17 22:40             ` Ben Myers
2012-10-18 12:16               ` Brian Foster
2012-10-18 15:46                 ` Ben Myers
2012-10-18 16:23                   ` Brian Foster
2012-10-22  7:34                 ` Dave Chinner
2012-10-22 13:23                   ` Brian Foster
2012-10-22 22:22                     ` Dave Chinner
2012-10-23  1:31   ` Dave Chinner [this message]
2012-10-24 16:16     ` Brian Foster
2012-10-24 19:27       ` Dave Chinner
2012-10-05 14:17 ` [PATCH v5 07/10] xfs: make xfs_quota_type() non-static Brian Foster
2012-10-23  1:31   ` Dave Chinner
2012-10-05 14:17 ` [PATCH v5 08/10] xfs: add quota id filtering to eofblocks scan Brian Foster
2012-10-23  1:42   ` Dave Chinner
2012-10-24 16:18     ` Brian Foster
2012-10-24 19:41       ` Dave Chinner
2012-10-24 23:02         ` Brian Foster
2012-10-25  0:02           ` Dave Chinner
2012-10-25  0:29             ` Brian Foster
2012-10-05 14:17 ` [PATCH v5 09/10] xfs: add minimum file size " Brian Foster
2012-10-23  1:43   ` Dave Chinner
2012-10-05 14:17 ` [PATCH v5 10/10] xfs: add background scanning to clear eofblocks inodes Brian Foster
2012-10-23  1:55   ` Dave Chinner
2012-10-19 21:02 ` [PATCH v5 00/10] speculative preallocation inode tracking Mark Tinguely
2012-10-21 14:00   ` Brian Foster
2012-10-21 17:53     ` Mark Tinguely
2012-10-21 20:31       ` Mark Tinguely
2012-10-21 22:28       ` Dave Chinner
2012-10-23 19:10 ` Ben Myers

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=20121023013104.GJ4291@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox