Re: 2.6.34-rc3: inode 0x401afe0 background reclaim flush failed with 11

[Dave Chinner <david@fromorbit.com>]

On Mon, Apr 12, 2010 at 07:57:26PM -0700, Christian Kujau wrote:
> On Tue, 13 Apr 2010 at 12:49, Dave Chinner wrote:
> > No.
> > 
> > http://git.kernel.org/?p=linux/kernel/git/dgc/xfs.git;a=commit;h=7bb6049804717d4aa1f43f2abb50691c0df1d9f2
> 
> Ah, thanks. It's not in -rc4 yet, will it be included in the next release?

It's not even in the xfs-dev tree yet. I'm about to gather all the
outstanding reviewed patches into a branch so that they can get
there, but there's a few patches that need to go to linus, too...

> > > PS: Why is the inode shown in hex and not in decimal? Would something 
> > > like this do:
> > 
> > Because I find that large inode numbers in hex are much easier to
> > understand than huge decimal numbers. The inode number is a direct
> > encoding of it's location on disk and these days I can generally
> > decode them in my head direct from the hex value.
> 
> Hehe, OK. Will learn how to do that too :-)
> 
> > IOWs, the first
> > thing I almost always do when looking at an inode number is convert
> > it to hex, so I don't see any point in printing them in decimal...
> 
> I was tempted to "find . -inum" to find out which data might be in trouble 
> but then noticed that I had to convert it to decimal first.

Hmmm - I'd never realised that find doesn't decode hex numbers.
I guess I rarely use find for that purpose. I'll keep that in mind
when adding new output.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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