SSD tuning in Windows XP

  • Thread starter Thread starter John Doe
  • Start date Start date
J

John Doe

Intel has an "Acronis AlignTool" for correction an NTFS formatting
problem in Windows XP. Something about the starting sector being 63
causing every read to access the disk twice. If I recall correctly,
my Macrium Reflect backup took 58 seconds before using that tool. It
took 30 seconds after.

I wonder if my first SSD could have benifited by the same tool.
 
John said:
Intel has an "Acronis AlignTool" for correction an NTFS formatting
problem in Windows XP. Something about the starting sector being 63
causing every read to access the disk twice. If I recall correctly,
my Macrium Reflect backup took 58 seconds before using that tool. It
took 30 seconds after.

I wonder if my first SSD could have benifited by the same tool.

On older OSes, they use the CHS information the disk gives them.
Even though, in practical terms, the disk uses LBA for normal usage.

The "fake" CHS info, says the disk has 63 sectors per track. That
applies to the larger disks. (We don't really know how many sectors
there are per track, but the number isn't 63. It hasn't been 63 for
about twenty years or so.)

Flash memory chips, on the other hand, are aligned to power_of_two
quantities.

Windows 7 or Vista solves this, by aligning the first partition to
an offset of a megabyte or two. Which is a power_of_two number of
sectors. This improves the odds that a disk cluster, aligns with
the flash units of storage. And the idea is, there are fewer
fractional operations required, on average.

If you change the alignment, then your older partition management
tools will complain. For example, if I used that AlignTool here,
Partition Magic would stop working, and PTEDIT32 would as well.
Which in the scheme of things, is a small loss. (I could replace
it with a free partition manager.)

And yes, the SSDs share characteristics, so what helps your new one,
would have helped the old one too. The page size may have doubled,
between the old and new one. But the same issues still occur, and
alignment helps.

If you'd primed the SSD on a Windows 7 (or even the release preview
version of Windows 8), then chances are it would be aligned as well.
The AlignTool's benefit, is the ability to correct a file system
that already has data on it. If the SSD has nothing on it, then
you can also create a fresh partition as a means to align it.
And then copy the data over after that. If you prepped in WinXP,
the partition would be misaligned. If you manually entered the
information into the MBR yourself, then your next battle would be
getting a formatter to like what you'd done. In terms of the
tools I've got here, I'd have a hard time cobbling together a
solution manually. (I could change the offset with PTEDIT32,
but then the question would be, whether the WinXP formatter
would have a heart failure on seeing that alignment.)

*******

There's a procedure here, for checking the alignment. It requires
"NAND erase block size" and "NAND page size", and that info comes
from the SSD maker. (It's actually determined by the flash chips
themselves.) There was also a web site with a "worksheet", where
you plugged the numbers in, and it told you whether the alignment
was good or not. If you prepped a drive in Windows 7, it might
be worthwhile verifying the job was done right (at least, the
first time).

http://www.ehow.com/how_8651274_test-ssd-alignment.html

Paul
 
Paul said:
John Doe wrote:

On older OSes, they use the CHS information the disk gives them.
Even though, in practical terms, the disk uses LBA for normal
usage.

The "fake" CHS info, says the disk has 63 sectors per track.
That applies to the larger disks. (We don't really know how many
sectors there are per track, but the number isn't 63. It hasn't
been 63 for about twenty years or so.)

Flash memory chips, on the other hand, are aligned to
power_of_two quantities.

Windows 7 or Vista solves this, by aligning the first partition
to an offset of a megabyte or two. Which is a power_of_two
number of sectors. This improves the odds that a disk cluster,
aligns with the flash units of storage. And the idea is, there
are fewer fractional operations required, on average.

If you change the alignment, then your older partition
management tools will complain. For example, if I used that
AlignTool here, Partition Magic would stop working, and PTEDIT32
would as well. Which in the scheme of things, is a small loss.
(I could replace it with a free partition manager.)

For dual booting Linux-Windows, Macrium Reflect allows you to
backup or restore both at the same time, or you can backup or
restore the individual parts. That works when you want to continue
dual booting, but...

One of the newer versions of Macrium Reflect appears less
functional, its rescue CD does not allow options for restoring the
boot area of an OS backup. So, if (for whatever reason) you want
to restore only the Windows part of your dual boot backup, if you
want only windows to be on the disk/partition, you cannot specify
"restore with default Windows XP boot area". There is no option
for restoring the boot area. Apparently that causes a failure.
Probably has something to do with Linux taking over the boot area,
I'm guessing that the Windows portion of your dual boot back up no
longer has a proper windows XP boot area.

