> From: "Bjoern A. Zeeb"
> To: "FreeBSD Current"
> Subject: fsync: giving up on dirty, umount -f fails
> Date: Thu, 24 Oct 2019 07:58:39 +
>
> Hi,
>
> I am archiving some old disks and while trying to umount [-f] them I am
> getting err
Hi,
I am archiving some old disks and while trying to umount [-f] them I am
getting errors and I basically cannot get rid of the mount anymore
without rebooting. This is on a HEAD from mid-end-August (around
r351518M).
Given there is a lot of work going on at the moment to deal with
D $FS@$NEW |ssh $HOST zfs recv -uF $FILESYSTEM
On the receiving server, we forcibly unmount the filesystem which is
being received into with:
zfs umount -f $FILESYSTEM
(the filesystem may or may not actually be mounted)
This causes any ZFS file operation (such as "ls
On Wed, Nov 08, 2000 at 07:43:24AM -0700, Warner Losh scribbled:
| In message <[EMAIL PROTECTED]> Johan Karlsson writes:
| : At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote:
| : > In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
| : > : Yes, this used to work quite well for some time, I
On Wed, Nov 08, 2000 at 07:43:24AM -0700, Warner Losh wrote:
> It is a problem that I could have sworn worked before SMPNG.
Negative, this occurs on releng_4 machines for me as well.
It also was occuring on my -current workstation that was about 110 days
old before a disk went out, so it was def
In message <[EMAIL PROTECTED]> Johan Karlsson writes:
: At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote:
: > In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: > : Yes, this used to work quite well for some time, I have no idea
: > : who broke it. Maybe you can sprinkle some printfs in
At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
> : Yes, this used to work quite well for some time, I have no idea
> : who broke it. Maybe you can sprinkle some printfs in the code and
> : narrow it down a bit?
>
> I'll give it a sh
In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: Yes, this used to work quite well for some time, I have no idea
: who broke it. Maybe you can sprinkle some printfs in the code and
: narrow it down a bit?
I'll give it a shot. I'm glad to see it is a "should work but is
busted" rather t
* Warner Losh <[EMAIL PROTECTED]> [001107 13:14] wrote:
> In message <[EMAIL PROTECTED]> Bill Fumerola writes:
> : On Tue, Nov 07, 2000 at 01:13:41PM -0700, Warner Losh wrote:
> :
> : > I just tried to umount -f /home, where /home was an NFS mounted file
> : >
In message <[EMAIL PROTECTED]> Bill Fumerola writes:
: On Tue, Nov 07, 2000 at 01:13:41PM -0700, Warner Losh wrote:
:
: > I just tried to umount -f /home, where /home was an NFS mounted file
: > system on a network that was no longer attached to my laptop. In the
: > past this
On Tue, Nov 07, 2000 at 01:13:41PM -0700, Warner Losh wrote:
> I just tried to umount -f /home, where /home was an NFS mounted file
> system on a network that was no longer attached to my laptop. In the
> past this has just worked, even if processes were hung in disk wait
> state.
I just tried to umount -f /home, where /home was an NFS mounted file
system on a network that was no longer attached to my laptop. In the
past this has just worked, even if processes were hung in disk wait
state. When I tried it last night on an Oct 29th kernel, I got EBUSY
and the file system
On Thu, Feb 11, 1999 at 08:24:52AM -0500, Mikhail Teterin
wrote:
> =Do you have "hard" mount or "soft" mount? I have seen such behavior
> =for "hard" mounts.
>
> Soft. But it should not matter, should it?
I don't know, I'm not a expert to say for sure. Only know that about
two months ago I tr
Vallo Kallaste once stated:
=On Wed, Feb 10, 1999 at 01:54:53PM -0500, Mikhail Teterin
wrote:
=
=> Nope:
=>
=> m...@xxx:/tmp (1044) umount -f -t nfs phosphorus:/phosphorus
=> umount: /phosphorus: Device busy
=>
=> It is not, that umount hangs, it is that it care
On Wed, Feb 10, 1999 at 01:54:53PM -0500, Mikhail Teterin
wrote:
> Nope:
>
> m...@xxx:/tmp (1044) umount -f -t nfs phosphorus:/phosphorus
> umount: /phosphorus: Device busy
>
> It is not, that umount hangs, it is that it cares about the device being
> busy des
>> > Will it ever work as it appears it should? Currently I have (on 2.2.8)
>> >From an email from Peter Wemm:
>>
>> In this situation, you need to do this:
>> umount -f -t nfs phosphorus:/phosphorus
>>
>> This causes umount to stat("
> Just to ask, have you run lsof on /phosphorus to see if it is,
> indeed, busy?
lsof is unable to stat /phosphorus, of course. But, in any case,
this should not be relevant, because the `-f' is specified...
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd
> > Will it ever work as it appears it should? Currently I have (on 2.2.8)
> >
> > m...@xxx:/tmp (1032) umount -f phosphorus:/phosphorus
> > umount: /phosphorus: Device busy
>
> >From an email from Peter Wemm:
>
> In this situation, you
> Will it ever work as it appears it should? Currently I have (on 2.2.8)
>
> m...@xxx:/tmp (1032) umount -f phosphorus:/phosphorus
> umount: /phosphorus: Device busy
>From an email from Peter Wemm:
In this situation, you need to do this:
umount -f -t
Will it ever work as it appears it should? Currently I have (on 2.2.8)
m...@xxx:/tmp (1032) umount -f phosphorus:/phosphorus
umount: /phosphorus: Device busy
This is because phosphorus is unreachable and is unlikely to ever
become reachable again. Currently, a reboot is
20 matches
Mail list logo
