[Top] [All Lists]

Re: ***** SUSPECTED SPAM ***** [RFD 11/17] xfs: factor xfs_create to pre

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: ***** SUSPECTED SPAM ***** [RFD 11/17] xfs: factor xfs_create to prepare for O_TMPFILE
From: Zhi Yong Wu <zwu.kernel@xxxxxxxxx>
Date: Tue, 20 Aug 2013 16:16:59 +0800
Cc: xfstests <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oHslXTjRTQeYcIOLVsdS12cJyPkUCyeOQ6FTmazIIbo=; b=pzZZ4m5WnRqAfr6HsHCngLTyZcSiipz3U4rvI4M4iutoRM/wYVOWVaP336OO1r74PD D47NZgkdI++KWdQWmGntHxpeHE9YZcQMUJmSsjsxylk9ugwcyT1YHg00tg8qJqFmfNcl SBuaVoAsMNfZ9fUHkK/Ud4f5Lwf8kbJJqjBqDZklK7WanPWQvKqAxuK1yHiA6JVBGfGu HCHsS0GkIrL2Q34XKZFAIcHAHzG77l6CREVRfrCVUjiR2vitqp2FVkDAPNYDLvxi9d9j 3hoymHLz34TGUv6SrXb1Gl1u7PO8z/fY+EuaJd4mnVzCZqRxttb5VppjpKojtFumfszZ icGA==
In-reply-to: <1376313607-28133-12-git-send-email-david@xxxxxxxxxxxxx>
References: <1376313607-28133-1-git-send-email-david@xxxxxxxxxxxxx> <1376313607-28133-12-git-send-email-david@xxxxxxxxxxxxx>

I'd like to pick off this item and its following 2 items, please avoid
the duplicated work, thanks.

[RFD 11/17] xfs: factor xfs_create to prepare for O_TMPFILE,
[RFD 12/17] xfs: add tmpfile methods
[RFD 13/17] xfs: allow linkat() on O_TMPFILE files

On Mon, Aug 12, 2013 at 9:20 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> O_TMPFILE support requires allocating an inode that is not attached to the
> a current namespace - it's anonymous. The current inode allocation code runs
> through xfs_create() which requires a parent inode and a name to be passed to
> it. for O_TMPFILE, we do not have a parent inode or a name so we cannot use
> the same calling conventions as xfs_create() to allocate a inode.
> In this case, the inode is anonymous, so it is a property of the allocation
> group it is allocated to, not the namespace. Hence all we really need to pass
> from the VFS is a struct xfs_mount and the struct xfs_inode pointer that we
> return the allocated inode in.
> The allocation of the inode requires a different log reservation to 
> mkdir/create
> as there is no directory modification taking place, though we still need to
> reserve/account quotas appropriately. We do not need to check if we can add 
> the
> entry to the directory, either.
> Hence the majority of the inode allocation code is similar to that in
> xfs_create, and so can be factored out of xfs_create() and reused.
> The fact that a parent inode does not exist follows into xfs_dir_ialloc() and
> xfs_ialloc(), too. xfs_dir_ialloc() does not actually use the parent inode, 
> just
> passes it through to xfs_ialloc(). xfs_ialloc() can handle a null parent 
> inode,
> but it results in a target inode number of 0 and so allocation will always
> target AG 0, This will effectively serialise O_TMPFILE allocation and removal.
> Hence we should separate the parent inode from the allocation target inode all
> the way down to xfs_dialloc() while factoring this code. This will allow us to
> use a separate AG rotor to direct allocation of temporary files around 
> different
> AGs, allowing them to the allocated and removed concurrently.
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> ---
>  fs/xfs/xfs_iops.c | 1 +
>  1 file changed, 1 insertion(+)
> diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> index 96dda62..9c20a2c 100644
> --- a/fs/xfs/xfs_iops.c
> +++ b/fs/xfs/xfs_iops.c
> @@ -112,6 +112,7 @@ xfs_cleanup_inode(
>         iput(inode);
>  }
> +/* how much of this does tmpfile need? */
>  STATIC int
>  xfs_vn_mknod(
>         struct inode    *dir,
> --
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs


Zhi Yong Wu

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