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

2019-10-24 Thread Kirk McKusick
> 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 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
> 0xf803533b81e0: tag devfs, type VCHR
>  usecount 1, writecount 0, refcount 1661 rdev 0xf8015372a800
>  flags (VI_ACTIVE)
>  v_object 0xf80365537c00 ref 0 pages 8340 cleanbuf 1561 dirtybuf 97
>  lock type devfs: EXCL by thread 0xf80006a57000 (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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


fsync: giving up on dirty, umount -f fails

2019-10-24 Thread Bjoern A. Zeeb

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

0xf803533b81e0: tag devfs, type VCHR
usecount 1, writecount 0, refcount 1661 rdev 0xf8015372a800
flags (VI_ACTIVE)
v_object 0xf80365537c00 ref 0 pages 8340 cleanbuf 1561 dirtybuf 
97
lock type devfs: EXCL by thread 0xf80006a57000 (pid 26526, 
umount, tid 100091)

dev da0s2g


/bz
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"