[conspire] output from gparted doesn't explain missing GiBs

[Rick Moen]

Quoting Darlene Wallach (freepalestin at dslextreme.com):

> I ran dd if=/dev/zero of=/dev/sdb bs=512 count=200
> 
> I'm using gparted since parted doesn't support ext3 yet.

Again, my understanding from online material is merely that it doesn't
support internally doing mkfs.ext3, _not_ that it cannot allocate ext3
filesystems.

I continue to recommend GNU parted for many reasons.  A while back, 
you took part of this thread offlist, so I cited some of the reasons
offlist in my reply.  Here, for others' benefit, is that part of what I
wrote:

  You really should not rely on GUI tools for important system functions,
  for a lot of reasons including being still able to function if X11 or
  linked graphics libraries are not available for some reason.  In other
  words, learning to get by with parted means you can do partitioning from
  anything as simple as a live CD disk or a non-X11 maintence/rescue
  environment:  It's a tool that works in essentially any environment.

  Also, non-graphical tools are inherently simpler in the sense of having
  less code with fewer bugs and (in general) better error reporting.
  When I am working with things as critical as destroying and remaking
  partition tables, I want my tools to be ultra-reliable.



> gparted shows the FreeAgent Go 1T disk as having 931.51GiB.
> 
> I don't understand what happened to the other 68.69 GiB.
> 
> Is there something I should do to get access to the 68.69 GiB not
> showing up in gparted?

Manufacturers have long played fast and loose with capacity claims.
This particular series has drawn some complaints among Amazon.com
reviewers about real capacity being somewhat shy of what's advertised:
http://www.amazon.com/review/R3LSMYSKWIBTTO/ref=cm_cr_pr_viewpnt#R3LSMYSKWIBTTO

And thereby hangs a tale:

A GiB is 2^30 bits, or 1,073,741,824 bytes.  In old-school days, everyone
including mass storage manufacturers implicitly used the binary
definition of kilobyte / megabyte / gigabyte (2^10, 2^20, 2^30).
Unfortunately, a couple of decades ago, some marketing weasel at one of
the companies realised they could sell a slightly smaller drive as 
"42 MB" when in fact it had 6 heads * 17 sectors per track * 820
tracks / head * 512 bytes / sector = 42,823,680 -- which by binary
calculation would have been 40.83 MB (42,823,680 / 1024 / 1024),
but was sold as a "42 MB" drive rather than a 40 MB one.

I believe it was, in fact, Seagate that first pulled this dodge.  I
vaguely recall that the rest soon followed suit -- predictably:
Otherwise, they would have lost sales to firms with "larger" drives.

Also, Seagate and the others were able to justify their nomenclature by
reference to official Systeme Internationale (SI) definitions of units
applied in an achingly precise and context-blind manner:  Within the
metric system proper, "tera" officially means 10^9, not 2^30.  

Thus, the convention _within computing_ that "Sure, we know what kilo
officially means, but _we_ define it to be 1024 within our limited
sphere of life" was destroyed by marketing weenies, and the ridiculous
terms "kibibyte", "mebibyte", "gibibyte", tebibyte", etc. for the binary
amounts got retroactively invented (and then hardly ever used).

The official Seagate specs on your drive -- that's model
ST910004FAA2E1-RK, right? -- are annoyingly vague:  They say only that
it's a "1 TB" capacity drive, but if you _were_ able to get figures on
sectors per track, heads, tracks per head, and bytes per sector and do
the math, I'm guessing you'd find that it's just over 10^9 bytes, which
is what what Seagate calls a terabyte.

A tebibyte (2^40) would be 1,099,511,627,776 bytes -- 1024 gibibytes (GiB).
You quite reasonably expect a terabyte drive to have _that_ capacity.
I agree with you.  Unfortunately, Seagate Technology and the rest of the 
Winchester drive industry does not.  To them, a terabyte is
1,000,000,000,000 bytes.  Converting that decimal amount to the binary
version:  1,000,000,000,000 bytes divided by 1,073,741,824 bytes per GiB, 
or 931.32 GiB.

And there you have it.  Your GParted-measured capacity of 931.51GiB 
means you have _just over_ the 1,000,000,000,000 bytes Seagate promised.



> I ran gparted after running dd if=/dev/zero of=/dev/sdb bs=512
> count=200. It didn't make a difference in terms of size of the disk.
> 
> even though I told gparted to start at 0, but it did not start at 0:
                                                ^^^^^^^^^^^^^^^^^^^^^

Hmm, interesting.

> path: /dev/sdb1
> start: 34

Not sure why it started with thirty-four somethings (blocks?), but 
there's probably some sort of reserved data...?  Dunno, really.

     	
> mkfs.ext3 -L "Wallach1TData" /dev/sdb1
>      	
> Filesystem label=Wallach1TData
> OS type: Linux
> Block size=4096 (log=2)
             ^^^^

Notice the block size selected by mkfs.ext3 -- rather larger than the
512 bytes that's most often been used in the past.  I assume mkfs.ext3 
knows what it's doing, absent a really good reason to override its
judgement.

 
> Will I get different results, like more than 931.51Gib available if I
> run cfdisk?

Nope.  ;->