Re: sbp2port.sys, IEEE 1394 port driver
From: Phil Barila (PBarila_at_Barila.com)
Date: 02/08/04
- Next message: Tim Roberts: "Re: Kernel malloc/realloc?"
- Previous message: David J. Craig: "Re: Mounting a second partition on a compact flash"
- In reply to: David J. Craig: "Re: sbp2port.sys, IEEE 1394 port driver"
- Next in thread: Maxim S. Shatskih: "Re: sbp2port.sys, IEEE 1394 port driver"
- Reply: Maxim S. Shatskih: "Re: sbp2port.sys, IEEE 1394 port driver"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 7 Feb 2004 22:38:00 -0700
"David J. Craig" <SeniorDriversWriter@shogunyoshimuni.com.net> wrote in
message news:%23mgOLTc7DHA.1804@TK2MSFTNGP12.phx.gbl...
> Comments inline:
> 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.
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.
> 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.
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.
> 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
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.
> 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.
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.
> 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
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.
> 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.
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.
> 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.
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?
> 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.
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.
- Next message: Tim Roberts: "Re: Kernel malloc/realloc?"
- Previous message: David J. Craig: "Re: Mounting a second partition on a compact flash"
- In reply to: David J. Craig: "Re: sbp2port.sys, IEEE 1394 port driver"
- Next in thread: Maxim S. Shatskih: "Re: sbp2port.sys, IEEE 1394 port driver"
- Reply: Maxim S. Shatskih: "Re: sbp2port.sys, IEEE 1394 port driver"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|