Re: sbp2port.sys, IEEE 1394 port driver

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: David J. Craig (SeniorDriversWriter_at_shogunyoshimuni.com.net)
Date: 02/07/04 

Date: Sat, 7 Feb 2004 16:53:14 -0500

Comments inline:

"Phil Barila" <PBarila@Barila.com> wrote in message
news:ScqdnUMxaqY7Br3dRVn-ug@4dv.net...
> "David J. Craig" <SeniorDriversWriter@shogunyoshimuni.com.net> wrote
in
> message news:%23ELZ$LF6DHA.2472@TK2MSFTNGP10.phx.gbl...
> > You are correct as to the old IDE_PASS_THROUGH interface being the
only
> > one available at the time, except SCSI_PASS_THROUGH. Yes, I know
that
> > almost all IDE/ATA devices are 512 bytes, but CDs and DVDs are not
and
> > those sectors are not a modulo of 512 either in raw mode or on
non-mode1
> > media. However, there is a major manufacturer of CompactFlash that
has
> > a special sector that is accessed via a vendor unique command as
allowed
> > by the ATAPI spec. It contains 512 + 16 bytes, where the 16 byte
part
> > contain configuration information for the embedded controller in the
> > media. There is a hardware device that connects to the ATA cable
that
> > permits CompactFlash to be used on that bus. The only way I know of
to
> > access those bytes, read and write, is via DOS where the IDE ports
can
> > be accessed directly. I do not know if that 'feature' of the
> > CompactFlash media is common to media from other manufacturers, but
it
> > is for that one. The application was for using XP embedded where
the OS
> > boots from the CF. I know a vendor ATA miniport driver could make
this
> > work, but it wasn't possible in a no-reboot environment.
>
> Where did you see in the ATA spec that you can use ATAPI transfers for
ATA
> devices, which CFA devices are? ATAPI is, sort of, SCSI over the ATA
wires.
> CFA is sector-based ATA, with some limitations. Your customer's
device was
> just non-compliant.
>
CompactFlash does have some interesting things going on, but there has
to be a way to permit some behaviors to be modified. Some of the
controls available can be used to inhibit or permit certain power
states. The commands are vendor commands and should be allowed to be
non-mod 512 sizes. I think the manufacturer should consider the various
operating systems, but many of these devices were developed for non-PC
environments first. SmartMedia was invented for cameras first and later
on computer usage became common. If I could get the CIS from the
SmartMedia, I can detect the real size of the media.

Microsoft has attempted to force all media to have a CHS where the heads
are always 255 and the sectors per track are 63. This can cause size
information from the DISK GEOMETRY request to be off by up to 8MB. I
discovered a way to get around that problem that will work under 2000
also, but it was a pain. I do have a nice format utility almost
finished that can format SmartMedia correctly as the SSFDC requires.
The primary reason for the special format is that it keeps each cluster
from being spread across multiple physical blocks. If this is not
followed, flash memory will wear out much more quickly as each flash
block can only be erased and written so many times before it fails. The
total number of erase/write cycles is much better than when the first
Intel flash memory devices were invented, but it is still much more
limited compared to the 'rust' in a hard drive.

Just like with Seagate the actual low level details of how each drive is
formatted and what vendor commands exist are not released to all but a
select few. There have been some discussions lately on some of these
newsgroups about how each vendor of USB or 1394 to ATAPI bridge chips
must include special command translations that permit more control than
the simple read, write, verify, etc. normally used if special features
are needed. Cache control, bad block info, etc. are some that come to
mind. Even a more complete inquiry that permits access to all the pages
would be nice, but they are not documented. Try getting the
manufacturer's name and model number of some hard drives in a USB 2.0
external box. Not easy and frequently not possible. I have not
completed the format program because I don't have a 1394 drive available
to check basic functionality.

