[conspire] output from gparted doesn't explain missing GiBs
freepalestin at dslextreme.com
Thu Apr 1 17:04:40 PDT 2010
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
> 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
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
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:
> 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
>> Will I get different results, like more than 931.51Gib available if I
>> run cfdisk?
> Nope. ;->
equal justice under law
More information about the conspire