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

[Darlene Wallach]

Rick,

On Thu, Apr 1, 2010 at 4:35 PM, Rick Moen <rick at linuxmafia.com> wrote:
> 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:

I profusely apologize for taking the thread offlist, it was *not* on
purpose. I wasn't paying attention when I replied.

I did try GNU parted and could not figure out how to get it to operate
on /dev/sdb.

I will try one more time.

Thank you for your patience! Thank you for taking your *very* valuable
time to so thoroughly answer my questions!

>
>  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.  ;->
>

Darlene Wallach
-- 
equal justice under law