> > I know you have to know that sooner or later hard drives will have
to
> > have larger physical sectors on the media to increase capacity. The
> > overhead for 512 byte sectors is rather large and with the current
state
> > of error correcting hardware/firmware in today's drives, this
decreases
> > the total capacity of the 'rust' based media too much. Just as
> > Microsoft had a special format for 1.44MB floppy media that actually
> > allowed about 1.8MB to be stored just by increasing the number of
> > sectors per track. Early floppy drives didn't have the tolerances
to
> > write and read that much data reliably, but the floppy is almost
dead as
> > a useful storage device. If Microsoft had their way, it would be
deader
> > than a doornail, but do seem to tolerate the USB floppy since it
fixes
> > some of the deficiencies - slightly faster, PnP, and media arrival
> > capability. Too bad that USB is always a slave at the device level
so
> > it takes constant polling to detect the state changes. SCSI's
multiple
> > initiator is so nice - why couldn't 1394 and USB be designed that
way?
>
> Yes, T13 is talking about that now. I don't know why those bus be the
way
> they be, ask the folks that designed them. USB was designed to be
cheap and
> require the host CPU to burn cycles managing it. Not sure what the
1394
> design goals were, but evidently it wasn't to provide a complete SCSI
> implementation over serial wires.
>
> > So, to get to the point, if I can keep to it, as more and more
devices
> > are designed to provide some form of mass storage on these busses
> > non-mod 512 data transfers should be accommodated. I have a SanDisk
> > CF/SM dual media reader on USB 1.1 where I cannot access the
> > SmartMedia's CIS blocks nor the 16 byte redundant data area. Some
of
> > that is due to restrictions designed into the reader's firmware, but
> > some of those restrictions are probably (possibly) there because of
> > limitations in the Windows storage stacks. If sectors could be made
> > 64KB in size, what would the capacity of a 160GB hard drive become?
The
> > control and other space surrounding the data is a significant amount
of
> > overhead.
>
> 160 GB? The limitation isn't in the LBA space, it's in the areal
density.
> Making larger sectors doesn't provide any increase in areal density,
it just
> reduces the number of LBAs. Do you really want the minimum FS
allocation
> unit to be 64K? To be fair, an FS could do more work to subdivide the
disk
> native sector size into smaller units, but who want's the over head of
a 64K
> RMW to write your 10 byte batch file?
>
What is the total number of bytes available on a 160GB drive including
all servo data that can be reduced by using larger sectors? I think
64KB sectors would have some use, especially in specialized storage
drives. If you use Ghost to backup a standard drive, all the files
created are 2GB in size except for the last one. Also MP3 files are
larger than 64KB as they run about 3 to 7 MB per file. The larger
sector size would not impact the effective storage size of the drive.
Also, if you use FAT32 for large drives less than 32GB the cluster size
is 16KB and larger than 32GB creates 32KB clusters. Doubling the size
would have an impact, but maybe the extra space obtained would still
allow the same amount of data to be stored, except for uses where many
of the files are very small. I have noticed that lots of small files
are considerably more rare than before. Maybe you wouldn't want the
system drive to have 64KB sectors, but many others might work.

I do remember that in the past a data sector of 512 bytes also had the
CHS info, IDs, etc. including extra bytes after the sector to keep the
write to that sector from writing over the control information for the
next sector. On a floppy it is a significant penalty and during MFM
days it was significant there too. Maybe with the ID areas only being
written during the manufacturing process, some of the extra bytes have
already been reduced.

> Phil
> --
> Philip D. Barila Windows DDK MVP
> Seagate Technology, LLC
> (720) 684-1842
> As if I need to say it: Not speaking for Seagate.
> E-mail address is pointed at a domain squatter. Use reply-to instead.
>
>

Relevant Pages

  • Re: Poor raid 1 performance?
    ... and while sequential reading you should wait while ... >> other half to the other one, resulting in both drives reading ... > And since the media have been written sequentially (I assume it, ... You need to get rid of that even/odd numbered sectors fascination and start ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: Are Floppy Drives A Necessity On Laptops?
    ... The drives have 77 tracks on either one or two sides, in either single or double density, so at that level you have 4 combinations giving different numbers of tracks per diskette. ... the standard was 26 sectors per track of 128 bytes per sector. ... You can find sealed boxes of 8" diskettes on E-Bay for about $10, and while it's old media 930 years at this point), it almost all still works, I still have 5 systems here ...
    (comp.sys.laptops)
  • Re: Event ID 11 - please help
    ... a ton of drives. ... > two more SATA WD 120 GB drives connected to the Promise controller ... > Offset Length Sectors ... > Type Indicator Partition Partition ...
    (microsoft.public.windowsxp.hardware)
  • Re: sbp2port.sys, IEEE 1394 port driver
    ... media. ... I know you have to know that sooner or later hard drives will have to ... have larger physical sectors on the media to increase capacity. ... > That said, you are right, only the port driver writer knows for sure. ...
    (microsoft.public.development.device.drivers)
  • Re: Hard Disk Failure
    ... Does the HDD's OEM diagnostic tool see the full size of the HDD, ... Do you see anything in Disk Management that relates to the 160GB HDD, ... tool on the drives and this is the result. ... Sectors per Cluster: 8 ...
    (microsoft.public.windowsxp.hardware)