Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL

[Antti Kantee <pooka%cs.hut.fi@localhost>]

The following reply was made to PR kern/41189; it has been noted by GNATS.

From: Antti Kantee <pooka%cs.hut.fi@localhost>
To: YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost>
Cc: ad%netbsd.org@localhost, dholland-bugs%netbsd.org@localhost, 
tech-kern%netbsd.org@localhost,
        gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
Date: Sun, 10 May 2009 08:53:10 +0300

 On Sun May 10 2009 at 05:41:55 +0000, YAMAMOTO Takashi wrote:
 > hi,
 > 
 > > I should have been clearer. Have a look at the bigger picture.
 > > 
 > > - 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).
 > 
 > i don't think devfs is necessary here.
 > just giving up updating timestamps of mounted VBLK special files is enough.
 > 
 > > - 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.
 > 
 > are there applications of the misaligned transfers?
 
 iirc ntfs-3g does misaligned transfers and works only on block devices.
 IMHO it should be fixed (and probably not very hard).
 
 but there's the more general problem that we do not currently provide
 any good unbuffered method for a userspace process to access a raw disk
 device.  I would like to be able to say either "block until written" or
 "put this in the *device driver* queue and return immediately after the
 request is queued".  it might be solved with better aio, but we don't
 currently have it.
 
 (i don't see the relevance of devfs here either)