On Fri, Aug 22, 2008 at 12:03:40PM +0200, SÅawomir Nowakowski wrote:
> Dear All,
> We have a problem with implementing xfs file system for Linux. The problem
> appears after mounting xfs file system on 188.8.131.52 kernel that is created on
> 184.108.40.206 kernel.
> File system is created on logical volume in the following way:
> lvcreate -L 4G volume1 -n test
> mkfs.xfs /dev/volume1/test
> mount /dev/volume1/test /mnt/x
> After mounting it on 220.127.116.11 kernel "df -B 1" output looks like this:
> /dev/volume1/test 4284481536 147456 4284334080 1% /mnt/x
> but in case of 18.104.22.168 kernel:
> /dev/volume1/test 4284481536 4489216 4279992320 1% /mnt/x
> The same happens in case of 22.214.171.124 kernel.
Yeah, we reserved 4MB of space for unreserved delayed metadata
allocations to allow transactions to succeed when at ENOSPC. That
reservation is accounted as 'used space' to prevent it being used by
> As it is shown after mounting the volume in newer kernel size of file system
> is visible smaller. The problem appears when on this volume exists one big
> file, occupying all available space. After trying to mount it under newer
> kernel, the file is cut because available free space is smaller.
What is on disk will not change - the reservation is purely an
in-memory construct. i.e. if the file already exists then it
won't change on upgrade. Can you show how the file changes just
by booting a different kernel (e.g. ls -l output, md5sums, etc).
> Is it known issue and/or does solution or workaround exists?
$ sudo xfs_io -x -c 'resblks 0' <file in filesystem>
will remove the reservation. This means your filesystem can shutdown
or lose data at ENOSPC in certain circumstances....