aboutsummaryrefslogtreecommitdiff
path: root/fs/splice.c
diff options
context:
space:
mode:
authorDavid Chinner <david@fromorbit.com>2008-10-30 17:38:12 +1100
committerLachlan McIlroy <lachlan@sgi.com>2008-10-30 17:38:12 +1100
commita7444053fb3ebd3d905e3c7a7bd5ea80a54b083a (patch)
treea7c09acf01c1b9a3c13684059ec88637cfa93155 /fs/splice.c
parent8c38ab032094ff1d903c79db689607b1ebae13ca (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/splice.c')
0 files changed, 0 insertions, 0 deletions