public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Linda A. Walsh" <xfs@tlinx.org>
To: xfs-oss <xfs@oss.sgi.com>
Subject: re: xfs: xfs_swap_extents needs to handle dynamic fork offsets
Date: Mon, 08 Aug 2011 16:18:37 -0700	[thread overview]
Message-ID: <4E406ECD.2020708@tlinx.org> (raw)

Saw this description from a patch set to lkml:
( http://lkml.indiana.edu/hypermail/linux/kernel/1004.2/02461.html )
========================================================
From: Greg KH
Date: Thu Apr 22 2010 - 16:43:40 EST
Subj: [022/197] xfs: xfs_swap_extents needs to handle dynamic fork offsets

2.6.32-stable review patch. If anyone has any objections, please let us 
know.
------------------
From: Dave Chinner <david@xxxxxxxxxxxxx>
commit e09f98606dcc156de1146c209d45a0d6d5f51c3f upstream
=========================================================
Description says...(brackets, [], added to highlight/break apart
some sections):

...
Changing the way xfs_fsr sets up the attribute fork will prevent
this situation from ever occurring, so in the kernel code we can get
by with a preventative fix - check that the data fork in the
defragmented inode is in a format valid for the inode it is being
swapped into.  [
]
This will lead to files that will silently and
potentially repeatedly fail defragmentation, [
***] so _issue_ _a_ _warning_ to the log when this particular
failure occurs to let us know that [
***]_xfs_fsr_ _needs_ _updating/fixing_.[***]


"To help identify how to improve xfs_fsr to avoid this issue, add
trace points for the inodes being swapped so that we can determine
why the swap was rejected and to confirm that the code is making the
right decisions and modifications when swapping forks. "
....
=========================================================
lower in the code you added the message:
=========================================================
+ /* check inode formats now that data is flushed */
+ error = xfs_swap_extents_check_format(ip, tip);
+ if (error) {
+ xfs_fs_cmn_err(CE_NOTE, mp,
+ "%s: inode 0x%llx format is incompatible for exchanging.",
+ __FILE__, ip->i_ino);
goto out_unlock;
}
=========================================================

I'm seeing several of these in 'dmesg':

[873569.328221] Filesystem dm-6: fs/xfs/xfs_dfrag.c: inode 0x8227a310 
format is incompatible for exchanging.
[873623.752724] Filesystem dm-6: fs/xfs/xfs_dfrag.c: inode 0x8227a310 
format is incompatible for exchanging.
[873669.721127] Filesystem dm-6: fs/xfs/xfs_dfrag.c: inode 0x8227a310 
format is incompatible for exchanging.
...

----
am running 2.6.38.3,

& version 3.1.4-2.1 of 'xfsprogs'....

Is there a version of xfs_fsr that fixes these problems, or is this
this still something on the 'todo list' (I don't notice any other 
aberrant behaviors
that might have anything to do with this)...Just thought I'd ask about
the weird messages...

Thanks,
Linda



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2011-08-08 23:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-08 23:18 Linda A. Walsh [this message]
2011-08-09  0:04 ` xfs: xfs_swap_extents needs to handle dynamic fork offsets 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=4E406ECD.2020708@tlinx.org \
    --to=xfs@tlinx.org \
    --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