Date: Mon, 2 Jun 2003 14:59:29 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: current@freebsd.org Subject: Re: 5.1-RELEASE TODO Message-ID: <20030602145929.57b21886.Alexander@Leidinger.net> In-Reply-To: <3EDB2268.2020508@newsguy.com> References: <200306011300.h51D0DMH042667@fledge.watson.org> <20030601165406.20550ba0.Alexander@Leidinger.net> <3EDA3BFA.1020602@btc.adaptec.com> <20030601201110.7b11a30c.Alexander@Leidinger.net> <3EDB2268.2020508@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 02 Jun 2003 07:09:44 -0300
"Daniel C. Sobral" <dcs@newsguy.com> wrote:
> > I hadn't any program running with legitimate access to /mnt and I have
> > no program running which accesses a random filesystem path, so no vnodes
> > should have been open then.
>
> Alas, lsof (ports) would be a better way of checking if there are vnodes
> open or not. I think fstat does that too, but I'm too used to lsof.
>
> Also, what is the error message?
It was EBUSY. The first time I thought: sure, there's something open on
it... with 3 xterms open where I use zsh as the shell it was easy to
hunt for a program which I may have suspended, but I wasn't able to find
one. Even "umount -f" wasn't able to umount the slice. As the disk was
used to transport some data I wasn't able to look further into this.
Now with a new kernel (from May 30) and another data transport on a
harddisk I'm not able to reproduce the problem (a May 25 kernel failed
to umount the slice).
Bye,
Alexander.
--
...and that is how we know the Earth to be banana-shaped.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030602145929.57b21886.Alexander>