2018-06-06 10:42:14 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2013-08-12 18:49:33 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2000-2003,2005 Silicon Graphics, Inc.
|
|
|
|
* All Rights Reserved.
|
|
|
|
*/
|
|
|
|
#ifndef __XFS_INODE_FORK_H__
|
|
|
|
#define __XFS_INODE_FORK_H__
|
|
|
|
|
|
|
|
struct xfs_inode_log_item;
|
2013-10-23 07:51:50 +08:00
|
|
|
struct xfs_dinode;
|
2013-08-12 18:49:33 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* File incore extent information, present for each of data & attr forks.
|
|
|
|
*/
|
2018-07-18 07:51:50 +08:00
|
|
|
struct xfs_ifork {
|
xfs: fix inode fork extent count overflow
[commit message is verbose for discussion purposes - will trim it
down later. Some questions about implementation details at the end.]
Zorro Lang recently ran a new test to stress single inode extent
counts now that they are no longer limited by memory allocation.
The test was simply:
# xfs_io -f -c "falloc 0 40t" /mnt/scratch/big-file
# ~/src/xfstests-dev/punch-alternating /mnt/scratch/big-file
This test uncovered a problem where the hole punching operation
appeared to finish with no error, but apparently only created 268M
extents instead of the 10 billion it was supposed to.
Further, trying to punch out extents that should have been present
resulted in success, but no change in the extent count. It looked
like a silent failure.
While running the test and observing the behaviour in real time,
I observed the extent coutn growing at ~2M extents/minute, and saw
this after about an hour:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next ; \
> sleep 60 ; \
> xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 127657993
fsxattr.nextents = 129683339
#
And a few minutes later this:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4177861124
#
Ah, what? Where did that 4 billion extra extents suddenly come from?
Stop the workload, unmount, mount:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 166044375
#
And it's back at the expected number. i.e. the extent count is
correct on disk, but it's screwed up in memory. I loaded up the
extent list, and immediately:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4192576215
#
It's bad again. So, where does that number come from?
xfs_fill_fsxattr():
if (ip->i_df.if_flags & XFS_IFEXTENTS)
fa->fsx_nextents = xfs_iext_count(&ip->i_df);
else
fa->fsx_nextents = ip->i_d.di_nextents;
And that's the behaviour I just saw in a nutshell. The on disk count
is correct, but once the tree is loaded into memory, it goes whacky.
Clearly there's something wrong with xfs_iext_count():
inline xfs_extnum_t xfs_iext_count(struct xfs_ifork *ifp)
{
return ifp->if_bytes / sizeof(struct xfs_iext_rec);
}
Simple enough, but 134M extents is 2**27, and that's right about
where things went wrong. A struct xfs_iext_rec is 16 bytes in size,
which means 2**27 * 2**4 = 2**31 and we're right on target for an
integer overflow. And, sure enough:
struct xfs_ifork {
int if_bytes; /* bytes in if_u1 */
....
Once we get 2**27 extents in a file, we overflow if_bytes and the
in-core extent count goes wrong. And when we reach 2**28 extents,
if_bytes wraps back to zero and things really start to go wrong
there. This is where the silent failure comes from - only the first
2**28 extents can be looked up directly due to the overflow, all the
extents above this index wrap back to somewhere in the first 2**28
extents. Hence with a regular pattern, trying to punch a hole in the
range that didn't have holes mapped to a hole in the first 2**28
extents and so "succeeded" without changing anything. Hence "silent
failure"...
Fix this by converting if_bytes to a int64_t and converting all the
index variables and size calculations to use int64_t types to avoid
overflows in future. Signed integers are still used to enable easy
detection of extent count underflows. This enables scalability of
extent counts to the limits of the on-disk format - MAXEXTNUM
(2**31) extents.
Current testing is at over 500M extents and still going:
fsxattr.nextents = 517310478
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2019-10-18 04:40:33 +08:00
|
|
|
int64_t if_bytes; /* bytes in if_u1 */
|
2013-08-12 18:49:33 +08:00
|
|
|
struct xfs_btree_block *if_broot; /* file's incore btree root */
|
xfs: fix inode fork extent count overflow
[commit message is verbose for discussion purposes - will trim it
down later. Some questions about implementation details at the end.]
Zorro Lang recently ran a new test to stress single inode extent
counts now that they are no longer limited by memory allocation.
The test was simply:
# xfs_io -f -c "falloc 0 40t" /mnt/scratch/big-file
# ~/src/xfstests-dev/punch-alternating /mnt/scratch/big-file
This test uncovered a problem where the hole punching operation
appeared to finish with no error, but apparently only created 268M
extents instead of the 10 billion it was supposed to.
Further, trying to punch out extents that should have been present
resulted in success, but no change in the extent count. It looked
like a silent failure.
While running the test and observing the behaviour in real time,
I observed the extent coutn growing at ~2M extents/minute, and saw
this after about an hour:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next ; \
> sleep 60 ; \
> xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 127657993
fsxattr.nextents = 129683339
#
And a few minutes later this:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4177861124
#
Ah, what? Where did that 4 billion extra extents suddenly come from?
Stop the workload, unmount, mount:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 166044375
#
And it's back at the expected number. i.e. the extent count is
correct on disk, but it's screwed up in memory. I loaded up the
extent list, and immediately:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4192576215
#
It's bad again. So, where does that number come from?
xfs_fill_fsxattr():
if (ip->i_df.if_flags & XFS_IFEXTENTS)
fa->fsx_nextents = xfs_iext_count(&ip->i_df);
else
fa->fsx_nextents = ip->i_d.di_nextents;
And that's the behaviour I just saw in a nutshell. The on disk count
is correct, but once the tree is loaded into memory, it goes whacky.
Clearly there's something wrong with xfs_iext_count():
inline xfs_extnum_t xfs_iext_count(struct xfs_ifork *ifp)
{
return ifp->if_bytes / sizeof(struct xfs_iext_rec);
}
Simple enough, but 134M extents is 2**27, and that's right about
where things went wrong. A struct xfs_iext_rec is 16 bytes in size,
which means 2**27 * 2**4 = 2**31 and we're right on target for an
integer overflow. And, sure enough:
struct xfs_ifork {
int if_bytes; /* bytes in if_u1 */
....
Once we get 2**27 extents in a file, we overflow if_bytes and the
in-core extent count goes wrong. And when we reach 2**28 extents,
if_bytes wraps back to zero and things really start to go wrong
there. This is where the silent failure comes from - only the first
2**28 extents can be looked up directly due to the overflow, all the
extents above this index wrap back to somewhere in the first 2**28
extents. Hence with a regular pattern, trying to punch a hole in the
range that didn't have holes mapped to a hole in the first 2**28
extents and so "succeeded" without changing anything. Hence "silent
failure"...
Fix this by converting if_bytes to a int64_t and converting all the
index variables and size calculations to use int64_t types to avoid
overflows in future. Signed integers are still used to enable easy
detection of extent count underflows. This enables scalability of
extent counts to the limits of the on-disk format - MAXEXTNUM
(2**31) extents.
Current testing is at over 500M extents and still going:
fsxattr.nextents = 517310478
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2019-10-18 04:40:33 +08:00
|
|
|
unsigned int if_seq; /* fork mod counter */
|
2017-11-04 01:34:46 +08:00
|
|
|
int if_height; /* height of the extent tree */
|
2013-08-12 18:49:33 +08:00
|
|
|
union {
|
2017-11-04 01:34:46 +08:00
|
|
|
void *if_root; /* extent tree root */
|
2013-08-12 18:49:33 +08:00
|
|
|
char *if_data; /* inline file data */
|
|
|
|
} if_u1;
|
xfs: fix inode fork extent count overflow
[commit message is verbose for discussion purposes - will trim it
down later. Some questions about implementation details at the end.]
Zorro Lang recently ran a new test to stress single inode extent
counts now that they are no longer limited by memory allocation.
The test was simply:
# xfs_io -f -c "falloc 0 40t" /mnt/scratch/big-file
# ~/src/xfstests-dev/punch-alternating /mnt/scratch/big-file
This test uncovered a problem where the hole punching operation
appeared to finish with no error, but apparently only created 268M
extents instead of the 10 billion it was supposed to.
Further, trying to punch out extents that should have been present
resulted in success, but no change in the extent count. It looked
like a silent failure.
While running the test and observing the behaviour in real time,
I observed the extent coutn growing at ~2M extents/minute, and saw
this after about an hour:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next ; \
> sleep 60 ; \
> xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 127657993
fsxattr.nextents = 129683339
#
And a few minutes later this:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4177861124
#
Ah, what? Where did that 4 billion extra extents suddenly come from?
Stop the workload, unmount, mount:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 166044375
#
And it's back at the expected number. i.e. the extent count is
correct on disk, but it's screwed up in memory. I loaded up the
extent list, and immediately:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4192576215
#
It's bad again. So, where does that number come from?
xfs_fill_fsxattr():
if (ip->i_df.if_flags & XFS_IFEXTENTS)
fa->fsx_nextents = xfs_iext_count(&ip->i_df);
else
fa->fsx_nextents = ip->i_d.di_nextents;
And that's the behaviour I just saw in a nutshell. The on disk count
is correct, but once the tree is loaded into memory, it goes whacky.
Clearly there's something wrong with xfs_iext_count():
inline xfs_extnum_t xfs_iext_count(struct xfs_ifork *ifp)
{
return ifp->if_bytes / sizeof(struct xfs_iext_rec);
}
Simple enough, but 134M extents is 2**27, and that's right about
where things went wrong. A struct xfs_iext_rec is 16 bytes in size,
which means 2**27 * 2**4 = 2**31 and we're right on target for an
integer overflow. And, sure enough:
struct xfs_ifork {
int if_bytes; /* bytes in if_u1 */
....
Once we get 2**27 extents in a file, we overflow if_bytes and the
in-core extent count goes wrong. And when we reach 2**28 extents,
if_bytes wraps back to zero and things really start to go wrong
there. This is where the silent failure comes from - only the first
2**28 extents can be looked up directly due to the overflow, all the
extents above this index wrap back to somewhere in the first 2**28
extents. Hence with a regular pattern, trying to punch a hole in the
range that didn't have holes mapped to a hole in the first 2**28
extents and so "succeeded" without changing anything. Hence "silent
failure"...
Fix this by converting if_bytes to a int64_t and converting all the
index variables and size calculations to use int64_t types to avoid
overflows in future. Signed integers are still used to enable easy
detection of extent count underflows. This enables scalability of
extent counts to the limits of the on-disk format - MAXEXTNUM
(2**31) extents.
Current testing is at over 500M extents and still going:
fsxattr.nextents = 517310478
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2019-10-18 04:40:33 +08:00
|
|
|
short if_broot_bytes; /* bytes allocated for root */
|
|
|
|
unsigned char if_flags; /* per-fork flags */
|
2018-07-18 07:51:50 +08:00
|
|
|
};
|
2013-08-12 18:49:33 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Per-fork incore inode flags.
|
|
|
|
*/
|
|
|
|
#define XFS_IFINLINE 0x01 /* Inline data is read in */
|
|
|
|
#define XFS_IFEXTENTS 0x02 /* All extent pointers are read in */
|
|
|
|
#define XFS_IFBROOT 0x04 /* i_broot points to the bmap b-tree root */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fork handling.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define XFS_IFORK_Q(ip) ((ip)->i_d.di_forkoff != 0)
|
|
|
|
#define XFS_IFORK_BOFF(ip) ((int)((ip)->i_d.di_forkoff << 3))
|
|
|
|
|
|
|
|
#define XFS_IFORK_PTR(ip,w) \
|
|
|
|
((w) == XFS_DATA_FORK ? \
|
|
|
|
&(ip)->i_df : \
|
2016-10-04 00:11:32 +08:00
|
|
|
((w) == XFS_ATTR_FORK ? \
|
|
|
|
(ip)->i_afp : \
|
|
|
|
(ip)->i_cowfp))
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_DSIZE(ip) \
|
2020-03-18 23:15:10 +08:00
|
|
|
(XFS_IFORK_Q(ip) ? XFS_IFORK_BOFF(ip) : XFS_LITINO((ip)->i_mount))
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_ASIZE(ip) \
|
2020-03-18 23:15:10 +08:00
|
|
|
(XFS_IFORK_Q(ip) ? XFS_LITINO((ip)->i_mount) - XFS_IFORK_BOFF(ip) : 0)
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_SIZE(ip,w) \
|
|
|
|
((w) == XFS_DATA_FORK ? \
|
|
|
|
XFS_IFORK_DSIZE(ip) : \
|
2016-10-04 00:11:32 +08:00
|
|
|
((w) == XFS_ATTR_FORK ? \
|
|
|
|
XFS_IFORK_ASIZE(ip) : \
|
|
|
|
0))
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_FORMAT(ip,w) \
|
|
|
|
((w) == XFS_DATA_FORK ? \
|
|
|
|
(ip)->i_d.di_format : \
|
2016-10-04 00:11:32 +08:00
|
|
|
((w) == XFS_ATTR_FORK ? \
|
|
|
|
(ip)->i_d.di_aformat : \
|
|
|
|
(ip)->i_cformat))
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_FMT_SET(ip,w,n) \
|
|
|
|
((w) == XFS_DATA_FORK ? \
|
|
|
|
((ip)->i_d.di_format = (n)) : \
|
2016-10-04 00:11:32 +08:00
|
|
|
((w) == XFS_ATTR_FORK ? \
|
|
|
|
((ip)->i_d.di_aformat = (n)) : \
|
|
|
|
((ip)->i_cformat = (n))))
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_NEXTENTS(ip,w) \
|
|
|
|
((w) == XFS_DATA_FORK ? \
|
|
|
|
(ip)->i_d.di_nextents : \
|
2016-10-04 00:11:32 +08:00
|
|
|
((w) == XFS_ATTR_FORK ? \
|
|
|
|
(ip)->i_d.di_anextents : \
|
|
|
|
(ip)->i_cnextents))
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_NEXT_SET(ip,w,n) \
|
|
|
|
((w) == XFS_DATA_FORK ? \
|
|
|
|
((ip)->i_d.di_nextents = (n)) : \
|
2016-10-04 00:11:32 +08:00
|
|
|
((w) == XFS_ATTR_FORK ? \
|
|
|
|
((ip)->i_d.di_anextents = (n)) : \
|
|
|
|
((ip)->i_cnextents = (n))))
|
2013-08-12 18:49:33 +08:00
|
|
|
#define XFS_IFORK_MAXEXT(ip, w) \
|
|
|
|
(XFS_IFORK_SIZE(ip, w) / sizeof(xfs_bmbt_rec_t))
|
|
|
|
|
xfs: refactor "does this fork map blocks" predicate
Replace the open-coded checks for whether or not an inode fork maps
blocks with a macro that will implant the code for us. This helps us
declutter the bmap code a bit.
Note that I had to use a macro instead of a static inline function
because of C header dependency problems between xfs_inode.h and
xfs_inode_fork.h.
Conversion was performed with the following Coccinelle script:
@@
expression ip, w;
@@
- XFS_IFORK_FORMAT(ip, w) == XFS_DINODE_FMT_EXTENTS || XFS_IFORK_FORMAT(ip, w) == XFS_DINODE_FMT_BTREE
+ xfs_ifork_has_extents(ip, w)
@@
expression ip, w;
@@
- XFS_IFORK_FORMAT(ip, w) != XFS_DINODE_FMT_EXTENTS && XFS_IFORK_FORMAT(ip, w) != XFS_DINODE_FMT_BTREE
+ !xfs_ifork_has_extents(ip, w)
@@
expression ip, w;
@@
- XFS_IFORK_FORMAT(ip, w) == XFS_DINODE_FMT_BTREE || XFS_IFORK_FORMAT(ip, w) == XFS_DINODE_FMT_EXTENTS
+ xfs_ifork_has_extents(ip, w)
@@
expression ip, w;
@@
- XFS_IFORK_FORMAT(ip, w) != XFS_DINODE_FMT_BTREE && XFS_IFORK_FORMAT(ip, w) != XFS_DINODE_FMT_EXTENTS
+ !xfs_ifork_has_extents(ip, w)
@@
expression ip, w;
@@
- (xfs_ifork_has_extents(ip, w))
+ xfs_ifork_has_extents(ip, w)
@@
expression ip, w;
@@
- (!xfs_ifork_has_extents(ip, w))
+ !xfs_ifork_has_extents(ip, w)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-11-08 07:05:21 +08:00
|
|
|
#define xfs_ifork_has_extents(ip, w) \
|
|
|
|
(XFS_IFORK_FORMAT((ip), (w)) == XFS_DINODE_FMT_EXTENTS || \
|
|
|
|
XFS_IFORK_FORMAT((ip), (w)) == XFS_DINODE_FMT_BTREE)
|
|
|
|
|
2016-10-04 00:11:32 +08:00
|
|
|
struct xfs_ifork *xfs_iext_state_to_fork(struct xfs_inode *ip, int state);
|
|
|
|
|
2013-08-12 18:49:33 +08:00
|
|
|
int xfs_iformat_fork(struct xfs_inode *, struct xfs_dinode *);
|
2017-04-04 03:22:20 +08:00
|
|
|
void xfs_iflush_fork(struct xfs_inode *, struct xfs_dinode *,
|
2014-04-14 17:04:46 +08:00
|
|
|
struct xfs_inode_log_item *, int);
|
2013-08-12 18:49:33 +08:00
|
|
|
void xfs_idestroy_fork(struct xfs_inode *, int);
|
xfs: fix inode fork extent count overflow
[commit message is verbose for discussion purposes - will trim it
down later. Some questions about implementation details at the end.]
Zorro Lang recently ran a new test to stress single inode extent
counts now that they are no longer limited by memory allocation.
The test was simply:
# xfs_io -f -c "falloc 0 40t" /mnt/scratch/big-file
# ~/src/xfstests-dev/punch-alternating /mnt/scratch/big-file
This test uncovered a problem where the hole punching operation
appeared to finish with no error, but apparently only created 268M
extents instead of the 10 billion it was supposed to.
Further, trying to punch out extents that should have been present
resulted in success, but no change in the extent count. It looked
like a silent failure.
While running the test and observing the behaviour in real time,
I observed the extent coutn growing at ~2M extents/minute, and saw
this after about an hour:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next ; \
> sleep 60 ; \
> xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 127657993
fsxattr.nextents = 129683339
#
And a few minutes later this:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4177861124
#
Ah, what? Where did that 4 billion extra extents suddenly come from?
Stop the workload, unmount, mount:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 166044375
#
And it's back at the expected number. i.e. the extent count is
correct on disk, but it's screwed up in memory. I loaded up the
extent list, and immediately:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4192576215
#
It's bad again. So, where does that number come from?
xfs_fill_fsxattr():
if (ip->i_df.if_flags & XFS_IFEXTENTS)
fa->fsx_nextents = xfs_iext_count(&ip->i_df);
else
fa->fsx_nextents = ip->i_d.di_nextents;
And that's the behaviour I just saw in a nutshell. The on disk count
is correct, but once the tree is loaded into memory, it goes whacky.
Clearly there's something wrong with xfs_iext_count():
inline xfs_extnum_t xfs_iext_count(struct xfs_ifork *ifp)
{
return ifp->if_bytes / sizeof(struct xfs_iext_rec);
}
Simple enough, but 134M extents is 2**27, and that's right about
where things went wrong. A struct xfs_iext_rec is 16 bytes in size,
which means 2**27 * 2**4 = 2**31 and we're right on target for an
integer overflow. And, sure enough:
struct xfs_ifork {
int if_bytes; /* bytes in if_u1 */
....
Once we get 2**27 extents in a file, we overflow if_bytes and the
in-core extent count goes wrong. And when we reach 2**28 extents,
if_bytes wraps back to zero and things really start to go wrong
there. This is where the silent failure comes from - only the first
2**28 extents can be looked up directly due to the overflow, all the
extents above this index wrap back to somewhere in the first 2**28
extents. Hence with a regular pattern, trying to punch a hole in the
range that didn't have holes mapped to a hole in the first 2**28
extents and so "succeeded" without changing anything. Hence "silent
failure"...
Fix this by converting if_bytes to a int64_t and converting all the
index variables and size calculations to use int64_t types to avoid
overflows in future. Signed integers are still used to enable easy
detection of extent count underflows. This enables scalability of
extent counts to the limits of the on-disk format - MAXEXTNUM
(2**31) extents.
Current testing is at over 500M extents and still going:
fsxattr.nextents = 517310478
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2019-10-18 04:40:33 +08:00
|
|
|
void xfs_idata_realloc(struct xfs_inode *ip, int64_t byte_diff,
|
|
|
|
int whichfork);
|
2013-08-12 18:49:33 +08:00
|
|
|
void xfs_iroot_realloc(struct xfs_inode *, int, int);
|
|
|
|
int xfs_iread_extents(struct xfs_trans *, struct xfs_inode *, int);
|
|
|
|
int xfs_iextents_copy(struct xfs_inode *, struct xfs_bmbt_rec *,
|
|
|
|
int);
|
xfs: fix inode fork extent count overflow
[commit message is verbose for discussion purposes - will trim it
down later. Some questions about implementation details at the end.]
Zorro Lang recently ran a new test to stress single inode extent
counts now that they are no longer limited by memory allocation.
The test was simply:
# xfs_io -f -c "falloc 0 40t" /mnt/scratch/big-file
# ~/src/xfstests-dev/punch-alternating /mnt/scratch/big-file
This test uncovered a problem where the hole punching operation
appeared to finish with no error, but apparently only created 268M
extents instead of the 10 billion it was supposed to.
Further, trying to punch out extents that should have been present
resulted in success, but no change in the extent count. It looked
like a silent failure.
While running the test and observing the behaviour in real time,
I observed the extent coutn growing at ~2M extents/minute, and saw
this after about an hour:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next ; \
> sleep 60 ; \
> xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 127657993
fsxattr.nextents = 129683339
#
And a few minutes later this:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4177861124
#
Ah, what? Where did that 4 billion extra extents suddenly come from?
Stop the workload, unmount, mount:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 166044375
#
And it's back at the expected number. i.e. the extent count is
correct on disk, but it's screwed up in memory. I loaded up the
extent list, and immediately:
# xfs_io -f -c "stat" /mnt/scratch/big-file |grep next
fsxattr.nextents = 4192576215
#
It's bad again. So, where does that number come from?
xfs_fill_fsxattr():
if (ip->i_df.if_flags & XFS_IFEXTENTS)
fa->fsx_nextents = xfs_iext_count(&ip->i_df);
else
fa->fsx_nextents = ip->i_d.di_nextents;
And that's the behaviour I just saw in a nutshell. The on disk count
is correct, but once the tree is loaded into memory, it goes whacky.
Clearly there's something wrong with xfs_iext_count():
inline xfs_extnum_t xfs_iext_count(struct xfs_ifork *ifp)
{
return ifp->if_bytes / sizeof(struct xfs_iext_rec);
}
Simple enough, but 134M extents is 2**27, and that's right about
where things went wrong. A struct xfs_iext_rec is 16 bytes in size,
which means 2**27 * 2**4 = 2**31 and we're right on target for an
integer overflow. And, sure enough:
struct xfs_ifork {
int if_bytes; /* bytes in if_u1 */
....
Once we get 2**27 extents in a file, we overflow if_bytes and the
in-core extent count goes wrong. And when we reach 2**28 extents,
if_bytes wraps back to zero and things really start to go wrong
there. This is where the silent failure comes from - only the first
2**28 extents can be looked up directly due to the overflow, all the
extents above this index wrap back to somewhere in the first 2**28
extents. Hence with a regular pattern, trying to punch a hole in the
range that didn't have holes mapped to a hole in the first 2**28
extents and so "succeeded" without changing anything. Hence "silent
failure"...
Fix this by converting if_bytes to a int64_t and converting all the
index variables and size calculations to use int64_t types to avoid
overflows in future. Signed integers are still used to enable easy
detection of extent count underflows. This enables scalability of
extent counts to the limits of the on-disk format - MAXEXTNUM
(2**31) extents.
Current testing is at over 500M extents and still going:
fsxattr.nextents = 517310478
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2019-10-18 04:40:33 +08:00
|
|
|
void xfs_init_local_fork(struct xfs_inode *ip, int whichfork,
|
|
|
|
const void *data, int64_t size);
|
2013-08-12 18:49:33 +08:00
|
|
|
|
2017-11-04 01:34:46 +08:00
|
|
|
xfs_extnum_t xfs_iext_count(struct xfs_ifork *ifp);
|
2017-11-04 01:34:43 +08:00
|
|
|
void xfs_iext_insert(struct xfs_inode *, struct xfs_iext_cursor *cur,
|
2017-11-04 01:34:46 +08:00
|
|
|
struct xfs_bmbt_irec *, int);
|
2017-11-04 01:34:43 +08:00
|
|
|
void xfs_iext_remove(struct xfs_inode *, struct xfs_iext_cursor *,
|
2017-11-04 01:34:47 +08:00
|
|
|
int);
|
2013-08-12 18:49:33 +08:00
|
|
|
void xfs_iext_destroy(struct xfs_ifork *);
|
|
|
|
|
2016-11-24 08:39:32 +08:00
|
|
|
bool xfs_iext_lookup_extent(struct xfs_inode *ip,
|
|
|
|
struct xfs_ifork *ifp, xfs_fileoff_t bno,
|
2017-11-04 01:34:43 +08:00
|
|
|
struct xfs_iext_cursor *cur,
|
|
|
|
struct xfs_bmbt_irec *gotp);
|
2017-10-24 07:32:39 +08:00
|
|
|
bool xfs_iext_lookup_extent_before(struct xfs_inode *ip,
|
|
|
|
struct xfs_ifork *ifp, xfs_fileoff_t *end,
|
2017-11-04 01:34:43 +08:00
|
|
|
struct xfs_iext_cursor *cur,
|
|
|
|
struct xfs_bmbt_irec *gotp);
|
|
|
|
bool xfs_iext_get_extent(struct xfs_ifork *ifp,
|
|
|
|
struct xfs_iext_cursor *cur,
|
2016-11-24 08:39:32 +08:00
|
|
|
struct xfs_bmbt_irec *gotp);
|
2017-10-20 02:04:44 +08:00
|
|
|
void xfs_iext_update_extent(struct xfs_inode *ip, int state,
|
2017-11-04 01:34:43 +08:00
|
|
|
struct xfs_iext_cursor *cur,
|
|
|
|
struct xfs_bmbt_irec *gotp);
|
|
|
|
|
2017-11-04 01:34:46 +08:00
|
|
|
void xfs_iext_first(struct xfs_ifork *, struct xfs_iext_cursor *);
|
|
|
|
void xfs_iext_last(struct xfs_ifork *, struct xfs_iext_cursor *);
|
|
|
|
void xfs_iext_next(struct xfs_ifork *, struct xfs_iext_cursor *);
|
|
|
|
void xfs_iext_prev(struct xfs_ifork *, struct xfs_iext_cursor *);
|
2017-11-04 01:34:43 +08:00
|
|
|
|
|
|
|
static inline bool xfs_iext_next_extent(struct xfs_ifork *ifp,
|
|
|
|
struct xfs_iext_cursor *cur, struct xfs_bmbt_irec *gotp)
|
|
|
|
{
|
|
|
|
xfs_iext_next(ifp, cur);
|
|
|
|
return xfs_iext_get_extent(ifp, cur, gotp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool xfs_iext_prev_extent(struct xfs_ifork *ifp,
|
|
|
|
struct xfs_iext_cursor *cur, struct xfs_bmbt_irec *gotp)
|
|
|
|
{
|
|
|
|
xfs_iext_prev(ifp, cur);
|
|
|
|
return xfs_iext_get_extent(ifp, cur, gotp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the extent after cur in gotp without updating the cursor.
|
|
|
|
*/
|
|
|
|
static inline bool xfs_iext_peek_next_extent(struct xfs_ifork *ifp,
|
|
|
|
struct xfs_iext_cursor *cur, struct xfs_bmbt_irec *gotp)
|
|
|
|
{
|
|
|
|
struct xfs_iext_cursor ncur = *cur;
|
|
|
|
|
|
|
|
xfs_iext_next(ifp, &ncur);
|
|
|
|
return xfs_iext_get_extent(ifp, &ncur, gotp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the extent before cur in gotp without updating the cursor.
|
|
|
|
*/
|
|
|
|
static inline bool xfs_iext_peek_prev_extent(struct xfs_ifork *ifp,
|
|
|
|
struct xfs_iext_cursor *cur, struct xfs_bmbt_irec *gotp)
|
|
|
|
{
|
|
|
|
struct xfs_iext_cursor ncur = *cur;
|
|
|
|
|
|
|
|
xfs_iext_prev(ifp, &ncur);
|
|
|
|
return xfs_iext_get_extent(ifp, &ncur, gotp);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define for_each_xfs_iext(ifp, ext, got) \
|
|
|
|
for (xfs_iext_first((ifp), (ext)); \
|
|
|
|
xfs_iext_get_extent((ifp), (ext), (got)); \
|
|
|
|
xfs_iext_next((ifp), (ext)))
|
2016-11-24 08:39:32 +08:00
|
|
|
|
2013-08-12 18:49:33 +08:00
|
|
|
extern struct kmem_zone *xfs_ifork_zone;
|
|
|
|
|
2016-10-04 00:11:32 +08:00
|
|
|
extern void xfs_ifork_init_cow(struct xfs_inode *ip);
|
|
|
|
|
2018-01-09 02:51:06 +08:00
|
|
|
typedef xfs_failaddr_t (*xfs_ifork_verifier_t)(struct xfs_inode *);
|
|
|
|
|
|
|
|
struct xfs_ifork_ops {
|
|
|
|
xfs_ifork_verifier_t verify_symlink;
|
|
|
|
xfs_ifork_verifier_t verify_dir;
|
|
|
|
xfs_ifork_verifier_t verify_attr;
|
|
|
|
};
|
|
|
|
extern struct xfs_ifork_ops xfs_default_ifork_ops;
|
|
|
|
|
|
|
|
xfs_failaddr_t xfs_ifork_verify_data(struct xfs_inode *ip,
|
|
|
|
struct xfs_ifork_ops *ops);
|
|
|
|
xfs_failaddr_t xfs_ifork_verify_attr(struct xfs_inode *ip,
|
|
|
|
struct xfs_ifork_ops *ops);
|
|
|
|
|
2013-08-12 18:49:33 +08:00
|
|
|
#endif /* __XFS_INODE_FORK_H__ */
|