Re: CVS commit: src/sys/kern
Manuel Bouyer wrote: > In any case, adding a workaround for a specific setup which can potentially > cause spurious failures for everyone is not appropriate. I agree with that, but it is the case here? Running with vnd backends on the root partition is not what I would call a specific setup, and it is not obvious the change can do actual harm. I agree a EAGAIN on unmount(2) as shutdown time would be a problem, but can it happen? /etc/rc.d/mountall calls umount -a after all processes using the filesystem have exit. What process would call fstrans_start() while umount tries to do a file suspension? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: CVS commit: src/sys/kern
On Mon, Oct 01, 2018 at 07:43:05AM +, Emmanuel Dreyfus wrote: > On Mon, Oct 01, 2018 at 09:34:47AM +0200, Manuel Bouyer wrote: > > Yes, it's a bug, probably related to vndconfig'ing a file on the > > same filesystem as /dev. I use vnconfig a lot myself and I've never seen > > it. > > I think all you need is to have a domU with two block devices. On my I have such domUs, and never hit this problem. But the vnd files are on a separate partition In any case, adding a workaround for a specific setup which can potentially cause spurious failures for everyone is not appropriate. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/kern
On Mon, Oct 01, 2018 at 09:34:47AM +0200, Manuel Bouyer wrote: > Yes, it's a bug, probably related to vndconfig'ing a file on the > same filesystem as /dev. I use vnconfig a lot myself and I've never seen > it. I think all you need is to have a domU with two block devices. On my test machine I need to loop on xl create; sleep 60; xl shutdown -w to get it, while other systems I have it 100% reproductible. -- Emmanuel Dreyfus m...@netbsd.org
Re: CVS commit: src/sys/kern
On Mon, Oct 01, 2018 at 07:04:04AM +, Emmanuel Dreyfus wrote: > On Sun, Sep 30, 2018 at 11:13:11AM +0200, J. Hannken-Illjes wrote: > > This change is wrong, there is no upper time limit for a successfull > > file system suspension. > > Indeed, it can be infinite, as I experienced here: > http://mail-index.netbsd.org/tech-kern/2018/09/21/msg024099.html > > A umount, vndconfig or fssconfig failing with EAGAIN is indeed > bad, It's actually quite bad if it happens at shutdown time. > but I doubt you will advocate that freezing the whole system > forever is better. at the very last, the timeout should be much longer (at last several seconds) before deciding if it would hang forever. > I have machines where the above described > scenario became 100% reproductible with the NetBSD 8.0 upgrade, > this is just a shame. Yes, it's a bug, probably related to vndconfig'ing a file on the same filesystem as /dev. I use vnconfig a lot myself and I've never seen it. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/kern
On Sun, Sep 30, 2018 at 11:13:11AM +0200, J. Hannken-Illjes wrote: > This change is wrong, there is no upper time limit for a successfull > file system suspension. Indeed, it can be infinite, as I experienced here: http://mail-index.netbsd.org/tech-kern/2018/09/21/msg024099.html A umount, vndconfig or fssconfig failing with EAGAIN is indeed bad, but I doubt you will advocate that freezing the whole system forever is better. I have machines where the above described scenario became 100% reproductible with the NetBSD 8.0 upgrade, this is just a shame. I will be happy to see you revert my workaround and replace it by a more approriate fix. -- Emmanuel Dreyfus m...@netbsd.org
