Re: fsync: giving up on dirty, umount -f fails

> From: "Bjoern A. Zeeb" <bzeeb-lists_at_lists.zabbadoz.net>
> To: "FreeBSD Current" <freebsd-current_at_freebsd.org>
> Subject: fsync: giving up on dirty, umount -f fails
> Date: Thu, 24 Oct 2019 07:58:39 +0000
> 
> 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 
> “disks dropping out by error” and not to panic I was just wondering 
> if this is something to address as well?   Somehow umount -f should be 
> able to succeed (in the future)?
> 
> 
> fsync: giving up on dirty (error = 5) 
> g_vfs_done():da0s2g[READ(offset=4666441728, length=16384)]error = 5
> 0xfffff803533b81e0: tag devfs, type VCHR
>      usecount 1, writecount 0, refcount 1661 rdev 0xfffff8015372a800
>      flags (VI_ACTIVE)
>      v_object 0xfffff80365537c00 ref 0 pages 8340 cleanbuf 1561 dirtybuf 97
>      lock type devfs: EXCL by thread 0xfffff80006a57000 (pid 26526, 
>      umount, tid 100091)
>          dev da0s2g
> 
> /bz

In the above example the unmount is failing because it is getting
back EIO for one of its dirty buffers. Thus it is not able to get
everything written out, so refuses to do the unmount.

What we are working on doing is implementing a `very forcible'
unmount (which I would love to specify using `umount -F', but
regretably -F is already in use to specify an alternate fstab file).
A very forcible unmount says to simply abandon dirty buffers that
it cannot write.  In the event of a disk dying, that would be all
of the dirty buffers.

	Kirk McKusick