[conspire] verifying I'm doing this correctly - fdisk, mkfs.ext3, e2label for FreeAgent Go 1T
rick at linuxmafia.com
Sun Mar 28 15:45:34 PDT 2010
Quoting Darlene Wallach (freepalestin at dslextreme.com):
> So I want to make sure I'm doing this correctly.
> (just showing the FreeAgent Go onto which I already ran rsync before
> realizing I wanted to format it as ext3)
Again, please note the stuff on that Web page about this particular
product line having the problem of spinning down autonomously, which
is a bit of a problem. That page had some remedies.
I have to wonder: Are you asking for advice because there's some other
thing that's peculiar about this device? I'm certainly not complaining;
it's just that I'd hate to hand out bad advice because there was some
vital fact about the situation that I didn't know.
You currently have /dev/sdb1 on this thing mounted, I notice, and the
filesystem's of type "fuseblk", which is a FUSE (Filesystem in USErspace
handler) block-device. FUSE has sub-handlers of some sort for NTFS and
ZFS, among others. I figure that Ubuntu's automounter (autofs or
whatever they use) sniffed out what's on the hard drive by default,
which I figure must be NTFS, and automatically invoked the FUSE layer to
I tend to run Linux without automounters, which I really personally
dislike except in special situations (e.g., networks where you do a lot
of NFS remote filesystem access), so I'm not going to be able to give
you a lot of advice about that part of your situation. Also, I've never
had a terabyte drive to play with, but my vague recollection is that you
might have problems using /sbin/fdisk on a drive that huge, and might be
better off using GNU parted, which is newer and designed for such things.
> df -h
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb1 932G 2.1G 930G 1% /media/FreeAgent Drive
> # mount
> /dev/sdb1 on /media/FreeAgent Drive type fuseblk
> # fdisk -l /dev/sdb1
> Disk /dev/sdb1: 1000.2 GB, 1000202240000 bytes
> 255 heads, 63 sectors/track, 121600 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0x69205244
> This doesn't look like a partition table
> Probably you selected the wrong device.
I vaguely recall that really huge hard drives might use a GUID Partition
Table (GPT), rather than the familiar IBM/Microsoft partition table. Article:
Now, I note that the article talks about /sbin/fdisk's abilities
petering out at the point of creating individual partitions exceeding 2 TB.
However, you might want to read that article, and you might want to take
a look-see at the existing partition table using GNU parted. (What's on
that hard drive doesn't matter if your intention is to wipe it, of
course, but you might be curious about what the heck is on there. I
After you umount the /dev/sdb1 partition, you might want to run "mount"
again to make sure that Ubuntu's automounter doesn't immediately
re-mount the fool thing.
One of the reasons I (generally) dislike automounters is that I don't
want filesystems mounted except when I say so. It's nice to know that
nothing's ever going to get mounted or umounted behind your back.
There are advantages to automounters, and I'll let other people sing
their praises. If you want to hear a stern lecture about the necessity
for automounters, one way to get it is to go onto Don Marti's
linux-elitists mailing lists and casually mention that you dislike them.
Greg Kroah-Hartman will then explain why anyone opposed to them is a
contrarian fossil opposed to Linux's success among general audiences,
and who is cruelly trying to prevent his daughter from being able to use
casual USB storage devices on the household computer.
There's also nothing the least bit wrong with GUID Partition Tables,
which are the wave of the future, rah-rah. I'm just not yet really
familiar with them.
So, in summary, you'll probably be best advised to use GNU parted
(binary name "parted", for Partition EDitor) in all the places where
you've mentioned fdisk.
Note that the manpage for /sbin/fdisk includes:
fdisk doesn't understand GUID Partition Table (GPT) and it is not
designed for large partitions. In particular case use more advanced GNU
The manpage for /sbin/fdisk also claims that the tool is buggy and
crufty, and that it's smarter to use cfdisk generally (if not GNU
parted). I've been hearing that advice for a long time, but /sbin/fdisk
has been reliable if funky in my experience (just not for huge drives).
> Device Boot Start End Blocks Id System
> /dev/sdb1p1 ? 13578 119522 850995205 72 Unknown
> Partition 1 does not end on cylinder boundary.
> /dev/sdb1p2 ? 45382 79243 271987362 74 Unknown
> Partition 2 does not end on cylinder boundary.
> /dev/sdb1p3 ? 10499 10499 0 65 Novell Netware 386
> Partition 3 does not end on cylinder boundary.
> /dev/sdb1p4 167628 167631 25817+ 0 Empty
> Partition 4 does not end on cylinder boundary.
> Partition table entries are not in disk order
> Is this the correct order?
> 1. umount /dev/sdb1
> 1. fdisk /dev/sdb1
Just a brief note to say that "fdisk /dev/sdb1" is wrong: You would
want to say "fdisk /dev/sdb". "sdb" is the whole disk, and by extension
its partition table. "sdb1" is the first filesystem on that disk.
You would be seeking to use fdisk (or GNU parted) to examine the
partition-table contents of the _whole disk_.
The rest of your stuff, at a glance, looked approximately right, though
I'm unclear on why you'd be using e2label (or the labelling option of
/sbin/fdisk, for that matter). Which brings up the matter of disk
labels, and also of the more-recent, more-fashionable solution to the
same problem, UUIDs. <sigh>
Disk labels were a 1990s attempt to solve the problem of making sure
that a physical mass-storage device ends up always getting the same
mountpoint, even if you do something that reshuffles the device
labelling such that what has until now been drive /dev/sdc has suddenly
become /dev/sdd. (Let's say you insert a new hard drive and bump up
some of the existing drives' device numbers.)
The idea is that, instead of having /dev/sdc1, /dev/sdc2, etc. be listed
in /etc/fstab's device column, you would have "LABEL=Boot" and "LABEL=usr"
instead. Use e2label (or mkfs.ext3's or tune2fs's "-L" options, which
all appear to be equivalent) to tag those filesystems with the desired
label attributes, which get hidden in some otherwise unused sector, and
There were a lot of problems with disk labels, the worst being what
happened if you were moving disks around and accidentally connected two
mass-storage devices to the computer that had the same label on a couple
of partitions, one referenced in /etc/fstab. Let's say that you had
'LABEL=usr" as an indirect reference to your intended /usr partition on
/dev/sdb1 -- and you connected a new-ish drive that also had "usr" as a
partition tag, say, on /dev/sdd2. Everything will look OK until the
next boot: Suddenly, the boot-time mount routines will get confused and
silently fail with extremely perplexing symptoms (kernel panic with no
indication of the root problem). Reportedly, this was a devilishly
difficult problem to diagnose, because there was no indication of what
the heck was wrong.
I got into the habit of never using disk labels as a means of indirect
reference. Red Hat Linux (and RHEL) for a long time tended to use disk
labels in /etc/fstab by default: I would always just use "mount" to
figure out the real, underlying device name, e.g., /dev/sdb1, and
re-edit /etc/fstab to use that instead of the "LABEL=..." syntax.
People would object: "But, but, but... that means that, if you inserted
or removed a hard drive, your /etc/fstab might suddenly be wrong." My
answer: "Then I'll plan on updating it."
UUIDs are Take Two of the same idea. Since the problem with disk labels
was that they were not unique, UUIDs solve that problem by ensuring that
their strings to reference partitions _are_ completely, guaranteed to a
high degree of probability to be unique planet-wide. Also butt-ugly and
excessively long. So, instead of having "LABEL=Boot" in the device
column of /etc/fstab, you end up having something like
"UUID=3e6be9de-8139-11d1-9106-a43f08d823a6", where UUID stands for
Universally Unique IDentifier and is a 128-bit hexadecimal string.
There are a bunch of utilities used to generate, manage, and report
UUIDs: vol_id, findfs, uuid are the ones that come to mind. Here's
an article about that:
Modern Ubuntu systems default to using UUIDs in /etc/fstab. I don't
particularly like them, personally (and get rid of them exactly as I
used to get rid of disk labels), but suit yourself.
> Format the entire disk as ext3
> 2. mkfs.ext3 -c -c /dev/sdb1
> mkfs.ext3 -c -c -L <myLabel> /dev/sdb1
The "-c" is the "check for bad blocks" option. There's no benefit to
giving it twice in a command string.
I salute your caution in doing a check for bad blocks on a new hard
drive. Most people don't bother, and I personally agree with you that
it's a worthwhile precaution. Be warned, however, that it takes a
significantly long time. For a terabyte partition, I really am not
sure, but would not be surprised to hear that it took a full day.
Have a look at the section on ext3 in an article I wrote back in 2006,
Note the three slightly different journaling options, which you can
compare. I think I might go for "data=ordered", still.
Notice, too, the "commit=nnnn" mount option, to specify how frequently
the disk buffers are to be flushed. You might want to relax that
refresh to something significantly longer than 5 seconds. Also, note
I'm not sure which options current versions of mkfs.ext3 enable by
default, but you can use tune2fs and its kin to check those and ponder
which ones you might want to adjust. (I'm pretty sure that
"data=writeback" journaling is still the default. Nothing wrong with
that option, by the way, and it at least has the advantage of being
More information about the conspire