PS: I had to tweaked hard to find a number so that all partitions would be of same size because I know of the MBR effect on size for any P1 during setup of partitioning. It came to be these numbers and I wrote it to disk and this is the cfdisk output even after re-boot-- I always triple check things:
sda1 ... boot . Primary ... FreeBSD ... 327115.50
sda2 ... .... ... Primary ... FreeBSD ... 327115.50
sda3 ... .... ... Primary ... FreeBSD ... 327115.50
In the dd numbers chart, notice P1 size has change its size on its own. Don't take my word for it... Try it. DEVICES IS NOT SUPPOSE TO CHANGE THE USER ACCEPTED INPUT FOR GIVEN DEVICE ONCE INITIATED, expecially by a clean boot. But as you see, it did it anyway. It makes you wonder how-much of a 3-Terabyes HDD would have decent transfer speed. My guest is 30% or less. Now you get one real Terabyte of acceptable speed the rest for hidden tricks that defy the odds, to secure the drive along with your data..
Quote:
|
The data transfer rate is higher in the outer cylinders compared to the inner ones because they contain more sectors. Period.
|
Quote:
|
... it's implementation-dependent
|
Quote:
|
While the drive manufacturers may have internal maps ...
|
Proof of resize:
P1 ... 327 415 463 424 bytes
P2 ... 327 415 495 680 bytes
P3 ... 327 415 495 680 bytes
That 12,256 BYTES... that's more that 512bytes for the MBR and 512bytes for a boot manager like GRUB. That leaves 11.256-Megabytes ripped out of P1 and is un-accounted. Standard documentation say difference so that means this is not common place, or is it?
IMO, Implementation-dependent, Magic maps or not, we now got "kind-of" a jacked-up slow device with tons of disk-space being created as the trade-off. If the Seagate 3-Terabyte HDD can gives me one-full-Terabyte in the WARP-speed-zone, I'll buy a dozen of them today.