From: Chandan Rajendra <chandanrlinux@gmail.com>
To: linux-xfs@vger.kernel.org
Cc: Chandan Rajendra <chandanrlinux@gmail.com>,
david@fromorbit.com, chandan@linux.ibm.com,
darrick.wong@oracle.com, bfoster@redhat.com
Subject: [PATCH 0/2] Extend xattr extent counter to 32-bits
Date: Sat, 4 Apr 2020 14:22:27 +0530 [thread overview]
Message-ID: <20200404085229.2034-1-chandanrlinux@gmail.com> (raw)
XFS has a per-inode xattr extent counter which is 16 bits wide. A workload
which
1. Creates 1,000,000 255-byte sized xattrs,
2. Deletes 50% of these xattrs in an alternating manner,
3. Tries to create 400,000 new 255-byte sized xattrs
causes the following message to be printed on the console,
XFS (loop0): xfs_iflush_int: detected corrupt incore inode 131, total extents = -19916, nblocks = 102937, ptr ffff9ce33b098c00
XFS (loop0): xfs_do_force_shutdown(0x8) called from line 3739 of file fs/xfs/xfs_inode.c. Return address = ffffffffa4a94173
This indicates that we overflowed the 16-bits wide xattr extent counter.
I have been informed that there are instances where a single file has > 100
million hardlinks. With parent pointers being stored in xattr, we will
overflow the 16-bits wide xattr extent counter when large number of
hardlinks are created.
This patchset also includes the previously posted "Fix log reservation
calculation for xattr insert operation" patch as a bug fix. It now
replaces the xattr set "mount" and "runtime" reservations with just
one static reservation. Hence we don't need the funcationality to
calculate maximum sized 'xattr set' reservation separately anymore.
The patches can also be obtained from
https://github.com/chandanr/xfsprogs-dev.git at branch
32bit-anextents-v0.
Chandan Rajendra (2):
xfsprogs: Fix log reservation calculation for xattr insert operation
xfsprogs: Extend attr extent counter to 32-bits
db/bmap.c | 4 +--
db/btdump.c | 2 +-
db/check.c | 3 +-
db/field.c | 2 --
db/field.h | 1 -
db/frag.c | 6 ++--
db/inode.c | 10 ++++---
db/metadump.c | 4 +--
libxfs/xfs_attr.c | 6 +---
libxfs/xfs_format.h | 32 +++++++++++++++------
libxfs/xfs_inode_buf.c | 28 +++++++++++++------
libxfs/xfs_inode_fork.c | 3 +-
libxfs/xfs_log_format.h | 5 ++--
libxfs/xfs_log_rlimit.c | 29 -------------------
libxfs/xfs_trans_resv.c | 60 ++++++++++++++++++----------------------
libxfs/xfs_trans_resv.h | 5 +---
libxfs/xfs_trans_space.h | 8 +++++-
libxfs/xfs_types.h | 4 +--
logprint/log_misc.c | 9 +++++-
logprint/log_print_all.c | 9 +++++-
mkfs/xfs_mkfs.c | 1 +
repair/attr_repair.c | 2 +-
repair/dinode.c | 29 +++++++++++--------
23 files changed, 140 insertions(+), 122 deletions(-)
--
2.19.1
next reply other threads:[~2020-04-04 8:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-04 8:52 Chandan Rajendra [this message]
2020-04-04 8:52 ` [PATCH 1/2] xfsprogs: Fix log reservation calculation for xattr insert operation Chandan Rajendra
2020-04-04 8:52 ` [PATCH 2/2] xfsprogs: Extend attr extent counter to 32-bits Chandan Rajendra
2020-04-06 17:07 ` Darrick J. Wong
2020-04-08 12:46 ` Chandan Rajendra
-- strict thread matches above, loose matches on Subject: below --
2020-04-04 8:52 [PATCH 0/2] Extend xattr " Chandan Rajendra
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=20200404085229.2034-1-chandanrlinux@gmail.com \
--to=chandanrlinux@gmail.com \
--cc=bfoster@redhat.com \
--cc=chandan@linux.ibm.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
/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).