Re: XFS issue under 2.6.25.13 kernel

[Dave Chinner <david@fromorbit.com>]

On Wed, Aug 27, 2008 at 08:09:18PM +0200, Sławomir Nowakowski wrote:
> Dear Dave,
> 
> We really apreciate your help..
> 
> In the realtion to previous correspondations about differences between
> implementation of kernels 2.6.17.13 and 2.6.25.13 we'd like to ask
> some questions.
> 
> We was based on git repository:
> 
> git://git.kernel.org
> 
> We have reverted some changes for XFS in 2.6.25.13 kernel. We have
> usedf 3 commits:
> 
> - 94E1E99F11... (SGI-PV: 964468)
> - 4BE536DEBE... (SGI-PV: 955674)
> - 4CA488EB4...  (SGI-PV: 971186)
> 
> With these changes we have created patch for 2.6.25.13 kernel. This
> patch should eliminate additional reservation of disk space in XFS
> file system. Our intention was to get similarity space of disk between
> 2.6.17.13 and 2.6.25.13 kernels.

After removing the reservation with xfs_io (the big difference), I
don't see why you need to hack the kernel as well. Have you got
such little margin in your filesystem provisioning that you can't
spare 4 blocks per AG?

> Does patch that is attached to this mail do everything properly?

Don't know. You've taken away a bunch of reserved blocks other
code relies on existing for correct operation at ENOSPC. Given
that you are doing this because you are running so close to
ENOSPC there's a good chance that you've broken something.

I don't have the time (or the desire) to analyse the impact of the
changes being made, but I bet that the XFSQA tests that exercise
behaviour at ENOSPC will start to deadlock again...

> Is it
> 100% compatibe with XFS API?

You've changed statfs. You'll have to make sure it reports
the correct thing in all cases (there's an XFSQA test for this).

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com