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@xxxxxxxxxxxxx
|