sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Francis Moreau]

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 ?

Oh I'm currently using the kernel shipped with F12: 2.6.32.9-67.fc12.x86_64

Thanks
-- 
Francis

sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Francis Moreau]

[resending to fs-devel mailing list hoping to get some hints]

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 ?

Oh I'm currently using the kernel shipped with F12: 2.6.32.9-67.fc12.x86_64

Thanks
--
Francis



-- 
Francis
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Andreas Dilger]

On 2010-03-13, at 13:30, Francis Moreau wrote:
> 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

Mounting an in-use filesystem is a bad idea.

You should just use the blkid tool, which wa written specifically for  
this purpose.  It was previously part of e2fsprogs (installed on 99%  
of systems) and in the future (possibly even FC12) it has moved over  
to util-linux (on 100% of systems).

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Al Viro]

On Mon, Mar 15, 2010 at 10:04:46AM -0600, Andreas Dilger wrote:
> On 2010-03-13, at 13:30, Francis Moreau wrote:
> >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
> 
> Mounting an in-use filesystem is a bad idea.

Huh?  mount() will happily create another vfsmount refering to the same
superblock in that case.  It *is* OK to mount the same block device twice;
any fs that uses get_sb_bdev() will DTRT.

It should be safe.  The lack of error checking after mount, OTOH, is not.

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Francis Moreau]

On Mon, Mar 15, 2010 at 5:34 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, Mar 15, 2010 at 10:04:46AM -0600, Andreas Dilger wrote:
>> On 2010-03-13, at 13:30, Francis Moreau wrote:
>> >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
>>
>> Mounting an in-use filesystem is a bad idea.
>
> Huh?  mount() will happily create another vfsmount refering to the same
> superblock in that case.  It *is* OK to mount the same block device twice;
> any fs that uses get_sb_bdev() will DTRT.
>
> It should be safe.  The lack of error checking after mount, OTOH, is not.
>

Well I omitted the error checking since it was not revelant in my
case: umount(8) fails but not mount(8).

-- 
Francis
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Ian Kent]

On Mon, 2010-03-15 at 16:34 +0000, Al Viro wrote:
> On Mon, Mar 15, 2010 at 10:04:46AM -0600, Andreas Dilger wrote:
> > On 2010-03-13, at 13:30, Francis Moreau wrote:
> > >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
> > 
> > Mounting an in-use filesystem is a bad idea.
> 
> Huh?  mount() will happily create another vfsmount refering to the same
> superblock in that case.  It *is* OK to mount the same block device twice;
> any fs that uses get_sb_bdev() will DTRT.
> 
> It should be safe.  The lack of error checking after mount, OTOH, is not.

I started seeing similar behavior in autofs after the pnode patches went
in. I was never able to decide if I was doing something wrong or if
there had been some latency in reducing reference counts introduced.
Also, I couldn't see anything in the kernel code that that even looked
like it would cause this so I didn't see any use in reporting it.
Instead I began using a retry loop with a short delay when umounting
mounts.

Ian

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Francis Moreau]

On Mon, Mar 15, 2010 at 5:04 PM, Andreas Dilger <adilger@sun.com> wrote:
> On 2010-03-13, at 13:30, Francis Moreau wrote:
>>
>> 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
>
> Mounting an in-use filesystem is a bad idea.

But it's not: /dev/sdc1 is not mounted anywhere before executing the script.

Someone else pointed out that some other processes (such as hal, gnome
stuff...) may have detected the new mount point and started to access
it hence preventing umount(8) to work.

-- 
Francis
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Robert Hancock]

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.

>
> Oh I'm currently using the kernel shipped with F12: 2.6.32.9-67.fc12.x86_64
>
> Thanks

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Francis Moreau]

On Sun, Mar 14, 2010 at 5:21 PM, Robert Hancock <hancockrwd@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

Re: sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"

[Petr Uzel]

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

On Mon, Mar 15, 2010 at 01:09:30PM +0100, Francis Moreau wrote:
> On Sun, Mar 14, 2010 at 5:21 PM, Robert Hancock <hancockrwd@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.
> >

I have experienced something similar when I did addpart, immediately
followed by delpart. The delpart command failed with EBUSY, because
the first command triggered some hal subprocess that accessed the
device.

> You're right, I don't see this anymore if I'm booting in a single user mode.

You can try to put 'lsof /dev/sdc1' between mount and umount to see
what (if anything) is accessing the device.

> 
> So I need to find out how to wait until these other processes stop
> accessing the drive.

If it is hal what causes EBUSY, you could 'killall -SIGSTOP haldaemon'
before mount and SIGCONT after umount.


Petr

--
Petr Uzel, openSUSE Boosters Team
IRC: ptr_uzl @ freenode

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]