All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: fstests@vger.kernel.org
Subject: Re: trouble with generic/081
Date: Thu, 15 Dec 2016 14:29:44 +0800	[thread overview]
Message-ID: <20161215062944.GE28577@eguan.usersys.redhat.com> (raw)
In-Reply-To: <20161214164314.GA25105@infradead.org>

On Wed, Dec 14, 2016 at 08:43:14AM -0800, Christoph Hellwig wrote:
> Hi Eryu,
> 
> I'm running into a fairly reproducable issue with generic/081
> (about every other run): For some reason the umount call in
> _cleanup doesn't do anything because it thinks the file system isn't
> mounted, but then vgremove complains that there is a mounted file
> system.  This leads to the scratch device no being release and all
> subsequent tests failing.
> 
> Here is the output if I let the commands in _cleanup print to stdout:
> 
> QA output created by 081
> Silence is golden
> umount: /mnt/test/mnt_081: not mounted
>   Logical volume vg_081/snap_081 contains a filesystem in use.
>   PV /dev/sdc belongs to Volume Group vg_081 so please use vgreduce first.

Yes, I have this problem too.

My original patch didn't have "-c fsync" in the last xfs_io pwrite
command,

$XFS_IO_PROG -fc "pwrite 0 5m" -c fsync $mnt/testfile >>$seqres.full 2>&1

and Brian suggested that an explicit fsync would make the test clear.
And Dave added it and committed the patch.

https://www.spinics.net/lists/fstests/msg01265.html

This cleanup failure was the exact reason why I didn't include fsync at
first.

https://www.spinics.net/lists/fstests/msg01269.html

Then I sent a follow-up patch to workaround this issue, but Dave
suggested that we should triage and fix the underlying bug first (if
there's any).

https://www.spinics.net/lists/fstests/msg01406.html

I tried to follow & dig into it but went nowhere, I didn't know that
part of code good enough..

> 
> You added a comment in _cleanup that sais:
> 
> # lvm may have umounted it on I/O error, but in case it does not
> 
> Does LVM really unmount filesystems on it's own?  Could we be racing
> with it?

IIRC, there's some kind of hooks in LVM that unmount the filesystems,
but I can't recall the details now.. From the ending results, the
filesystems are umounted, perhaps that's why you see "/mnt/test/mnt_081:
not mounted" (this error message is redirected to /dev/null in the
test).

> 
> With a "sleep 1" added before the umount call the test passes reliably
> for me, but that seems like papering over the issue.

Do you have any preference on this?

Thanks,
Eryu

  reply	other threads:[~2016-12-15  6:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14 16:43 trouble with generic/081 Christoph Hellwig
2016-12-15  6:29 ` Eryu Guan [this message]
2016-12-15  6:36 ` Dave Chinner
2016-12-15  8:42   ` Christoph Hellwig
2016-12-15  9:16     ` Zdenek Kabelac
2016-12-16  8:15       ` Christoph Hellwig
2016-12-16  9:31         ` Zdenek Kabelac
2017-01-04 23:03         ` Eric Sandeen
2017-01-05 10:35           ` Zdenek Kabelac
2017-01-05 10:35             ` Zdenek Kabelac
2017-01-05 16:26             ` Mike Snitzer
2017-01-05 17:42               ` Zdenek Kabelac
2017-01-05 17:42                 ` Zdenek Kabelac
2017-01-05 18:07                 ` Mike Snitzer
2017-01-05 18:40                 ` Eric Sandeen
2017-01-05 18:24             ` Eric Sandeen
2017-01-05 18:52               ` Mike Snitzer
2017-01-05 19:13               ` Zdenek Kabelac
2017-01-05 19:29                 ` Eric Sandeen
2017-01-05 21:12                   ` Zdenek Kabelac
2017-01-05 22:03                     ` Eric Sandeen
2017-01-05 22:46                     ` Dave Chinner
2017-01-09 13:39                       ` Christoph Hellwig
2017-01-09 14:22                         ` Zdenek Kabelac
2017-01-09 14:54                           ` Eric Sandeen
2017-01-09 15:11                             ` Zdenek Kabelac
2017-01-10  2:48                               ` Theodore Ts'o
2017-01-10  4:30                             ` Darrick J. Wong
2017-01-09 15:01                           ` Christoph Hellwig

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=20161215062944.GE28577@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=hch@infradead.org \
    /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.