On Mon, 24 Oct 2016 19:49:14 +0100, John Rumm
wrote:
snip
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 ;-)
Which one? ;-)
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've not actually tried testing / moving / testing one yet to see for
myself. I have an SSD in a laptop that I feel runs slower than the std
HDD it replaced and I noticed the partitions were aligned ... and
another one is very fast and they aren't, but that might just be
coincidence?
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.
Ok.
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.
Exactly.
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.
Yup.
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.
Yes, I understand the concept.
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.
Ok.
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.
Yes, *if* it's typically advantageous overall for it to do so.
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].
Yes, I (still) hear what you are saying and suggesting 'those who
know' would also be saying but may I remain unconvinced that it is
always the case or that it will always make the OS faster till I test
it for myself and find it so (given that no one has offered any
conclusive way to prove that *IS* what is actually happening (and I'm
not saying it isn't)).
(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 ;-))
I don't dismiss it but can't comment because it (playing devils
advocate), only suggests what should / can happen but not that it
actually does on all drives (and yes, possibly 'today').
I'm not even sure that testing, aligning and re-testing and
potentially seeing a (write) performance under test conditions is any
real proof of this partition alignment 'change' being the cause.
Again, I'm not suggesting it isn't but like many things (and for many
people) I think I'd like some proof, even if only imperial.
Cheers, T i m