[conspire] verifying I'm doing this correctly - fdisk, mkfs.ext3, e2label for FreeAgent Go 1T

Darlene Wallach freepalestin at dslextreme.com
Sun Mar 28 17:24:07 PDT 2010


On Sun, Mar 28, 2010 at 3:45 PM, Rick Moen <rick at linuxmafia.com> wrote:
> 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.

There were to options - one a script - the other adding a udev rule so
I think I have that problem taken care of - I hope. I created

> 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
> mount it.

I actually have Fedora 10 installed on my laptop, but maybe Fedora did
the same thing.

> 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.
I found the following *gparted* available for Fedora 10:
# yum list *parted*
Loaded plugins: refresh-packagekit
Installed Packages
parted.i386                           1.8.8-8.fc10                     installed
Available Packages
gparted.i386                          0.4.8-1.fc10                     updates
parted-devel.i386                     1.8.8-8.fc10                     fedora
pyparted.i386                         1.8.9-5.fc9                      fedora
qtparted.i386                         0.4.5-18.fc9                     fedora

I'm installing gparted now.

*argh*! Just realizing I downloaded parted already so I don't need
gparted - duh!

And I have to figure out the commands I need to partition the Seagate
FreeAgent Go 1T. I spoke with Mark - he suggested I make a partition
so I can back up the filesystem on my laptop in case I ever need to
restore it. So I thought I'd make a 40G partition on for that purpose.
I thought I put the first 960.2G as data and the last 40G for backing
up the filesystem.

Now I need to figure out the gparted commands to do that.

Does it matter if I use mkpart or mkparfs?

When I use parted to list, I get:
Model: Seagate FreeAgent Go (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  1000GB  1000GB  primary  ntfs

So does this look correct to you?
This would make the first partition for my data:
mkpart primary ext3 32.3kB 960.2G

Would this be the second partition?
mkpart primary ext3 960.2G 1000G

>> 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
>> (rw,nosuid,nodev,allow_other,blksize=4096)
>> # 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:
> http://www.cyberciti.biz/tips/fdisk-unable-to-create-partition-greater-2tb.html

Thank you.

> 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
> would be.)

I ran rsync then realized I wanted to format the drive as ext3, so it
is my stuff.

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

Thank you. I will.

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

Yep. When I install Fedora I think I do *not* select automount stuff.

> 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
>   parted(8).
> 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.

Thank you - duh!

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

How will the Seagate FreeAgent Go 1T get the UUID label?
Oh I see something in mkfs.ext3 for creating a UUID label.

> 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
> you're set.
> 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:
> http://www.linux.com/archive/feature/146951
> 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
>> OR
>> 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.

The man page says:
If this option is specified twice, then a slower read-write test
is used instead of a fast read-only test.

So I thought "-c -c" would be a better option - even though the drive is new.

> 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,
> here:  http://linuxmafia.com/faq/Filesystems/journaled-filesystems.html
> Note the three slightly different journaling options, which you can
> compare.  I think I might go for "data=ordered", still.

I don't see this in the man page for mkfs.ext3

> 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
> the directory-hashing.

Don't see "commit=" in man page for mkfs.ext3
> 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
> very conservative.)

Oh, not sure I understand, tune2fs will have the options I *don't* see
in mkfs.ext3. I could use tune2fs to add those options - journaling
and commit?

Thank you for taking so much time to answer my questions!

Darlene Wallach
equal justice under law

More information about the conspire mailing list