On Mon, 17 Oct 2016 20:20:55 +0100, John Rumm
wrote:

On 17/10/2016 11:42, T i m wrote:
On Mon, 17 Oct 2016 11:31:48 +0100, John Rumm
wrote:

On 17/10/2016 10:45, The Natural Philosopher wrote:
On 17/10/16 09:37, John Rumm wrote:
In reality it could be anywhere on any boundary the
SSD firmware and processor puts it.

Not quite - there is not a one to one mapping of OS allocation units to
flash pages. For optimum performance you need to ensure that whichever
allocation unit you update, the SSD can do that update by operating on
one (and only one) page of flash. With the wrong alignment, you can end
up with the SSD needing to do two page updates for each OS allocation
unit update.


However all that may be true, but its not under user level control via
partioning, and its handled internally by the SSD.

There is no obvious way a SSD could make a sensible choice to internally
remap alignment if it turns out you have managed to install an OS
partition with a start LBA offset from the ideal. Especially as one
physical drive can host more than one partition, and if you really
tried, you could end up with several partitions each with different
alignments.

It makes far more sense to ensure the partitions are aligned so that the
OS allocation unit is on a 4K boundary (which is the default action on a
modern OS anyway)

So and irrespective of any performance impact ITRW, if some software
(Gparted) can see and display that these alignments aren't made *and*
can set them, is Gparted actually then *actually / physically*
resetting said alignments or just indicating it is?

It would need to copy the entire partition up or down a number of
sectors.

Yes, I have seen how one used Gparted to do it John but was interested
to know how we *know* it was actually doing it? Like when your tried
to LL format a drive and it looked like it was doing so but then you
rebooted and all your stuff was still there ... eg, Is it actually
happening (and how can we *prove* that) or is it simply saying it's
happening (by say moving a pointer) but not *actually* doing it (as
TNP seem to suggest is the case)?

Or like when you could no longer set the right drive geometry up
(c,h,s/t, b/s) and so the drives started doing translation to allow
you to access the whole drive past whatever BOIS limit was in place at
the time?

(However the OS may bork and need a reinstall if you do!)

Quite. ;-(

What would be a good (valid) way of checking for such things
(increased performance hopefully) pre and post adjustment?

On windows, do a msinfo32 in a command prompt to start the system
information tool. Then expand out the Components - Storage - Disks
part of the tree view. That will show all the physical drives, and the
partitions and their starting offsets. Divide the offset by 4096 and
hope you get an integer answer ;-)

e.g:

Description Disk drive
Manufacturer (Standard disk drives)
Model KINGSTON SHSS37A240G ATA Device
Bytes/Sector 512
Media Loaded Yes
Media Type Fixed hard disk
Partitions 1
SCSI Bus 0
SCSI Logical Unit 0
SCSI Port 0
SCSI Target ID 0
Sectors/Track 63
Size 223.57 GB (240,054,796,800 bytes)
Total Cylinders 29,185
Total Sectors 468,857,025
Total Tracks 7,442,175
Tracks/Cylinder 255
Partition Disk #0, Partition #0
Partition Size 223.57 GB (240,055,746,560 bytes)
Partition Starting Offset 1,048,576 bytes

Ok, but again, how do we *know* we are seeing the raw data and not
some soft translation of same? Is there some diagnostic software that
can really access the drive and report what *it* is actually doing?

It all sounds like re-numbering sector to reduce latency with Optune
all those years ago. ;-)

Yup, when disc controllers were so slow they might not be able to read
consecutive sectors if they were physically adjacent to each other!

That was it ... and testing it and resetting it was like re-plastering
the wall without touching the wallpaper. ;-)

Cheers, T i m