Badness in xfs_write at fs/xfs/linux-2.6/xfs_lrw.c:838

Badness in xfs_write at fs/xfs/linux-2.6/xfs_lrw.c:838

[andutt]

Hi Xfs foks

I have some problem with an XFS filesystem, im running Suse SLES 10
SP2, with 2.6.16.60-0.42.7-smp kernel untop of a veritas 1Tb volume, a
couple of times per day i get following in my kernel log.

Badness in xfs_write at fs/xfs/linux-2.6/xfs_lrw.c:838
Call Trace: <ffffffff88bcb550>{:xfs:xfs_write+1415}
<ffffffff8014ab93>{get_futex_key+71}
<ffffffff8014acff>{unqueue_me+134}
<ffffffff88bc7c5a>{:xfs:xfs_file_aio_write+103}
<ffffffff80185f15>{do_sync_write+199}
<ffffffff8012c6f7>{default_wake_function+0}
<ffffffff80171d1d>{find_extend_vma+22}
<ffffffff8014ba50>{do_futex+1869}
<ffffffff8014820e>{autoremove_wake_function+0}
<ffffffff802ea6c0>{thread_return+0} <ffffffff8018684e>{vfs_write+215}
<ffffffff80186f06>{sys_pwrite64+82} <ffffffff8010bced>{error_exit+0}
<ffffffff8010ae16>{system_call+126}
Badness in xfs_write at fs/xfs/linux-2.6/xfs_lrw.c:838

I have used xfs_check on the device, and it did not report any errors
and the filesystem is mounteble with no errors,  do you guys have any
idea:s on how to proceed?, or what could be the source of the problem?

Thanx in advance!

/Andreas

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

Re: Badness in xfs_write at fs/xfs/linux-2.6/xfs_lrw.c:838

[Ben Myers]

Andutt,

On Thu, Jan 21, 2010 at 10:16:45AM +0100, andutt wrote:
> I have some problem with an XFS filesystem, im running Suse SLES 10
> SP2, with 2.6.16.60-0.42.7-smp kernel untop of a veritas 1Tb volume, a
> couple of times per day i get following in my kernel log.
> 
> Badness in xfs_write at fs/xfs/linux-2.6/xfs_lrw.c:838

(I am picking up this old thread for the benefit of the mail archive, whose
results I found to be inadequate.  Hopefully what follows is sufficient
explanation of this warning for the next poor fool.  It may even be correct.)

I was able to reproduce this (once) by running the following overnight:

while true; do dd if=/dev/zero of=file conv=notrunc bs=4k count=1000 oflag=direct; done
while true; do dd if=file of=/dev/null bs=1k count=10000 iflag=direct; done
while true; do dd if=file of=/dev/null bs=4k count=10000; done
while true; do dd if=file of=/dev/null bs=4k count=10000; done
while true ; do dd if=file of=/dev/null bs=1k count=1000; done
while true; do dd if=file of=/dev/null bs=4k count=10000; done
while true ; do dd if=file of=/dev/null bs=1k count=1000; done          * 'ish
while true ; do dd if=file of=/dev/null bs=1k count=1000; done          * 'ish

* ish... maybe this is what I ran.  It's not in scrollback.

I believe what we are seeing is a thin race between the direct write and the
buffered readers adding cached pages to the file.  It looks to me that the
direct write and the readers all take the iolock shared.  So there is no
exclusion between them when the direct write checks for cached pages in the
file to determine whether to take the iolock exclusive to flush them out, and
when the actual flushing and WARN_ON occur.  The buffered readers can read data
from disk into the cache during this window and this causes the WARN_ON to
fire.

The standard advice given here is:  "Don't do direct and buffered io
concurrently on the same file."

It seems to me that having pages cached during the direct write isn't
necessarily a problem.  These pages might be at offsets that do not overlap
with the direct write, and this would be a perfectly valid usage of concurrent
direct and buffered io.  I believe the required semantics of an overlapping
buffered/direct situation are undefined (I could be horribly wrong).  And XFS
leaves it up to the application to use adequate locking to prevent overlapping
concurrent buffered and direct io.  It looks like running flushinval with
iolock shared is not a problem here, and there cannot be any dirty pages
because the direct write has the iolock shared and buffered writes take it
exclusive.

I suggest you 1) be certain that your application is doing the Right Thing, and
then 2) ignore the warning.

It really is up to the application to do the right thing in this area.  And the
warning doesn't (necessarily) indicate that the application did something
wrong, just that it could have.

This warning has been removed from xfs in v3.1 (see c58cb165). 

-Ben

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