All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: xfs@oss.sgi.com
Subject: Re: xlog_space_left: head behind tail
Date: Mon, 27 Feb 2012 12:28:29 +1100	[thread overview]
Message-ID: <20120227012829.GS3592@dastard> (raw)
In-Reply-To: <20120223105418.GB24638@quack.suse.cz>

On Thu, Feb 23, 2012 at 11:54:18AM +0100, Jan Kara wrote:
> On Thu 23-02-12 11:48:53, Jan Kara wrote:
> >   Hello,
> > 
> >   when I run:
> > while true; do ~/tests/xfstests-dev/ltp/fsstress -d /mnt -n 10000 -p 4; done
> > 
> > and in parallel
> > 
> > while true; do ./fsfreeze /mnt; sync; ./fsfreeze -u /mnt; sleep 3; done
> > 
> > where fsfreeze is a small utility freezing and unfreezing filesystem.

Ah, the world has been reinvented again:

$ xfs_io -x -c "help freeze" -c "help thaw"
freeze -- freeze filesystem of current file
thaw -- unfreeze filesystem of current file

> > I get
> > warnings like:
>   BTW, the first message is:
> [ 1626.278347] XFS (vdb1): xlog_space_left: head behind tail
> [ 1626.278349]   tail_cycle = 7, tail_bytes = 12907008
> [ 1626.278351]   GH   cycle = 7, GH   bytes = 12907000

So out by 8 bytes.

This is indicative of a transaction reservation accounting error or
a race condition in updating the grant heads during transaction
reservation/completion.

> > [ 2029.103193] XFS (vdb1): xlog_space_left: head behind tail
> > [ 2029.103195]   tail_cycle = 10, tail_bytes = 6036480
> > [ 2029.103197]   GH   cycle = 10, GH   bytes = 6035728

and 400s later is it out by 752 bytes

> > [ 2029.103218] XFS (vdb1): xlog_space_left: head behind tail
> > [ 2029.103219]   tail_cycle = 10, tail_bytes = 6036480
> > [ 2029.103220]   GH   cycle = 10, GH   bytes = 6035728
> > [ 2033.269796] XFS (vdb1): xlog_space_left: head behind tail
> > [ 2033.269800]   tail_cycle = 10, tail_bytes = 6400512
> > [ 2033.269803]   GH   cycle = 10, GH   bytes = 6399752

And 4s later (a single freeze) it is out by 760 bytes.

Ok, so that looks like a 8 byte accounting leak rather than a race
that is occurring. Given that it has been roughly 400s since the
first report, and you're running a freeze roughly every 4s, that's
100 freezes, and that's roughly 800 bytes which is in the ballpark
for 8 bytes a freeze being leaked.

I'll look into it further.

> Is it a real problem or just annoyance?

Real problem, but something rather unlikely to be tripped over in
the real world....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

      reply	other threads:[~2012-02-27  1:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 10:48 xlog_space_left: head behind tail Jan Kara
2012-02-23 10:54 ` Jan Kara
2012-02-27  1:28   ` Dave Chinner [this message]

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=20120227012829.GS3592@dastard \
    --to=david@fromorbit.com \
    --cc=jack@suse.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.