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--