[conspire] verifying I'm doing this correctly - fdisk, mkfs.ext3, e2label for FreeAgent Go 1T
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
parted.i386 1.8.8-8.fc10 installed
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
mkpart PART-TYPE [FS-TYPE] START END
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
>> # 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
> 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
> 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:
> 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.
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
Thank you for taking so much time to answer my questions!
equal justice under law
More information about the conspire