Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Nov 2010 03:27:07 +0100
From:      Martin Matuska <mm@FreeBSD.org>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        freebsd-fs@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: 8.1-STABLE: problem with unmounting ZFS snapshots
Message-ID:  <4CDDF77B.90708@FreeBSD.org>
In-Reply-To: <4CDD4EB4.40004@freebsd.org>
References:  <D9ABDE54892A4D9285FE7FFA6E1B1B69@vosz.local>	<4CDD2F5F.2000902@freebsd.org>	<FD7FC6ED159249338A04BE125941D146@vosz.local> <4CDD4EB4.40004@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Yes, this is indeed a leak introduced by importing onnv revision 9214
and it exists in perforce as well - very easy to reproduce.

# mount -t zfs test@t1 /mnt
# umount /mnt (-> hang)

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367

This is not compatible with mounting snapshots outside mounted ZFS and I
was not able to reproduce the errors defined in 6604992 and 6810367
(they are Solaris-specific). I suggest we comment out this code (from
head, later MFC and p4 as well).

Patch (should work with HEAD and 8-STABLE):
http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch

Dňa 12.11.2010 15:27, Andriy Gapon  wrote / napísal(a):
> on 12/11/2010 16:00 Alexander Zagrebin said the following:
>> Thanks for your reply!
>>
>>>> 2. the umount is waiting for disk
>>>> #ps | egrep 'PID|umount'
>>>>   PID  TT  STAT      TIME COMMAND
>>>>   958   0  D+     0:00,04 umount /mnt
>>>> # procstat -t 958
>>>>   PID    TID COMM             TDNAME           CPU  PRI 
>>> STATE   WCHAN
>>>>   958 100731 umount           -                  3  133 
>>> sleep   mntref
>>>
>>> procstat -kk <pid>
>>
>> $ ps a | grep umount
>> 86874   2- D      0:00,06 umount /mnt
>> 90433   3  S+     0:00,01 grep umount
>>
>> $ sudo procstat -kk 86874
>>   PID    TID COMM             TDNAME           KSTACK
>> 86874 100731 umount           -                mi_switch+0x176
>> sleepq_wait+0x42 _sleep+0x317 vfs_mount_destroy+0x5a dounmount+0x4d4
>> unmount+0x38b syscall+0x1cf Xfast_syscall+0xe2
>>
> 
> 
> Looks like possible mnt_ref leak.
> I think that something like that was fixed some not long time ago.
> Perhaps you either don't have the fix or there is another leak.
> What revision do you have?
> 
> Perhaps Martin has an insight here.
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CDDF77B.90708>