Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Darwin disk I/O question

Stuart Smith wrote:

> true, the SCSI standard permits this, but most drives don't actually
> implement it, and the Darwin drivers don't make use of the feature.

Yes, well, perhaps if someone were to include a SCSI tape device, they
would find a reason to implement disconnect/reselect, and I think
CD's also suffer from the long latency times for 'simple' seeks.


> What you are looking for is often found in RAID drivers (which can use
> multiple ATA channels). While channel A is busy doing I/O with one chunk of
> data channel B can be kept busy with the next chunk.

Well, I should be clear, my typical driver target systems have not
been Mac OS... Hence my personal 'typical' requirement is to write
drivers which can do the 'simultaneous' transfers, all predicated
on some sort of disconnect/reselect, and I should add, SCSI based...
IDE/ATA, what's that...


> You're right, ATA doesn't understand 'reconnect', and by extension ATAPI
> doesn't either. (IDE is the electrical bus interface, it says nothing about
> communication protocol, ATA defines an ugly register-based communication
> protocol, and ATAPI defines how to crowbar a packet interface (which may
> carry SCSI commands) onto the ATA protocol.

I've recently heard about an 'ugly' set of ATA commands which are talked about
to prevent certain types of data from being written or read back without
a 'key'... but I digress...


> What I meant by single-threaded is that the Darwin drivers execute one
> command at a time per device. There is no overlapping and no reordering of
> requests. Depending on how the driver is implemented, a command in progress
> may block the workloop thread for the device's controller (thus preventing
> execution of commands for another device on that controller), or block a
> private thread for just that device.

Yes, well, using SCSI commands one is almost virtually unaware of the actual
underlying 'structure', just one long linear sequence of blocks. I don't think I've
'considered' sorting by block address in years... However, being aware of
various system implementations and paramenters, does assist in helping
'users' to understand why they don't get performance out the kazoo when
they have very fragmented files, or a file system which does not support
the concept of 'contiguous' allocation.

Hey, does HFS+ have such a concept... UFS has not had that as a required
element although some 'unix' providers have enhanced the filesystem management
to have such a capability. Typically this would be for data acquisition systems
which have a high data rate, but there is a desire to keep the file in a easily
accessable form by other programs or systems.

--
Copyright 2000, John Clark all rights reserved, in particular
permission for use in reference to any commercial product
is denied.
Copyright 2000, John Clark alle Rechte vorbehalten,
insbesondere kommerzieller Gebrauch ist nicht gestattet.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.