- 07 Apr, 2021 29 commits
-
-
Dave Chinner authored
Device inodes have a non-default data fork size of 8 bytes as checked/enforced by xfs_repair. xfs_default_attroffset() doesn't handle this, so lets do a minor refactor so it does. Fixes: e6a688c3 ("xfs: initialise attr fork on inode create") Signed-off-by:
Dave Chinner <dchinner@redhat.com> Tested-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Darrick J. Wong <djwong@kernel.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Allison Henderson <allison.henderson@oracle.com>
-
Dave Chinner authored
Due to confusion on when the XFS_IFEXTENT needs to be set, the changes in e6a688c3 ("xfs: initialise attr fork on inode create") failed to set the flag when initialising the empty attribute fork at inode creation. Set this flag the same way xfs_bmap_add_attrfork() does after attry fork allocation. Fixes: e6a688c3 ("xfs: initialise attr fork on inode create") Signed-off-by:
-
Dave Chinner authored
The pitfalls of regression testing on a machine without realising that selinux was disabled. Only set the attr fork during inode allocation if the attr feature bits are already set on the superblock. Fixes: e6a688c3 ("xfs: initialise attr fork on inode create") Signed-off-by:
-
Chandan Babu R authored
xchk_btree_check_minrecs() checks if the contents of the immediate child of a bmbt root block can fit within the root block. This check could fail on inodes with an attr fork since xfs_bmap_add_attrfork_btree() used to demote the current root node of the data fork as the child of a newly allocated root node if it found that the size of "struct xfs_btree_block" along with the space required for records exceeded that of space available in the data fork. xfs_bmap_add_attrfork_btree() should have used "struct xfs_bmdr_block" instead of "struct xfs_btree_block" for the above mentioned space requirement calculation. This commit disables the check for unoptimized (in terms of disk space usage) data fork bmbt trees since there could be filesystems in use that already have such a layout. Suggested-by:
Chandan Babu R <chandanrlinux@gmail.com> Reviewed-by:
-
Chandan Babu R authored
The incore data fork of an inode stores the bmap btree root node as 'struct xfs_btree_block'. However, the ondisk version of the inode stores the bmap btree root node as a 'struct xfs_bmdr_block'. xfs_bmap_add_attrfork_btree() checks if the btree root node fits inside the data fork of the inode. However, it incorrectly uses 'struct xfs_btree_block' to compute the size of the bmap btree root node. Since size of 'struct xfs_btree_block' is larger than that of 'struct xfs_bmdr_block', xfs_bmap_add_attrfork_btree() could end up unnecessarily demoting the current root node as the child of newly allocated root node. This commit optimizes space usage by modifying xfs_bmap_add_attrfork_btree() to use 'struct xfs_bmdr_block' to check if the bmap btree root node fits inside the data fork of the inode. Reviewed-by:
-
Anthony Iliopoulos authored
Use of the flag has had no effect since kernel commit 288699fe ("xfs: drop dmapi hooks"), which removed all dmapi related code, so deprecate it. Signed-off-by:
Anthony Iliopoulos <ailiop@suse.com> Reviewed-by:
-
Christoph Hellwig authored
Merge _xfs_dic2xflags into its only caller. Signed-off-by:
-
Christoph Hellwig authored
Move the crtime field from struct xfs_icdinode into stuct xfs_inode and remove the now entirely unused struct xfs_icdinode. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the flags2 field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the flags field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the forkoff field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
The i_cowextsize field is only used for v3 inodes, and the i_flushiter field is only used for v1/v2 inodes. Use a union to pack the inode a littler better after adding a few missing guards around their usage. Signed-off-by:
-
Christoph Hellwig authored
Clean up xfs_ioctl_setattr a bit by using XFS_B_TO_FSB. Signed-off-by:
-
Christoph Hellwig authored
Add a local xfs_mount variable, and use the XFS_FSB_TO_B helper. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the flushiter field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the cowextsize field into the containing xfs_inode structure. Also switch to use the xfs_extlen_t instead of a uint32_t. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the extsize field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the nblocks field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the on-disk size field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
In preparation of removing the historic icinode struct, move the projid field into the containing xfs_inode structure. Signed-off-by:
-
Christoph Hellwig authored
The xfs_icdinode structure just contains a random mix of inode field, which are all read from the on-disk inode and mostly not looked at before reading the inode or initializing a new inode cluster. The only exceptions are the forkoff and blocks field, which are used in sanity checks for freshly allocated inodes. Signed-off-by:
-
Christoph Hellwig authored
The legacy DMAPI fields were never set by upstream Linux XFS, and have no way to be read using the kernel APIs. So instead of bloating the in-core inode for them just copy them from the on-disk inode into the log when logging the inode. The only caveat is that we need to make sure to zero the fields for newly read or deleted inodes, which is solved using a new flag in the inode. Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
The crtime only exists for v5 inodes, so only copy it for those. Signed-off-by:
-
Christoph Hellwig authored
Make sure di_flags2 is always initialized. We currently get this implicitly by clearing the dinode core on allocating the in-core inode, but that is about to go away. Signed-off-by:
-
Christoph Hellwig authored
Split looking up the dinode from xfs_imap_to_bp, which can be significantly simplified as a result. Signed-off-by:
-
Chandan Babu R authored
A directory with one directory block which in turns consists of two or more fs blocks is incorrectly flagged as corrupt by scrub since it assumes that "Block" format directories have a data fork single extent spanning the file offset range of [0, Dir block size - 1]. This commit fixes the bug by removing the incorrect check. Signed-off-by:
-
Chandan Babu R authored
xfs/538 can cause the following call trace to be printed when executing on a multi-block directory configuration, WARNING: CPU: 1 PID: 2578 at fs/xfs/libxfs/xfs_bmap.c:717 xfs_bmap_extents_to_btree+0x520/0x5d0 Call Trace: ? xfs_buf_rele+0x4f/0x450 xfs_bmap_add_extent_hole_real+0x747/0x960 xfs_bmapi_allocate+0x39a/0x440 xfs_bmapi_write+0x507/0x9e0 xfs_da_grow_inode_int+0x1cd/0x330 ? up+0x12/0x60 xfs_dir2_grow_inode+0x62/0x110 ? xfs_trans_log_inode+0x234/0x2d0 xfs_dir2_sf_to_block+0x103/0x940 ? xfs_dir2_sf_check+0x8c/0x210 ? xfs_da_compname+0x19/0x30 ? xfs_dir2_sf_lookup+0xd0/0x3d0 xfs_dir2_sf_addname+0x10d/0x910 xfs_dir_createname+0x1ad/0x210 xfs_create+0x404/0x620 xfs_generic_create+0x24c/0x320 path_openat+0xda6/0x1030 do_filp_open+0x88/0x130 ? kmem_cache_alloc+0x50/0x210 ? __cond_resched+0x16/0x40 ? kmem_cache_alloc+0x50/0x210 do_sys_openat2+0x97/0x150 __x64_sys_creat+0x49/0x70 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae This occurs because xfs_bmap_exact_minlen_extent_alloc() initializes xfs_alloc_arg->total to xfs_bmalloca->minlen. In the context of xfs_bmap_exact_minlen_extent_alloc(), xfs_bmalloca->minlen has a value of 1 and hence the space allocator could choose an AG which has less than xfs_bmalloca->total number of free blocks available. As the transaction proceeds, one of the future space allocation requests could fail due to non-availability of free blocks in the AG that was originally chosen. This commit fixes the bug by assigning xfs_alloc_arg->total to the value of xfs_bmalloca->total. Fixes: 30151967 ("xfs: Introduce error injection to allocate only minlen size extents for files") Signed-off-by:
-
Chandan Babu R authored
With dax enabled filesystems, a direct write operation into an existing unwritten extent results in xfs_iomap_write_direct() zero-ing and converting the extent into a normal extent before the actual data is copied from the userspace buffer. The inode extent count can increase by 2 if the extent range being written to maps to the middle of the existing unwritten extent range. Hence this commit uses XFS_IEXT_WRITE_UNWRITTEN_CNT as the extent count delta when such a write operation is being performed. Fixes: 727e1acd ("xfs: Check for extent overflow when trivally adding a new extent") Reported-by:
-
- 25 Mar, 2021 11 commits
-
-
Anthony Iliopoulos authored
Removal of kmem_zone_init wrappers accidentally changed a slab cache name from "xfs_trans" to "xf_trans". Fix this so that userspace consumers of /proc/slabinfo and /sys/kernel/slab can find it again. Fixes: b1231760 ("xfs: Remove slab init wrappers") Signed-off-by:
-
Gao Xiang authored
per-AG resv failure after fixing up freespace is hard to test in an effective way, so directly add an error injection path to observe such error handling path works as expected. Signed-off-by:
Gao Xiang <hsiangkao@redhat.com> Reviewed-by:
-
Gao Xiang authored
As the first step of shrinking, this attempts to enable shrinking unused space in the last allocation group by fixing up freespace btree, agi, agf and adjusting super block and use a helper xfs_ag_shrink_space() to fixup the last AG. This can be all done in one transaction for now, so I think no additional protection is needed. Reviewed-by:
-
Gao Xiang authored
This patch introduces a helper to shrink unused space in the last AG by fixing up the freespace btree. Also make sure that the per-AG reservation works under the new AG size. If such per-AG reservation or extent allocation fails, roll the transaction so the new transaction could cancel without any side effects. Reviewed-by:
-
Gao Xiang authored
Move out related logic for initializing new added AGs to a new helper in preparation for shrinking. No logic changes. Reviewed-by:
-
Gao Xiang authored
sb_fdblocks will be updated lazily if lazysbcount is enabled, therefore when shrinking the filesystem sb_fdblocks could be larger than sb_dblocks and xfs_validate_sb_write() would fail. Even for growfs case, it'd be better to update lazy sb counters immediately to reflect the real sb counters. Reviewed-by:
-
Bhaskar Chowdhury authored
s/strutures/structures/ Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Reviewed-by:
Pavel Reichl <preichl@redhat.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
-
Bhaskar Chowdhury authored
s/sytemcall/syscall/ Signed-off-by:
-
Bhaskar Chowdhury authored
s/filesytem/filesystem/ s/instrumention/instrumentation/ Signed-off-by:
-
Dave Chinner authored
- 21.92% __xfs_trans_commit - 21.62% xfs_log_commit_cil - 11.69% xfs_trans_unreserve_and_mod_sb - 11.58% __percpu_counter_compare - 11.45% __percpu_counter_sum - 10.29% _raw_spin_lock_irqsave - 10.28% do_raw_spin_lock __pv_queued_spin_lock_slowpath We debated just getting rid of it last time this came up and there was no real objection to removing it. Now it's the biggest scalability limitation for debug kernels even on smallish machines, so let's just get rid of it. Signed-off-by: -
Dave Chinner authored
On debug kernels, we call xfs_dir3_leaf_check_int() multiple times on every directory modification. The robust hash ordering checks it does on every entry in the leaf on every call results in a massive CPU overhead which slows down debug kernels by a large amount. We use xfs_dir3_leaf_check_int() for the verifiers as well, so we can't just gut the function to reduce overhead. What we can do, however, is reduce the work it does when it is called from the debug interfaces, just leaving the high level checks in place and leaving the robust validation to the verifiers. This means the debug checks will catch gross errors, but subtle bugs might not be caught until a verifier is run. It is easy enough to restore the existing debug behaviour if the developer needs it (just change a call parameter in the debug code), but overwise the overhead makes testing large directory block sizes on debug kernels very slow. Profile at an unlink rate of ~80k file/s on a 64k block size filesystem before the patch: 40.30% [kernel] [k] xfs_dir3_leaf_check_int 10.98% [kernel] [k] __xfs_dir3_data_check 8.10% [kernel] [k] xfs_verify_dir_ino 4.42% [kernel] [k] memcpy 2.22% [kernel] [k] xfs_dir2_data_get_ftype 1.52% [kernel] [k] do_raw_spin_lock Profile after, at an unlink rate of ~125k files/s (+50% improvement) has largely dropped the leaf verification debug overhead out of the profile. 16.53% [kernel] [k] __xfs_dir3_data_check 12.53% [kernel] [k] xfs_verify_dir_ino 7.97% [kernel] [k] memcpy 3.36% [kernel] [k] xfs_dir2_data_get_ftype 2.86% [kernel] [k] __pv_queued_spin_lock_slowpath Create shows a similar change in profile and a +25% improvement in performance. Signed-off-by:
-
