summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_alloc.h
diff options
context:
space:
mode:
authorDavid Chinner <david@fromorbit.com>2008-10-30 17:38:12 +1100
committerLachlan McIlroy <lachlan@redback.melbourne.sgi.com>2008-11-10 17:51:14 +1100
commit6f9f51adb6ac0a49fce49e01c47dcfc2810c6e9d (patch)
tree0286cc775521b135e481a4eb26391bc3e4cc8950 /fs/xfs/xfs_alloc.h
parent2cf7f0da3ae225848a2ee10d4e216448a770fd00 (diff)
[XFS] Account for allocated blocks when expanding directories
When we create a directory, we reserve a number of blocks for the maximum possible expansion of of the directory due to various btree splits, freespace allocation, etc. Unfortunately, each allocation is not reflected in the total number of blocks still available to the transaction, so the maximal reservation is used over and over again. This leads to problems where an allocation group has only enough blocks for *some* of the allocations required for the directory modification. After the first N allocations, the remaining blocks in the allocation group drops below the total reservation, and subsequent allocations fail because the allocator will not allow the allocation to proceed if the AG does not have the enough blocks available for the entire allocation total. This results in an ENOSPC occurring after an allocation has already occurred. This results in aborting the directory operation (leaving the directory in an inconsistent state) and cancelling a dirty transaction, which results in a filesystem shutdown. Avoid the problem by reflecting the number of blocks allocated in any directory expansion in the total number of blocks available to the modification in progress. This prevents a directory modification from being aborted part way through with an ENOSPC. SGI-PV: 988144 SGI-Modid: xfs-linux-melb:xfs-kern:32340a Signed-off-by: David Chinner <david@fromorbit.com> Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Diffstat (limited to 'fs/xfs/xfs_alloc.h')
0 files changed, 0 insertions, 0 deletions