On 17/10/2016 22:15, T i m wrote:
On Mon, 17 Oct 2016 20:20:55 +0100, John Rumm
wrote:

On 17/10/2016 11:42, T i m wrote:

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?

That's basically saying "does Gparted's partition resize / move
capability work?" The answer to which is yes.

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,

Low level formatting on IDE onwards was "supported" by issuing a command
to the drive and letting it get on with it (or not). Moving a partition
is not something a drive has embedded support for - your external
utility needs to physically read a bunch of blocks from one area of the
disk and write them back somewhere else, then rinse and repeat until its
done the whole partition.

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)?

Its happening for real, the partition will appear at a new starting
logical block address once done.

Internally the shift in content may not be reflected in exactly the same
way as a result of wear levelling, but its also fair to say the drive is
not going to be smart enough to say "aha, that 512MB bunch of sectors
you read a few mins ago, looks suspiciously similar to a new bunch of
sectors you are now writing 600 meg higher up the LBA address space -
you know what, I will take a gamble that you won't be needing the
original copy of that data and just pull a fast one swapping some
pointers round"


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 ;-)

Ok, but again, how do we *know* we are seeing the raw data and not
some soft translation of same?

You are seeing the raw partition info and LBA numbers.

Even with a normal HDD there may be sector remapping going on, so you
won't necessarily know how those LBAs map to the physical CHS addresses
on the HDD, or the flash page address of the SSD (especially as SSDs use
internal parallelism for performance)

Is there some diagnostic software that
can really access the drive and report what *it* is actually doing?

With SSD you probably can't get at physical flash pages unless you have
a proprietary tool from the maker of the drive. (one of the reasons why
there is a security risk when attempting to sanitise a SSD - you can't
be sure you have got all of the flash pages since they are not all
visible via a LBA - and the physical page used for a given LBA may
change in use).



--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/