[Top] [All Lists]

Re: XFS issue under kernel

To: Sławomir Nowakowski <nailman23@xxxxxxxxx>
Subject: Re: XFS issue under kernel
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 26 Aug 2008 11:41:33 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <50ed5c760808250408o44aeaf07me262eab8da8340ba@xxxxxxxxxxxxxx>
Mail-followup-to: Sławomir Nowakowski <nailman23@xxxxxxxxx>, xfs@xxxxxxxxxxx
References: <50ed5c760808220303p37e03e8dge5b868a572374e0b@xxxxxxxxxxxxxx> <20080823010524.GM5706@disturbed> <50ed5c760808250408o44aeaf07me262eab8da8340ba@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Aug 25, 2008 at 01:08:29PM +0200, Sławomir Nowakowski wrote:
> 2008/8/23 Dave Chinner <david@xxxxxxxxxxxxx>:
> Next we have created some files:
> -one big file called "bigfile" and size of 5109497856 bytes
> -two small text files called: "file1" and "file2"
> At this stage it looked as follows:
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/sda3              4993984   4989916      4068 100% /mnt/z
> Then we have run system with kernel and checked how it looks:
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/sda3              4993984   4993984         0 100% /mnt/z
> As it shown in case of kernel system reports no free space,
> but under kernel there is 4068kB of free space.
> At this stage when editing file  file1 with i.e. mcedit and trying to
> write changes, the system cuts this file to 0 bytes!

Oh, look, yet another editor that doesn't safely handle ENOSPC and
trashes files when it can't overwrite them. That's not an XFS
problem - I suggest raising a bug against the editor....

> >> 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....
> A question: does using the command:
> $ sudo xfs_io -x -c 'resblks 0' <file in filesystem>
> for kernel gives higher risk of losing data then in case of
> kernel.

Hard to say. If you don't run to ENOSPC then there is no difference.
If you do run to ENOSPC then I think that there is a slightly higher
risk of tripping problems on 2.6.25.x because of other ENOSPC fixes
that have been included since This really is a safety net
in that it allows the system to continue without problems in
conditions where it would have previously done a bad thing...


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>