public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Sławomir Nowakowski" <nailman23@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: XFS issue under 2.6.25.13 kernel
Date: Tue, 26 Aug 2008 11:41:33 +1000	[thread overview]
Message-ID: <20080826014133.GS5706@disturbed> (raw)
In-Reply-To: <50ed5c760808250408o44aeaf07me262eab8da8340ba@mail.gmail.com>

On Mon, Aug 25, 2008 at 01:08:29PM +0200, Sławomir Nowakowski wrote:
> 2008/8/23 Dave Chinner <david@fromorbit.com>:
> 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 2.6.25.13 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 2.6.25.13 kernel system reports no free space,
> but under 2.6.17.13 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 2.6.25.13 kernel gives higher risk of losing data then in case of
> 2.6.17.13 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 2.6.17.13. 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...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2008-08-26  1:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-22 10:03 XFS issue under 2.6.25.13 kernel Sławomir Nowakowski
2008-08-23  1:05 ` Dave Chinner
2008-08-25 11:08   ` Sławomir Nowakowski
2008-08-26  1:41     ` Dave Chinner [this message]
2008-08-26 12:53       ` Sławomir Nowakowski
2008-08-27  0:52         ` Dave Chinner
2008-08-27 18:09           ` Sławomir Nowakowski
2008-08-28  0:20             ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080826014133.GS5706@disturbed \
    --to=david@fromorbit.com \
    --cc=nailman23@gmail.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox