[conspire] questions on next steps to use external firewire harddrive

[Rick Moen]

Quoting Darlene Wallach (freepalestin at dslextreme.com):

> 1. Here is what is reported by df -h for the external
> firewire harddrive:
> 
> $ df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdb2             148G  189M  140G   1% /media/ieee1394disk
> 
> Since the disk is really larger and I specified
> +2G for swap and +161G for the remaining, and
> 
> Command (m for help): p
> 
> Disk /dev/sda: 163.9 GB, 163928604672 bytes
> 
> am I correct in assuming that about 21G is bad blocks?
> I used:
> mkfs.ext3 -c -c /dev/sda2 157236187


Er, I don't know.  21GB does sound like an extraordinarily excessively
high number, for bad blocks on a hard drive.  If true, that would be in
my opinion ample grounds for considering the drive basically defective,
and returning it under warranty (if any).

Wait a minute:  I have to wonder why you said "157236187" at the end of
that command -- and suspect you may have inadvertantly created a
partition shorter than the available space.

That number will get interpreted as "Make the filesystem be exactly this
number of blocks, regardless of how many blocks there actually are."  I
have never used that parameter for the mkfs.* commands, and suspect
they're normally against your best interest.  Normally, one would allow
the mkfs utility to figure out for itself how many blocks to allocate --
and I strongly suspect you should do that, and that you'll find yourself
suddenly regaining the missing space, when you do.

So, I'd say you should do that.


> Since I used the mkfs.ext3 as stated above, which I
> assume wrote to the disk using 4 test patterns, should
> I also use the following command to really zero out
> the harddrive before I use it?
> 
> #  dd if=/dev/zero of=/dev/sdb bs=512 count=1

No -- though that's probably not what you want to do, at the moment,
anyway.

To answer your question as posed, first, that command doesn't zero out
the (entire) _hard drive_, per se, because of the last two parameter:

"bs=512" means use a block size of 512 bytes for the operations
specified in this command.

"count=1" means perform one write cycle, only.  (Default, without this
parameter, would have been to keep repeating until one reaches 
end-of-device.)

In context, the cited command thus becomes "Please bit-copy information
from device /dev/zero (which is an endless source of binary zeroes) to
device /dev/sdb (the second SCSI device, addressed from its very first
storage sector and moving forwards from there).  In doing so, perform
one write of 512 bytes, and then stop."

In other words, that command wipes out sector zero (only) of the target
device.  In the PC world, that's the sector where the 446-byte MBR boot
program (if any), the 64-byte partition table, and two bytes left over
(used by NT & kindred for "disk signature" bits) live.  The command thus
clobbers the disk catalogue (if any) and boot program, while leaving
untouched everything else including partitions themselves.  Of course, 
those partitions (if present) will at that point have only a kind of
ghost existence, since the partition tables that define them will have
been zeroed out.

It's a super-quick way of making the drive _effectively_ empty for all
practical purposes.

(By the way, I'm not sure what you mean by "4 test patterns", but you
might be referring to the badblocks checking, in which case you probably
know more about that than I do, at the moment.)


> 2. What is the best way to transfer/move data from my
> internal hard drive to the external firewire
> 
> Should I use
> dd if=/dev/hda2 of=/dev/sdb2 bs=512 count=1
> 
> $ df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/hda2              18G   17G  385M  98% /home
> 
> 
> Should I use tar?
> Should I use mv?

I've written a FAQ on this, of sorts:
"Copying Directory Trees" on http://linuxmafia.com/kb/Admin/

Personally, I like rsync.  Also, be wary to avoid accidentally copying
filesystems mounted within other filesystems, e.g., copying /proc by 
mistake when copying the root filesystem.  For that reason, and in order
to make sure the filesystems to be copied are quiescent (not changing
underneath you) while being copied, you should ideally perform the copy
information while booted from a live CD.

For completeness's sake (for other people reading this thread and
seeking to apply its tips to their own situations):  If you'd been
intending to deploy the new drive as the replacement boot drive (which
in _your_ case will not be happening), regardless of the method you use
to copy data files over, you'll almost certainly also have to rewrite
the bootloader on the new drive, e.g., using a live CD.