On 24/10/2016 12:05, T i m wrote:
On Sun, 23 Oct 2016 22:24:03 +0100, John Rumm
wrote:

On 23/10/2016 08:35, RJH wrote:
On 23/10/2016 07:36, John Rumm wrote:
On 22/10/2016 16:57, The Natural Philosopher wrote:

I conclude that it is therefore an urban myth believed in by people who
don't understand how SSDS actually work , and carried over from hard
drives, where the problem does exist.

So what you seem to be suggesting is that you have not actually found
any documentation that explicitly supports your position, and its one
based entirely on supposition?

Still it should be an easy enough proposition to test.


I've been round this particular house a couple of times. When pressed
for evidence he'll have an enormous strop and you'll be kill-filed.

Makes it all worthwhile :-)

Well there was a slim possibility that he actually had a source of
information that would be educational, or even a recommendation of a SSD
that does this hypothetical on the fly realignment.

Are you sure that is what he was suggesting as a straight 'thing' but
more that the physical / electronic alignment can be different in a
real world sense in comparison (even) than with what the tools we
generally use for such things offer / report? eg, There is no
*re-alignment on the fly* (as in making it actually align with the 4k
block boundaries) but that the whole alignment thing is hidden by the
electronics *and* data (or more importantly it's storage structure)
could / can be moved in any case for various reasons?

That's one heck of a sentence ;-)

I think the answer is yes - since the difference in performance with
differing alignments on otherwise identical drives would not show up so
dramatically otherwise.

I would think that any SSD manufacturer would like to 'hide' the
actual electronics (block sizes and actual addresses) so as to make it
unnecessary for anyone (or utility) to have to consider them. I'm not
suggesting that this is the case, just that I'm still willing to be
'open to' such thoughts.

The SSD (and any block level drive for that matter) does hide many
physical details from the OS. However there is no requirement to make
all considerations of alignment etc "go away" if you know that the OS is
on your side and will do sensible stuff to make sure this does not cause
a problem.

Just as we see with HDD geometry translation (something I see every
time I boot into Linux on my other PC).

Indeed, and that is just one example of the "hiding" - the physical
addressing on a hard drive needs cylinder, head and sector (CHS)
information to reach a physical address, but will typically be dealing
with SCSI style logical block addresses (LBA) instead.

Now in the case of a HDD there *may* be a relatively close mapping of
LBAs to physical sectors, such that as you step through sequential LBAs
it maps that to a physical address efficiently - addressing adjacent
sectors first, then heads, and finally cylinders. However even here
there is scope for redirection since the drives support bad sector
remapping etc. So two sequential LBAs may actually be stored in
completely different areas of the disk even with a HDD.

Block level misalignment started being a issue when 4K sector (i.e. so
called "Advanced Format" or AF) drives became the norm, because the
interface still retains the ability to address individual 512 byte
sectors. If the OS attempts to do a non aligned 4K write operation, then
then the drive can be forced to do a read - modify - write operation on
two physical sectors to complete the write - hence more latency and
slower performance.

With a SSD the mapping from LBAs to physical pages of flash is even more
arbitrary; due to the need for wear levelling, and extraction of maximum
performance from multiple parallel IO channels etc. However the drive
designers know in advance that IO will be done by the OS in 4K lumps, so
it makes lots of sense to optimise for the most likely operation, and
keep 4K writes contained in as few physical flash pages as possible.

Any OS less than a dozen years old has been updated to make sure that
any partition it creates does line up with physical sector boundaries[1].

(there may be a secondary alignment issue on SSDs as well since there
will also be a minimum size of erasable block that typically spans many
pages of flash - so not writing individual blocks that span those
boundaries any more often than required also helps[2]).

[1] e.g. https://wiki.debian.org/SSDOptimizat..._and_Alignment

[2] http://tytso.livejournal.com/2009/02/20/

(That last link will no doubt be dismissed by some as its "too old" and
the guy is a Linux kernel file system developer, so obviously not
qualified to comment ;-))


--
Cheers,

John.

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