From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: ***** SUSPECTED SPAM ***** [RFD 11/17] xfs: factor xfs_create to prepare for O_TMPFILE
Date: Mon, 12 Aug 2013 23:20:01 +1000 [thread overview]
Message-ID: <1376313607-28133-12-git-send-email-david@fromorbit.com> (raw)
In-Reply-To: <1376313607-28133-1-git-send-email-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
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@redhat.com>
---
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,
--
1.8.3.2
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-08-12 13:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 13:19 ***** SUSPECTED SPAM ***** [RFD 00/17] xfs: inode management development direction Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 01/17] xfs: inode allocation tickets Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 02/17] xfs: separate inode chunk allocation from free inode allocation Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 03/17] xfs: move inode chunk allocation into a workqueue Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 04/17] xfs: optimise background inode chunk allocation Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 05/17] xfs: introduce a free inode allocation btree Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 06/17] xfs: partial inode chunk allocation Dave Chinner
2013-08-13 22:07 ` Brian Foster
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 07/17] xfs: separate inode chunk freeing from inode freeing Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 08/17] xfs: inode chunk freeing in the background Dave Chinner
2013-08-12 13:19 ` ***** SUSPECTED SPAM ***** [RFD 09/17] xfs: optimise inode chunk freeing Dave Chinner
2013-08-12 13:20 ` ***** SUSPECTED SPAM ***** [RFD 10/17] xfs: swap extents operations for CRC filesystems Dave Chinner
2013-08-12 13:20 ` Dave Chinner [this message]
2013-08-20 8:16 ` ***** SUSPECTED SPAM ***** [RFD 11/17] xfs: factor xfs_create to prepare for O_TMPFILE Zhi Yong Wu
2013-11-06 11:20 ` Christoph Hellwig
2013-11-06 11:21 ` Christoph Hellwig
2013-08-12 13:20 ` ***** SUSPECTED SPAM ***** [RFD 12/17] xfs: add tmpfile methods Dave Chinner
2013-08-12 13:20 ` ***** SUSPECTED SPAM ***** [RFD 13/17] xfs: allow linkat() on O_TMPFILE files Dave Chinner
2013-08-12 13:20 ` ***** SUSPECTED SPAM ***** [RFD 14/17] xfs: separate inode freeing from inactivation Dave Chinner
2013-08-12 13:20 ` ***** SUSPECTED SPAM ***** [RFD 15/17] xfs: introduce a method vector for unlinked list operations Dave Chinner
2013-08-12 13:20 ` ***** SUSPECTED SPAM ***** [RFD 16/17] xfs: add in-core unlinked list for v3 inodes Dave Chinner
2013-08-12 13:20 ` ***** SUSPECTED SPAM ***** [RFD 17/17] xfs: log unlinked list modifications in the incore v3 inode Dave Chinner
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=1376313607-28133-12-git-send-email-david@fromorbit.com \
--to=david@fromorbit.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