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 188.8.131.52 and 184.108.40.206 we'd like to ask
> some questions.
> We was based on git repository:
> We have reverted some changes for XFS in 220.127.116.11 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 18.104.22.168 kernel. This
> patch should eliminate additional reservation of disk space in XFS
> file system. Our intention was to get similarity space of disk between
> 22.214.171.124 and 126.96.36.199 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).