[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
The following reply was made to PR kern/41189; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
Date: Sun, 13 Sep 2009 18:37:07 +0000
On Sat, May 09, 2009 at 07:35:01AM +0000, Andrew Doran wrote:
>>> I disagree. I think the solution is:
>>> - devfs
>>> - kill block devices in userspace
>>> - allow unaligned I/O to disk devices via the raw node
>> How/why? As I've already explained once (mostly quoted above), devfs
>> will not solve the real problem, just move it around. What are you
>> envisioning that devfs will provide that will avoid the confusion?
>> Please *explain* your reasoning.
> I should have been clearer. Have a look at the bigger picture.
Thank you, but four months later I still don't understand.
> - We have longstanding problems with device nodes showing up in
> multiple file systems. For 6.0 we have devfs coming along, which
> will at some point in its development likely eliminate the need
> to support device nodes on other file systems. So devfs will
> give us a 1:1 mapping between device instances and vnodes (or
> maybe devfs inodes).
More likely the latter, but even assuming all this happens, it won't
solve the problem. We'll end up with devfs ops being called on
arbitrary non-devfs vnodes, same as the previous round of problems
gave us wapbl ops being called on arbitrary non-wapbl vnodes, and
before that we had softupdate ops being called on non-softupdate
vnodes, and so on ad infinitum.
The problem is that as things stand, the device vnode half belongs to
the FS it came from and half to the FS that's mounted on it. The
dividing line isn't clear (I'm not entirely convinced it's even well
defined) and therefore it's easy for mistakes to arise. When mistakes
arise, the consequence is often calling the wrong vnode ops. There are
probably cases where the consequence is more subtle than that, too.
This is a structural problem, and to really make it go away for real
it needs to be solved structurally.
The device vnode should belong only to the FS it came from, whether
that's devfs or wapbl or whatever.
> - We have longstanding problems providing block device semantics. Block
> devices are an interesting toy but they have no real application. Disk
> character devices suffice with one exception: on NetBSD, transfers on
> these devices must be aligned. So there is no need for physio to cache,
> it could simply buffer to allow misaligned transfers.
This I have no disagreement with; it's just not relevant to what I'm
David A. Holland
Main Index |
Thread Index |