From patchwork Wed May 18 08:19:03 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 96136 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id AE30DB6F59 for ; Wed, 18 May 2011 18:19:09 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755201Ab1ERITH (ORCPT ); Wed, 18 May 2011 04:19:07 -0400 Received: from mail-ey0-f174.google.com ([209.85.215.174]:48903 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754316Ab1ERITF convert rfc822-to-8bit (ORCPT ); Wed, 18 May 2011 04:19:05 -0400 Received: by eyx24 with SMTP id 24so367264eyx.19 for ; Wed, 18 May 2011 01:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M8q8pLen3U1m8A2DwO9GYdLk+RbVvIqVXVxJMQQOwYc=; b=E1h9u4jGpXRpgVK1qzkYjOAXiySWjGFLZjv1kycrxYAKQiDJ86/+/6f40Q4kBgTtS7 gE9ppO6/S4/nERnMFLCZB6r5U4FG5r3wrKdYycdJkPhfbnLiUfsAs99EZv5FVRe3t6y4 3LHtvRIM13eC1kyOyD+Uf/RKcP22IF4jhziVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vFQM+81Q/d3NvjKg/QDv+4BKonI/ukROouxYgKokBCUaPi3wKA78HFbrXQB6dLlDQw BQqbylWAaAuXbX11t6kZdvWwIa9grAg4GZLRt90z5r7eix0kxHbQ4b2eooFMzzBemDGI +qc7zLaFxF5v2eY53r+JDs1UhdfZ1C+Ic+C0U= MIME-Version: 1.0 Received: by 10.14.46.214 with SMTP id r62mr511000eeb.99.1305706743893; Wed, 18 May 2011 01:19:03 -0700 (PDT) Received: by 10.14.45.3 with HTTP; Wed, 18 May 2011 01:19:03 -0700 (PDT) In-Reply-To: <20110518063153.GZ19446@dastard> References: <4DD286E5.8090105@redhat.com> <20110518063153.GZ19446@dastard> Date: Wed, 18 May 2011 11:19:03 +0300 Message-ID: Subject: Re: xfstests: device busy when umount From: Amir Goldstein To: Dave Chinner Cc: Eric Sandeen , Yongqiang Yang , Ext4 Developers List , xfs-oss Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, May 18, 2011 at 9:31 AM, Dave Chinner wrote: > On Tue, May 17, 2011 at 06:01:14PM +0300, Amir Goldstein wrote: >> On Tue, May 17, 2011 at 5:32 PM, Eric Sandeen wrote: >> > On 5/17/11 4:03 AM, Yongqiang Yang wrote: >> >> Hi, >> >> >> >> I noticed that all tests which contain 'device busy' errors have >> >> falloc operations.  Does the error have something to do with falloc? > > > > Perhaps a bit more detail about what you are testing, how you've set > up xfstests, etc, and some analysis of the problem is in order first? ^2 Let me make it simple: amir@qalab:~/xfstests$ uname -a Linux qalab 2.6.39-rc7+ #11 SMP Mon May 16 12:08:52 IDT 2011 x86_64 x86_64 x86_64 GNU/Linux amir@qalab:~/xfstests$ mount -t ext4 /dev/sdb1 on / type ext4 (rw,errors=remount-ro,commit=0) /dev/sda5 on /mnt/test/ext4 type ext4 (rw,acl,user_xattr) amir@qalab:~/xfstests$ cat local.config export DISABLE_UDF_TEST=1 export TEST_DEV=/dev/sda5 export TEST_DIR=/mnt/test/ext4 export SCRATCH_DEV=/dev/sda8 export SCRATCH_MNT=/mnt/test/scratch amir@qalab:~/xfstests$ sudo ./check 124 FSTYP -- ext4 PLATFORM -- Linux/x86_64 qalab 2.6.39-rc7+ MKFS_OPTIONS -- /dev/sda8 MOUNT_OPTIONS -- -o acl,user_xattr /dev/sda8 /mnt/test/scratch 124 9s ... - output mismatch (see 124.out.bad) Ran: 124 Failures: 124 Failed 1 of 1 tests amir@qalab:~/xfstests$ mount -t ext4 /dev/sdb1 on / type ext4 (rw,errors=remount-ro,commit=0) /dev/sda8 on /mnt/test/scratch type ext4 (rw,acl,user_xattr) /dev/sda5 on /mnt/test/ext4 type ext4 (rw,acl,user_xattr) amir@qalab:~/xfstests$ sudo umount /mnt/test/scratch/ amir@qalab:~/xfstests$ mount -t ext4 /dev/sdb1 on / type ext4 (rw,errors=remount-ro,commit=0) /dev/sda5 on /mnt/test/ext4 type ext4 (rw,acl,user_xattr) I am not trying anything special. Running umount from command line after the test succeeds, so it must be some kind of race. As I said, I tried running lsof before umount in common.rc, but it detected nothing. Do you have any suggestions for further analysis? > >> > cc'ing xfs list since xfs devs maintain xfstests. >> > >> > What tests have "device busy" errors?  What do the usual investigative >> > steps such as "lsof" and "fuser" tell you when this happens? >> >> I tried running lsof | grep $TEST_DIR before umount >> and I tried sleep 1 before umount and it didn't yield anything. > > Which usually indicates that you've got some kind of reference > counting problem preventing the filesystem from being unmounted. As I demonstrated, the filesystem *can* be unmounted. > >> > Are there loop devices that didn't get cleaned up, or processes that >> > have not terminated? >> > >> > What tests have these problems? >> >> for me 124 always fails to umount, and 198 and 213 sometimes fails to umount. > > What, exactly, are you testing on? test 124 uses XFS_IOC_RESVSP > directly, not fallocate(), so all it is doing on a non-XFS > filesystem is iterating a loop that writes a 1MB file, reads it back > then unlinks it.... > Tell me about it... The machine was a clean install of Ubuntu 10.10, which was recently upgraded to Ubuntu 11.4, but this problem existed since the beginning. It is used for nothing but running tests and I only installed packages required (to my understanding) by xfstests. I just build xfstests from git (HEAD 30456902). The kernel is latest 2.6.39-rc7 with ext4 dev branch changed, but again, the problem existed with any previous/release kernel I tried. Cheers, Amir. --- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- 124.out 2011-03-01 18:00:49.808338003 +0200 +++ 124.out.bad 2011-05-18 10:47:01.830998615 +0300 @@ -1 +1,4 @@ QA output created by 124 +umount: /mnt/test/scratch: device is busy. + (In some cases useful info about processes that use + the device is found by lsof(8) or fuser(1))