public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Arkadiusz Bubała" <arkadiusz.bubala@open-e.com>
Cc: xfs@oss.sgi.com
Subject: Re: [BUG] Call trace during snapshot start/stop sequence
Date: Fri, 29 Nov 2013 08:16:50 +1100	[thread overview]
Message-ID: <20131128211650.GQ10988@dastard> (raw)
In-Reply-To: <52971442.8080701@open-e.com>

On Thu, Nov 28, 2013 at 11:00:34AM +0100, Arkadiusz Bubała wrote:
> Hello,
> thank you for valuable information.
> 
> On 28.11.2013 00:06, Dave Chinner wrote:
> >
> >>Running a custom built 3.4.63 kernel with a bunch of out of tree
> >>modules installed. can you reproduce this on a vanilla 3.12 kernel?
> >>
> Ok, we'll try.
> 
> >The script is full of bugs, and i don't have time to debug it - it
> >hard codes /dev/sda in places despite taking the device as a CLI
> >parameter. It has hard coded mount points.  It sometimes fails to
> >make the filesystem on the base LV after it's been created.
> >start_snap() appears to fail for some reason, as it doesn't result
> >in mounted snapshots. stop_snap fails as well:
> >
> >Starting snap19 : Thursday 28 November  10:01:26 EST 2013
> >   Logical volume lv1+snap19 converted to snapshot.
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ OK ] lv1+snap19 activated.
> >Starting time : 37 s.
> >---------------------------
> >Stopping snap0 : Thursday 28 November  10:02:06 EST 2013
> >[ FAIL ] Can't umount snapshot
> >[ FAIL ] Can't remove snapshot
> >[ FAIL ] lv0+snap00 still active !!!
> >[ OK ] lv0+snap00 umounted.
> >Stopping time : 0 s.
> >
> >I've got no idea is this is intended behaviour, but it sure doesn't
> >seem right to me...
> >
> >
> Yes, sometimes umount and remove operations fail.

They always fail here - snapshots are not being mounted at all
(nothing in dmesg about XFS filesystems being mounted during the
test at all), so the test does not appear to be doing what you
expect to be doing...

> This script tests
> system stability and these messages are debug info only.

It ran overnight on a TOT 3.13-rc1 kernel with memory leak and
poisoning turned on, issuing those fail messages and nothing
broke...

> I've fixed it. Now it takes two parameters: device and mount point.

I'll try it again...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2013-11-28 21:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27 10:01 [BUG] Call trace during snapshot start/stop sequence Arkadiusz Bubała
2013-11-27 22:19 ` Dave Chinner
2013-11-27 23:06   ` Dave Chinner
2013-11-28 10:00     ` Arkadiusz Bubała
2013-11-28 21:16       ` Dave Chinner [this message]
2013-12-05  8:36         ` Arkadiusz Bubała

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=20131128211650.GQ10988@dastard \
    --to=david@fromorbit.com \
    --cc=arkadiusz.bubala@open-e.com \
    --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