Subject: Re: CVS commit: src/sys
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 11/15/2006 01:45:49
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


On Wed, Nov 15, 2006 at 08:29:58AM +0900, YAMAMOTO Takashi wrote:
> > On Wed, Nov 15, 2006 at 07:14:00AM +0900, YAMAMOTO Takashi wrote:
> > > > Modified Files:
> > > > 	src/sys/kern: vfs_bio.c
> > > > 	src/sys/sys: buf.h
> > > > 
> > > > Log Message:
> > > > Export nestiobuf_iodone(). This allows nested iobufs to have a custom
> > > > call-back function that can then call the nestiobuf_iodone() to propagate.
> > > > 
> > > can you explain why you want this?
> > 
> > Sure! Its to enable nested buffers to be queued and have their status 
> > monitored. Esp. on aynchronous writes its pleasant to know if a write did 
> > succeed or not and get a notification on for various reasons; if only for 
> > queueing or syncing notification.
> 
> i want to know an example of "various reasons".
> i guess you did this for a particular reason, right?

sure thing. I'm currently working out an system for UDF that needs 
enqueueing all read and write requests and shedule them at file system 
level.

I've thought about adding a generic sheduling dicipline but that would mean 
breaking abstraction layers since call backs are then needed. UDF needs at 
least 4 sheduling states: reading, sequential writing, normal writing and 
block read-modify-write-ing.

Especially sequential writing is troublesome since blocks need to be 
pre-processed before they can be written. File or directory nodes need to 
record a logical number so they are ok but directory-stream data i.e. a 
series of dirent's effectively need to have their *physical* sector number 
recorded in them... Not my idea but otherwise its breaking the spec and the 
discs might and are known to be rejected by other implementations.

Since CD-R and DVD*R too is basicly physically formatted as error 
correcting chunks of 32 or 16 sectors, switching from writing to reading 
and back will mean that when switching to reading the chunk will have to 
written out completely meaning a few visible (!) sector numbers will be 
lost and not addressable. If one has carefully numbered out and allocated 
the stream to be `just right' an unexpected switch to reading is desastrous 
for all will be wrong. Where it comes to is that a CD-R has defacto only 
has ONE write-point/sectornumber available for writing and that sector 
number increases. Writing any other sectornumber will be rejected by the 
device. Its far more rigid that tape in that sense.

Some devices claim to be `BURNFREE' or have options alike that try to fix 
that basic problem but they are focused on stalling problems, not on this 
error-correcting chunk problem.

At the very least it looks like i need a callback for each buffer 
asyncronously written out/read in to be able to determine if all reads or 
writes are done before i switch modes.

With regards,
Reinoud


--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iQEVAwUBRVpjNoKcNwBDyKpoAQLxxgf+O7gezImKPKzmVtkYVeJRz1qNuJ+PbAza
RmdyKmOCA50jATNLvag8Mt3ilfYbXI784TBFkF+hQpEbaIRbll+IBFZIASGBmFZ6
jmHhv5HrWqeR70l0DqAqQII/OKozpt9K81AyHmiXba8VJLMAxSPz8SYwyLXp2co6
jpuhgqwi3JmO2lYUGfIFIs9aT4MTNKTHVbKFnv8oqbQlceCiBZBGv8oxNk7UDU/a
dFmCz/6DVBsQ1VY5ov32wR+IQRNKuArZ+WlqGtUox6Nz8YUkPY7KRWFmWIuWq/mQ
mgYhOOBbeCS6AYtWAeTU1bV2yFX6OEzuIwWe9RsM7i5cvkAHULPt8A==
=W0Vp
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--