On Tue, 18 Oct 2016 12:56:14 +0100, John Rumm
wrote:

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

No, it's not. It's 'Is Gparted able to see and manipulate data at a
sufficiently low level', just in the same way low level formatting IDE
hard drives *appeared* to do something but (often) actually did
nothing at all.

The answer to which is yes.

If that is the right answer to the right question. ;-)



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

Quite, and it's the 'or not' bit I'm questioning here.

Moving a partition
is not something a drive has embedded support for -

I'm not suggesting it has John.

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.

Yes, understood, and that's fine *as long* as the blocks it thinks
it's writing to are the actual blocks. Think hdd address translation.

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.

Ok, and we can prove that how? eg, Do you have or are aware of a
utility, possibly offered by the drive manufacturers themselves that
can support your thoughts / understanding? Just to be clear here, I'm
not questioning your understanding, just asking if you have any way of
proving it please?

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"

I think I follow what you are saying there but don't think it's what
I'm trying to pin down (but it could well be). ;-)


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.

Yes, I understand that's what you are saying but can you offer any way
of substantiating it? Or more accurately, is there any way you could
help me substantiate it for myself on the SSD / System (dual booting
W10 and Mint 18) here?


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)

Ok, but I was really only trying to consider a clean / new drive that
had not had any block re-allocation.

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.

That was my thought.

(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).

Hmm, so that may also be the answer to my general 'but how can we be
sure' questions. ;-(

I've no dog in this fight, I'm just trying to get to the bottom of
what might be going on so as I can determine if I should bother /
waste any time correcting something that I may not actually be able to
in any case.

Maybe if no definitive / scientific answer is easily obtainable, maybe
a direct / specific speed test (focused on testing for such things)
could be applied (by me) pre and post any block alignment and then at
least I would know if it was any more than just a geeky myth etc
('now', if it ever was anything else etc). ;-)

Maybe I need a gold plated SATA 'Digital' cable to be able to test it
fully. weg

Cheers, T i m