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

Mark Weisler mark at weisler-saratoga-ca.us
Sun Mar 28 19:56:11 PDT 2010

Hash: SHA1

Darlene Wallach wrote:
> Rick,
> 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
> 10-local.rules:
>> 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!
It will not hurt you to have both parted and gparted on your computer.
parted is a CLI partition editor.
GParted (abbreviated as GPT) is a CUI frontend to GNU Parted and the
official GNOME Partition Editor application.

GParted is pretty friendly to use and makes it pretty clear what is
going on. I recommend you try it.
Just create one or two partitions on the external Seagate drive then put
the filesystem on each partition. That should do it.

> 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

- --
Mark Weisler
PGP Key ID 68E462B6
PGP Key fingerprint  87D5 A77B FC47 3CC3 DFF0  586D 23FF F8B4 68E4 62B6

Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the conspire mailing list