Prev: [PATCH] Staging: asus_oled: fix spaces and TAB coding style issue in asus_oled.c
Next: [PATCH 0/2] exec: refactor how call_usermodehelper works, and update the sense of the core_pipe recursion check (v4 rediff)
From: Francis Moreau on 15 Mar 2010 08:10 On Sun, Mar 14, 2010 at 5:21 PM, Robert Hancock <hancockrwd(a)gmail.com> wrote: > On 03/13/2010 02:56 AM, Francis Moreau wrote: >> >> Hello >> >> I've some shell scripts which try to find out the filesystem hosted by >> a block device. >> >> They basically do this: >> >> � � mount /dev/sdc1 /mnt >> � � fs=$(stat -f -c %T $mount_point) >> � � umount /mnt >> >> It happens to work but since an unknown upgrade (kernel, libs or tools >> upgrade), umount(8) returns -EBUSY. >> >> I found that it's actually the sys_umount() which return -EBUSY. >> >> So the question, is this expected or is this a regression ? >> >> If it's expected then which operation should I add between the >> mount(8) and umount(8) to make the mount operation completely finish >> (inside the kernel) so the next umount won't return -EBUSY ? > > If no other process were involved I would say it's likely a bug. However, my > guess is that some other process (HAL, something in GNOME, etc.) detects the > mount and decides to start accessing the drive. Then when you immediately > try to unmount, it fails because it's busy. I suspect if you try this in > single-user mode with no unnecessary processes running you won't see this. > You're right, I don't see this anymore if I'm booting in a single user mode. So I need to find out how to wait until these other processes stop accessing the drive. Thanks -- Francis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |