Hello,

We are chip vender for the IDE/ATA storagebox that is connected to 1394 (Firewire).

Microsoft's generic 1394 port driver(sbp2port.sys) translates SRBs from DISK CLASS driver into SBP-2 commands which are issued to the underlying IEEE 1394 driver stack. So, we are able to read/write/format etc.

My question is,
1. How can we send the vender specific ATA SMART commands from our management applicaction through the above mentioned driver stack?

2. Is the IEEE 1394 prot driver (sbp2prot.sys) also provides pass through support something similar to ATA_PASS_THROUGH provided by atapi.sys?

Please help,

Thanks in advance,
Shakeel

This is a good question. For USB 2.0 and earlier, the answer is that
the only ones who know if it can be done have source code for those port
drivers. My suspicion is that 1394 might be the same. There has been
an attempt with ATA_PASS_THROUGH to permit some commands, but the
support is still inadequate if what I have seen in these newsgroups is
true. There are some ATA devices, specifically a CompactFlash adapter
that connects to the hard drive cable, that requires vendor commands
that are not multiples of 512 bytes. I have heard, but not tested since
I don't have access to the hardware anymore, that even the new ATA does
not support this. Use DOS and ding the ports yourself.

"shak" <kpf@netcell.com> wrote in message
news:4CC135D3-ACB4-44E2-8132-E813F47A786F@microsoft.com...
underlying IEEE 1394 driver stack. So, we are able to read/write/format
etc.
atapi.sys?

"David J. Craig" <SeniorDriversWriter@shogunyoshimuni.com.net> wrote in
message news:ud41GU25DHA.2432@TK2MSFTNGP10.phx.gbl...
If I remember right, you were trying to use the undocumented
IDE_PASS_THROUGH interface, and found a lot of limitations, such as the fact
that it didn't do writes well. One thing you might not be considering, as
of now, there is only one size of ATA sectors, and that's 512 bytes. The
whole interface is wrapped around that. In fact, with the exception of DMA
and Multi-Sector commands, every defined command that returns data has to
return it in integer multiples of 512 bytes, the device is supposed to
interrupt after each sector transferred. So it's not unreasonable for the
driver to limit the ATA_PASS_THROUGH interface to that size. If you were
going to do that device yourself, you could work around that issue by moving
two sectors.

That said, you are right, only the port driver writer knows for sure.
However, since the lingua franca of the port drivers is SCSI CDBs, it's
likely that there is some SCSI_PASS_THROUGH interface of some kind. The
limitations of said interface, if it exists in a given port driver, may
prevent you from doing certain things. It might give sufficient leeway to
allow you to implement a vendor-unique SCSI command in your hardware that
implements an ATA_PASS_TRHOUGH.

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.

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.

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?

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.

"Phil Barila" <PBarila@Barila.com> wrote in message
news:ZKGdnfrier3Z-Ybd4p2dnA@4dv.net...

David and Philip

Thanks for your inputs. I think we are missing the point here. My question was how can we send ATA SMART commands to a disk connected through firewire (IEEE 1394). The drive shows up in Device manager as disk drive, but as SBP2 1394 device

The driver stack for our device shows up a

----------Partition Manage

|--Disk Class drive
|---SPB2PORT.SYS ( I am guessing this is IEEE-1394 port driver

| |---
|---| IEEE 1394 driver stac
|----

I am wondering is there pass through mechanism available for this also

Thanks,
Shak

you can't. SBP-2 is a SCSI protocol and uses SCSI CDBs; it allows sending
arbitrary CDBs (with some documented exceptions) using the SCSI passthrough
interface. It does not support IDE_PASS_THROUGH or the newer
ATA_PASS_THROUGH because it doesn't know what an ATA command looks like. The
bridge device (1394->ATA, aka tailgate) does the translations between SCSI
commands and ATA, but unless you have some private CDB defined for the
bridge and some proprietary encapsulation of ATA commands using that private
CDB, there isn't a way to send ATA commands to the underlying device.

SAS (a new serial SCSI protocol) has the notion of SATA tunneling (STP) but
this isn't defined for other interfaces.


"shak" <kpf@netcell.com> wrote in message
news:BABA26CC-0EDF-4684-83D5-3B6DDFFE459F@microsoft.com...
(IEEE 1394). The drive shows up in Device manager as disk drive, but as SBP2
1394 device.

"David J. Craig" <SeniorDriversWriter@shogunyoshimuni.com.net> wrote in
message news:%23ELZ$LF6DHA.2472@TK2MSFTNGP10.phx.gbl...
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.

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.

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?

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.

Comments inline:

"Phil Barila" <PBarila@Barila.com> wrote in message
news:ScqdnUMxaqY7Br3dRVn-ug@4dv.net...
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.

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.

"David J. Craig" <SeniorDriversWriter@shogunyoshimuni.com.net> wrote in
message news:%23mgOLTc7DHA.1804@TK2MSFTNGP12.phx.gbl...
It's not about catering to the limitations of any given OS, it's about
conforming to a specification. The ATA spec says that sectors are 512
bytes, and that PIO data transfers are in integer numbers of sectors. If
you read ATA-6 differently, please cite the location of the reference that
suggests otherwise.

No argument here. Except to note that the architectural quirk of the MS
storage stack still being wrapped around CHS has nothing to do with the
legitimacy of a device that doesn't comply with the governing specification.

No kidding, I'm the one who told one of the OPs that (s)he would have to
implement one of those, and then use SPTI to get to the vendor-unique
command.

Yes, the drivers and bridges aren't designed to provide maximum information
or flexibility for managing ATA disks, they are designed to provide the
minimum function and information necessary to store and retrieve user
information as inexpensively as possible.


The amount of platter used by the servo is a function of the spindle speed
and the TPI(tracks per inch). The native sector size has no impact on the
servo overhead.

I've never ghosted to a network drive, so I don't know if Ghost produces 2
GB file segments because it has an assumption of FAT built into it, or if
the 2 GB file sizes I've seen is a consequence of the fact that it doesn't
ship with an NTFS DOS driver, so I'm ghosting to a file on a FAT32 volume.
Since the largest filesize FAT32 supports is 2GB, the largest ghost image
file will be 2 GB, as well.

Larger sectors don't buy you much in reduced overhead. They buy you better
ECC, but at the cost of more metadata, so the net capacity gain is
negligible. The reliability and data integrity gain is measurably
significant.

You argued above that you didn't want to tie yourself to a particular OS.
Now you want to tie yourself to the quirks of a particularly inefficient FS
implementation?

Fixed disks haven't been encoded that way for a very long time. There is
some per-sector info, but it's mostly ECC.

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.

4GB. About 20 minutes of DV video.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

You are correct in some ways. If you are using Windows, then 4GB will
work. If you are using DOS, which Ghost does, you are pretty much
limited to 2GB because the 'set file position' command takes a 32-bit
offset that is signed. Therefore, the seekable limit is 2GB and the
MS-DOS Programmer's Reference says that the limit is 2GB because DOS
only uses 31-bits for the file size.

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eoi4N9l7DHA.3360@tk2msftngp13.phx.gbl...