on 13/11/2010 13:21 Kostik Belousov said the following:
> On Sat, Nov 13, 2010 at 01:09:55PM +0200, Andriy Gapon wrote:
>> on 13/11/2010 13:06 Martin Matuska said the following:
>>> No, this is not good for us. Solaris does not allow "mounting" of
>>> snapshots on any vnode, like we do. Solaris has
On Sat, Nov 13, 2010 at 01:09:55PM +0200, Andriy Gapon wrote:
> on 13/11/2010 13:06 Martin Matuska said the following:
> > No, this is not good for us. Solaris does not allow "mounting" of
> > snapshots on any vnode, like we do. Solaris has them only in
> > .zfs/snapshots. This allows us to have re
on 13/11/2010 13:06 Martin Matuska said the following:
> No, this is not good for us. Solaris does not allow "mounting" of
> snapshots on any vnode, like we do. Solaris has them only in
> .zfs/snapshots. This allows us to have read-only mounts without even
> mounting the parent zfs.
>
> Before v15
No, this is not good for us. Solaris does not allow "mounting" of
snapshots on any vnode, like we do. Solaris has them only in
.zfs/snapshots. This allows us to have read-only mounts without even
mounting the parent zfs.
Before v15 we have been happy with that code and had no issues :-)
I have a
on 13/11/2010 04:27 Martin Matuska said the following:
> 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 t...@t1 /mnt
> # umount /mnt (-> hang)
>
> http://bugs.opensolaris.org/bugdatabase/view_b
> 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 t...@t1 /mnt
> # umount /mnt (-> hang)
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992
> http://bugs.opensolaris.org/bugd
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 t...@t1 /mnt
# umount /mnt (-> hang)
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992
http://bugs.opensolaris.org/bugdatabase/view_bug
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
>>> PIDTID COMM TDNAME
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
> > PIDTID COMM TDNAME CPU PRI
> STATE WCHAN
> > 958 100731 umount
on 12/11/2010 13:57 Alexander Zagrebin said the following:
> 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
> PIDTID COMM TDNAME CPU PRI STATE WCHAN
> 958 1
I have found that there is an issue with unmounting ZFS snapshots:
the /sbin/umount "hangs" after unmounting.
The test system is i386, but I can reproduce this issue on amd64 too.
# uname -a
FreeBSD alpha.vosz.local 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Oct 19
18:47:05 MSD 2010 r...@alpha.vos
11 matches
Mail list logo
