[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
-----BEGIN PGP SIGNED MESSAGE-----
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
>
> 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
>>> (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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuwFssACgkQI//4tGjkYrYIkQCeJDAP9rz7pVi9HaCNOPVBQ0QJ
+LsAmgLlKxFTKgCUySezH+FbF35NeyE0
=gNXE
-----END PGP SIGNATURE-----
More information about the conspire
mailing list