*NIX: Unexpected Behavior of HDD (internal VS enclosure?)

[ewemoa]

Has any one noticed oddness when trying to use a HDD sometimes via enclosure and at other times directly (e.g. via a SATA cable)?  An example of oddness is that gparted will show a partition table via one means, but via the other gives errors (sorry, don't have them recorded).

Need to do more testing and research, but came across:

My hunch (and it is just a hunch) is that your problem results from switching between a USB enclosure and direct connection of the disk. Some enclosures translate 512-byte logical sectors on the disk into 4096-byte logical sectors presented to the computer -- that is, the opposite of what the firmware in an Advanced Format disk does. I'm not positive, but I suspect that some enclosures do this only on over-2TiB disks. Both MBR and GPT partitioning schemes refer to data by sector numbers, so changing the sector size invalidates the partitioning data. Thus, if you prepare the disk in a USB enclosure that translates in this way and then try to use the disk directly (or vice-versa), you'll see errors because the partitions (and even GPT backup data) won't be where the computer expects it to be

via http://askubuntu.com/a/337993

Is this a well-known gotcha?

[Shades]

Most partition software (free and commercial) on Windows have an option to align a partition. Most modern operating systems and/or file-systems do this automatically. However, if you have formatted the drive in the enclosure and you use partition software to check for alignment you might see that it is out of alignment because of those 512 byte sectors. If so, alignment could help with putting the data on your disk on geographic locations that can be found if you swapped the disk from the enclosure into the computer.

I assume this type of software on Linux will have the alignment option available as well. But I'm not versed enough in Linux to tell you which application that could be. What I can tell you is that I did align every partition while I still was running XP on a 1TByte HD (cloned from a much smaller, older and dying HD) and I couldn't help but notice that the disk I/O wasn't stellar. With Process Explorer I checked the disk I/O and saw that it was almost always consuming between 0.5 to 2% of my computer resources.

After alignment it never got above 0.5% anymore and usually remained below 0.1%, something you definitely noticed in day-to-day use. Partition alignment works fast on empty partitions, but can take a very long time if a partition is crammed with data. Mine was full and it took almost 5 hours to align all partitions. However, it was worth it.

The link has a graphical representation of what the problem most likely is.

[ewemoa]

Thanks for the link and info!

Some subsequent searches have turned up the likes of:

To create an aligned partition (critical for an SSD) create a new partition with 2MiB of space preceding it (...) apply the change then resize/move the partition and change the 2MiB preceding space to 1mb. After that, create the next partition - again starting with 2MiB preceding space and then resizing/moving with 0 preceding space (always choose align to MiB). Repeat these steps for each additional partition.

via http://jsm-techblog.blogspot.com/2013/02/using-clonezilla-to-clone-from-larger.html

The instructions are for the program gparted.  Perhaps more searching will turn up a less manual series of steps...

[ewemoa]

Found the following response regarding the 2 moves from a gparted developer (?):

...there is truth in that to change a partition at the start of the disk from Cylinder alignment to MiB alignment and have it start at the first MiB does indeed require two moves.

There are historical reasons for the current behaviour in which resizing GParted could change a resize into a move and resize operation. For more information see the following bug report:

Bug 635113 - Unable to change alignment from cylinder (63) to MiB (2048) in single step

via http://gparted-forum...ewtopic.php?id=17101

[ewemoa]

I ran fdisk using a variety of arrangements for access to a specific HDD and found discrepancies in the reported total bytes (and ofc sectors) of the HDD.

The six things I tried included:

Direct internal SATA connection
3 SATA <-> USB adapters
2 USB 3 enclosures

The results for the direct connection and adapters all agree, but each of the USB 3 enclosures report different numbers (both smaller by different amounts)

Does it sound like I should avoid these enclosures?

[Shades]

Probably, after all, it is your data and the access you have to it shouldn't be determined by any device that can't get the numbers straight. Unless the data is of no importance to you, of course.

For fun you should try a USB2 enclosure and see where if the numbers are as expected in that one. If so, you could find out more regarding the chipset being used to convert SATA3 and USB.

[ewemoa]

Thanks for the feedback -- very much appreciated!

I don't seem to have a USB 2 enclosure I can mess around with without voiding a warranty, but may be once an appropriate one expires, I'll try your suggestion.

[40hz]

Is it possible that the different brands commandeer small amounts of disk space for scratchpad use, log files, caching or writing a few small data files for the controller's reference when running internal checks or diagnostics? That might account for the small discrepancies between different units.  

Different brands may also introduce small patches to the drive to optimize USB performance with the enclosure.

Or maybe it's all just more NSA spookware.