From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: ***** SUSPECTED SPAM ***** [RFD 13/17] xfs: allow linkat() on O_TMPFILE files
Date: Mon, 12 Aug 2013 23:20:03 +1000 [thread overview]
Message-ID: <1376313607-28133-14-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>
The VFS allows an anonymous temporary file to be named at a later
time via a linkat() syscall. Inodes that are created as O_TMPFILE
are marked with a special flag I_LINKABLE that tells the VFS that it
is OK to add a link to the inode even though it currently has a zero
link count.
To support this in XFS, we need to have xfs_link() detect this flag
is set and behave appropriately when detected. When this situation
is detected, we have ot ensure that the transaciton reservation
takes into account the additional overhead of removing the inode
from the unlinked list.
Once we have determined that we can add the directory entry for the
new link, we can remove the inode from the unlinked list and then
add the directory entry. We do the operation in this order so that
the AGI locking versus directory block allocation (and hence AGF
locking) is the same as xfs_create() does.
Finally, when we bump the link count, we need to ensure we don't
assert fail on the zero link count that the O_TMPFILE inode has.
This is the only case where incremeting the link count when it is
zero is now valid, so we need to make sure that xfs_bumplink()
checks this precisely. The VFS should ensure that I_LINKABLE is
removed on the first link of an anonymous file so care is needed to
ensure that the checks capture this behaviour, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
fs/xfs/xfs_utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/xfs/xfs_utils.c b/fs/xfs/xfs_utils.c
index 0025c78..fb2fa6c 100644
--- a/fs/xfs/xfs_utils.c
+++ b/fs/xfs/xfs_utils.c
@@ -293,6 +293,7 @@ xfs_bumplink(
{
xfs_trans_ichgtime(tp, ip, XFS_ICHGTIME_CHG);
+ /* tmpfiles won't like this */
ASSERT(ip->i_d.di_nlink > 0);
ip->i_d.di_nlink++;
inc_nlink(VFS_I(ip));
--
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 ` ***** SUSPECTED SPAM ***** [RFD 11/17] xfs: factor xfs_create to prepare for O_TMPFILE Dave Chinner
2013-08-20 8:16 ` 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 ` Dave Chinner [this message]
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-14-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