From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752105AbbLNO7Y (ORCPT ); Mon, 14 Dec 2015 09:59:24 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36351 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751533AbbLNO7W (ORCPT ); Mon, 14 Dec 2015 09:59:22 -0500 To: "Linux-Kernel@Vger. Kernel. Org" From: Nikolay Borisov Subject: umount saying that a mounted directory is not mounted Message-ID: <566ED943.9020407@siteground.com> Date: Mon, 14 Dec 2015 16:59:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070402090900070401010004" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------070402090900070401010004 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello, I'm using the attached script to perform some tests. However from time to time I get the following results: [root@kernighan lvm-race]# bash -x ./init_vg.sh + set -e ++ mktemp -u --tmpdir=. vgfile.XXXX + file=./vgfile.lCdz ++ mktemp -u testgrp-XXXX + group=testgrp-OgAz ++ mktemp -u thingrp-XXXX + thingroup=thingrp-h8mw ++ mktemp -d --tmpdir=. mntdir-XXXX + mntpath=./mntdir-KpMO ++ mktemp -u testvol-XXXX + volume_name=testvol-JvsQ + volume_size=200M + truncate ./vgfile.lCdz --size 10G ++ losetup -f --show ./vgfile.lCdz + loopdev=/dev/loop2 + pvcreate --metadatasize 1M /dev/loop2 allocation/use_blkid_wiping=1 configuration setting is set while LVM is not compiled with blkid wiping support. Falling back to native LVM signature detection. Physical volume "/dev/loop2" successfully created + vgcreate testgrp-OgAz -s 1MiB /dev/loop2 Volume group "testgrp-OgAz" successfully created ++ vgdisplay /dev/testgrp-OgAz ++ grep 'PE Size' ++ awk '{print $3}' + pe_size=1.00 ++ bc -l +++ vgdisplay /dev/testgrp-OgAz +++ grep 'Free PE' +++ awk '{print $5}' ++ echo '10238*1.00-180' + thin_size=10058.00 + lvcreate --ignoreactivationskip -Z n -L 10058.00M -T /dev/testgrp-OgAz/thingrp-h8mw Logical volume "thingrp-h8mw" created. + lvcreate --ignoreactivationskip -V200M -T testgrp-OgAz/thingrp-h8mw -n testvol-JvsQ allocation/use_blkid_wiping=1 configuration setting is set while LVM is not compiled with blkid wiping support. Falling back to native LVM signature detection. Logical volume "testvol-JvsQ" created. + mkfs.ext4 /dev/testgrp-OgAz/testvol-JvsQ mke2fs 1.42.12 (29-Aug-2014) Discarding device blocks: done Creating filesystem with 51200 4k blocks and 12800 inodes Filesystem UUID: 303208ff-3c52-451e-8cf3-5c5bf2212902 Superblock backups stored on blocks: 32768 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done + sync + vgchange -Kan testgrp-OgAz 0 logical volume(s) in volume group "testgrp-OgAz" now active + losetup -d /dev/loop2 + echo 'Volume created, doing work' Volume created, doing work + for i in '{1..10}' + echo 'Doing iteration 1' Doing iteration 1 ++ losetup -f --show ./vgfile.lCdz + loopdev=/dev/loop2 + vgchange -Kay testgrp-OgAz 2 logical volume(s) in volume group "testgrp-OgAz" now active + mount /dev/testgrp-OgAz/testvol-JvsQ ./mntdir-KpMO + rm -rf ./mntdir-KpMO/lost+found ++ mktemp -u tmpfile.XXXX ++ get_random ++ local number=0 ++ '[' 0 -le 20 ']' ++ number=244 ++ let 'number %= 50' ++ '[' 44 -le 20 ']' ++ echo 44 + dd if=/dev/urandom of=./mntdir-KpMO/tmpfile.eSJR bs=44M count=1 0+1 records in 0+1 records out 33554431 bytes (34 MB) copied, 2.36667 s, 14.2 MB/s + umount ./mntdir-KpMO umount: ./mntdir-KpMO: not mounted This shows that (based on the way the script works) that a mount call succeeds, then a subsequent write succeeds as well and when umount is invoked it says that the location is not mounted, eventhough it is indeed mounted? What;s more is the fact that if I rerun the script umount works as expected? Is this some kind of racy behavior? Am I missing something? This is on kernel 4.2.6 Regards, Nikolay --------------070402090900070401010004 Content-Type: text/plain; charset=UTF-8; name="init_vg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="init_vg.txt" IyEvYmluL2Jhc2gKc2V0IC1lCgpmdW5jdGlvbiBnZXRfcmFuZG9tKCkgewoJbG9jYWwgbnVt YmVyPTAKCXdoaWxlIFsgIiRudW1iZXIiIC1sZSAyMCBdCglkbwoJICAJbnVtYmVyPSRSQU5E T00KCSAgICBsZXQgIm51bWJlciAlPSA1MCIgCglkb25lCgoJZWNobyAkbnVtYmVyCn0KCgkg ZmlsZT0kKG1rdGVtcCAtdSAtLXRtcGRpcj0uICB2Z2ZpbGUuWFhYWCkKCSBncm91cD0kKG1r dGVtcCAtdSB0ZXN0Z3JwLVhYWFgpCgkgdGhpbmdyb3VwPSQobWt0ZW1wIC11IHRoaW5ncnAt WFhYWCkKCSBtbnRwYXRoPSQobWt0ZW1wIC1kIC0tdG1wZGlyPS4gbW50ZGlyLVhYWFgpCgkg dm9sdW1lX25hbWU9JChta3RlbXAgLXUgdGVzdHZvbC1YWFhYKQoJIHZvbHVtZV9zaXplPTIw ME0KCSB0cnVuY2F0ZSAke2ZpbGV9IC0tc2l6ZSAxMEcKCSBsb29wZGV2PSQobG9zZXR1cCAt ZiAtLXNob3cgJHtmaWxlfSkKCSBwdmNyZWF0ZSAtLW1ldGFkYXRhc2l6ZSAxTSAke2xvb3Bk ZXZ9CgkgdmdjcmVhdGUgJHtncm91cH0gLXMgMU1pQiAke2xvb3BkZXZ9CgkgcGVfc2l6ZT0k KHZnZGlzcGxheSAiL2Rldi8ke2dyb3VwfSIgfCBncmVwICdQRSBTaXplJyB8IGF3ayAne3By aW50ICQzfScpCgkgdGhpbl9zaXplPSQoZWNobyAiJCh2Z2Rpc3BsYXkgIi9kZXYvJHtncm91 cH0iIHwgZ3JlcCAnRnJlZSAgUEUnIHwgYXdrICd7cHJpbnQgJDV9JykqJHtwZV9zaXplfS0x ODAiIHwgYmMgLWwpIAoJIGx2Y3JlYXRlIC0taWdub3JlYWN0aXZhdGlvbnNraXAgLVogbiAt TCAke3RoaW5fc2l6ZX1NIC1UICIvZGV2LyR7Z3JvdXB9LyR7dGhpbmdyb3VwfSIgCgkgbHZj cmVhdGUgLS1pZ25vcmVhY3RpdmF0aW9uc2tpcCAtViR7dm9sdW1lX3NpemV9IC1UICIke2dy b3VwfS8ke3RoaW5ncm91cH0iIC1uICIke3ZvbHVtZV9uYW1lfSIKCSBta2ZzLmV4dDQgL2Rl di8kZ3JvdXAvJHZvbHVtZV9uYW1lCgkgc3luYwoJIHZnY2hhbmdlIC1LYW4gJGdyb3VwCgkg bG9zZXR1cCAtZCAkbG9vcGRldgoKZWNobyAiVm9sdW1lIGNyZWF0ZWQsIGRvaW5nIHdvcmsi CmZvciBpIGluIHsxLi4xMH07IGRvIAoJZWNobyAiRG9pbmcgaXRlcmF0aW9uICRpIgoJbG9v cGRldj0kKGxvc2V0dXAgLWYgLS1zaG93ICR7ZmlsZX0pCgl2Z2NoYW5nZSAtS2F5ICRncm91 cAoJaWYgISBtb3VudCAvZGV2LyRncm91cC8kdm9sdW1lX25hbWUgJG1udHBhdGg7IHRoZW4g CgkJZWNobyAia29yIgoJCWV4aXQgMQoJZmkKCXJtIC1yZiAkbW50cGF0aC8qCglkZCBpZj0v ZGV2L3VyYW5kb20gb2Y9JG1udHBhdGgvJChta3RlbXAgLXUgdG1wZmlsZS5YWFhYKSBicz0k KGdldF9yYW5kb20pTSBjb3VudD0xCgl1bW91bnQgJG1udHBhdGgKCXZnY2hhbmdlIC1LYW4g JGdyb3VwCglsb3NldHVwIC1kICRsb29wZGV2Cgpkb25lCg== --------------070402090900070401010004--