For the disk alignment thing... When restoring a backup, Macrium
Reflect shows the most recently used format. For example, after
using the alignment tool, Macrium Reflect shows a very small part
starting at the 63rd sector. And it shows another area starting at
about 1 MB. I tried restoring an unaligned backup copy of Windows
to the section starting at about 1 MB. Within Windows, the
alignment tool showed it as "unaligned". But when I tried aligning
it, the alignment tool produced an error. The next time I did a
restore, I restored the unaligned Windows backup to the the first
area starting at sector 63, with the second area added to the
target space. Within Windows, again it showed as unaligned, but
that time the alignment tool worked properly.
 
Well. Restored an old backup copy of Windows. Installed the alignment
tool. Checked to see that it was not aligned. Made a backup copy,
that took 2:33. Used the alignment tool. Checked to see that it was
aligned. Make a backup copy, that took 2:33.
 
John said:
For the disk alignment thing... When restoring a backup, Macrium
Reflect shows the most recently used format. For example, after
using the alignment tool, Macrium Reflect shows a very small part
starting at the 63rd sector. And it shows another area starting at
about 1 MB. I tried restoring an unaligned backup copy of Windows
to the section starting at about 1 MB. Within Windows, the
alignment tool showed it as "unaligned". But when I tried aligning
it, the alignment tool produced an error. The next time I did a
restore, I restored the unaligned Windows backup to the the first
area starting at sector 63, with the second area added to the
target space. Within Windows, again it showed as unaligned, but
that time the alignment tool worked properly.

It sounds like the area from sector 63 up to 1MB, isn't being zeroed out
by AlignTool, and that causes Macrium to be confused.

They couldn't zero out below 63, because GRUB boot loader can live
in there. I don't think Windows puts anything in there. (I may have
looked at one time - there was something non-zero in there, on a
Windows system, but whatever it was, it didn't look important.)

The AlignTool, could be checking for more than one type of alignment.
Even though the origin of the file system is aligned, maybe something
else isn't aligned. You would think the part of the tool that does
alignments, would recognize when it is being asked to do a "null" operation.
(I.e. Not rewrite data to the exact same sectors it was being read from.)
Maybe that's why it threw an error ?

Paul
 
John said:
Well. Restored an old backup copy of Windows. Installed the alignment
tool. Checked to see that it was not aligned. Made a backup copy,
that took 2:33. Used the alignment tool. Checked to see that it was
aligned. Make a backup copy, that took 2:33.

Some people here, did their alignment manually, and got an improvement.
There's actually two parts to it. Aligning the partition, and then
changing a reserved area so clusters align. This was for FAT32. The
layout of NTFS will be different.

http://www.patriotmemory.com/forums/showthread.php?3696-HOWTO-Increase-write-speed-by-aligning-FAT32

I can't explain why you don't see a difference.

That thread mentions this article, and I had trouble finding a copy.
The server this was on, seems to be down at the moment.

http://web.archive.org/web/20101113...ning-filesystems-to-an-ssds-erase-block-size/

You could also look for a copy of nfi.exe (I've got it from a
"oem3sr2.zip" download from Microsoft), which only works on NTFS,
and look at the actual sectors occupied by files. And see if they
have any particular desirable alignment or not. If NTFS uses 4K
clusters, there probably isn't a way to align everything, and a set
of clusters can easily span multiple 128K blocks. And I don't think
you can set an NTFS cluster large enough, to align it naturally to
the flash. As far as I know, with each generation of flash getting
bigger, the block size is getting larger too.

("NAND erase block size" and "NAND page size", the ratio is usually
64 between those. And at one time, the erase block size was 128KB.
It could be larger now. As far as I know, the biggest NTFS cluster
size you can use is 64K, while the default is 4K. The 4K default
supports compression and defragmentation, which for an SSD you
don't care about, especially if it is Sandforce based.)

Paul
 
Well. Restored an old backup copy of Windows. Installed the alignment
tool. Checked to see that it was not aligned. Made a backup copy,
that took 2:33. Used the alignment tool. Checked to see that it was
aligned. Make a backup copy, that took 2:33.

The alignment is only useful during write operations, not during read
operations. And as I recall, even 64 sectors (sector count starts at 0
rather than 1) is considered aligned as far as SSD's are concerned. 64
sectors at 512 bytes/sector is equal to 32 256 bytes.

Yousuf Khan
 
Back
Top