On 04/09/2013 11:48 AM, çææ wrote:
> I'll work on reproducing the issue, can you share some tracing script to
> me? Thank you.
We're interested in tracking this problem down and are working on a
script that might help us gather more information. We still have some
research to do there, so please be patient! We'll share it when ready.
In the meantime, I think it would be helpful to take Eric's advice if
this occurs again:
- umount/remount to replay the XFS log.
- umount and collect a metadump of the filesystem (xfs_metadump). We'd
be interested to see this if you're willing/able to collect and share it
(note that this covers the fs prior to repair).
- capture the xfs_repair output and share that as well.
> 2013/4/9 Eric Sandeen <sandeen@xxxxxxxxxxx <mailto:sandeen@xxxxxxxxxxx>>
> On 4/9/13 10:23 AM, çææ wrote:
> > So my question is why xfs shutdown always happens? With same
> > reason(xfs_iunlink_remove: xfs_inotobp() returned error 22
> > xfs_inactive: xfs_ifree returned error 22 xfs_do_force_shutdown).
> > The server load is high and is it related?
> We don't know yet. :)
> I'd like to know what was passed to xfs_inotobp when it shut down,
> and what caused the EINVAL (22) return. Perhaps some tracing
> or systemtap scripts could to it.
> If you only hit this every few weeks, though, it's going to be
> difficult to catch.
> > free -m
> > total used free shared buffers
> > Mem: 129016 128067 948 0 10
> > -/+ buffers/cache: 8150 120865
> > Swap: 4093 0 4093
> xfs mailing list