Linea said:
You're not sure? How can one verify this? I have a 500 GB drive too, but
this is an external USB drive. I believe there is a seagate inside
because model ID is ST3500820AS. I see here in HD Sentinel: Bytes Per
Sector, 512 (amonst a load of other data).
When I say that, what I mean is, the drive is probably using a 4K sector
internally, but the *electronic* identification of the drive claims it
is a 512/512 drive. The addition of proper identification, was some
addition of information to the ATA spec. Later drives, properly
report size. Since I'm still working on this as a "project" for myself,
here's the latest link I found with some discussion.
http://www.johannes-bauer.com/linux/wdc/?menuid=3
As for a utility, this is one I tried yesterday.
http://downloads.dell.com/FOLDER96706M/22/DELL_ADVANCED-FORMAT-HDD-DET_A00_R306204.exe
Inside there, is a file "DellAFDT.exe" which I extracted with 7ZIP.
It runs from the command prompt. Here is the output from my
(suspected dishonest) drive and my latest 4K drive. The 4K drive,
since it is more honestly reporting logical and physical characteristics,
the Dell utility reports it is not aligned properly. (If you were running
this in Windows 7, you might want to use a "Run as Administrator" cmd.exe
window,
as I suspect the access of low level hardware details might need it.)
The first drive is 500GB, but behaves a bit choppy. Choppy behavior
can be caused by lots of spared-out sectors. So that is still a
possibility.
Since all the identify words are zero, I expect the drive just isn't
designed
to report anything for the appropriate parameters. And since the Dell
utility
has checked the params, and found them to indicate 512/512 byte per sector
drive, all partitions are claimed to be aligned. (Because partitions on
"old"
drives, don't have an alignment issue.) But my suspicion is, this is a
512e drive (4096 physical 512 logical) and not really a true
old fashioned 512 byte drive.
Model: ST3500418AS
Serial#: 9VMXTKA9
Advanced Format: No
Partition Alignment: Aligned
Partition 1: Aligned [G:]
Partition 2: Aligned [M:]
Partition 3: Aligned [Not assigned]
Partition 4: Aligned [N:]
Identify Data Word 106: 0x0
Identify Data Word 117: 0x0
Identify Data Word 118: 0x0
Identify Data Word 209: 0x0
This is my latest purchased drive. In Linux, this reports as 4096 physical
and 512 logical type drive. The Dell utility can easily tell that my CHS
prepared disk (partitioned in WinXP) is mis-aligned. But because the drive
emulated 512 byte sector operations (you write 512 bytes and it doesn't
care),
this is all handled for you. It's just, if the partitions were better
aligned,
then the cache behavior used to hide the details, would no longer be
necessary.
But the cache is always running anyway, so the overhead involved (cache
management policy inside the drive) is still going to be there.
Model: ST500DM002-1BD142
Serial#: W2A95XHC
Advanced Format: Yes
Logical sectors per physical sector: 8
Logical sector size (in bytes): 512
Partition Alignment: Misaligned
Partition 1: Misaligned [C:]
Partition 2: Misaligned [D:]
Partition 3: Misaligned [E:]
Partition 4: Misaligned [W:]
Identify Data Word 106: 0x6003
Identify Data Word 117: 0x0
Identify Data Word 118: 0x0
Identify Data Word 209: 0x4000
What I don't know, and what I've been researching as hard as I can, is
whether *any* utility understands FAT32 well enough, to understand that
aligning the front of the entire partition is one thing, but aligning
the clusters inside is a separate issue. The two FATs in FAT32, take
variable storage area, which causes the clusters to start where ever they
fall. Some nice pictures here, if needed...
http://www.pjrc.com/tech/8051/ide/fat32.html
http://www.pjrc.com/tech/8051/ide/fat32_layout.gif
As you change the overall size of the partition, the size of the FATs
change at the same time. If you change from 16K clusters to 32K clusters,
the size of the fat changes by a factor of two as well. It takes four
bytes of storage in a FAT, to store a link to a cluster. Which is how
that space is determined. If you radically change the number of clusters,
the FATs also change in size (as the number of 4 byte pointers to store
has changed).
I'm also going to need to research this for NTFS, but haven't got there
yet. First, I need to understand how to fix the FAT32. And whether the
purchase of the Paragon tool, would actually ensure the clusters are
aligned to 4K or not. When I did this manually from Linux (backup and
restore, using mkfs.vfat command to custom set up FAT32 partition),
it didn't seem to make a performance difference. And when I ran
"fixboot C:" from the WinXP installer CD later, that's when the
partition boot sector was put in the wrong place, and I couldn't
boot from that FAT32 partition. I was able to test the partition,
for write performance, but when finished, it wouldn't boot. Which
means I have more work to do. I'd probably need to leave the
Reserved Sectors field at the normal 32 value, and just resize the
partition a bit, to adjust the size of the FATs where they need to be.
This is what I tried in Linux, to make a fresh partition to
test with. 64 --> 32768 byte cluster. The R parameter is reserved
sectors at the front of the partition, and I changed that from the
normal 32 to 39 for my test. Using a hex editor, I checked the first
file on the new partition, and it was 4K aligned (32K cluster aligned
with 4K boundary). But when I did fixboot C: from WinXP, it seemed to
put the partition boot sector in the wrong place. So maybe it doesn't
like "R 39".
mkfs.vfat -a -F 32 -n WINXP -v -s 64 -R 39 /dev/sdc1
