Oh ye of little faith.

cp's (1) -a option is a shorhand for -dpR
 - No *d*ereference of symlinks
 - *p*reserve file attributes if possible, and
 - *R*ecursive copy

Personally, I would have *ass*umed that -a does NOT override the default
SPARSE=auto, which implies preservation.  However, being everybit the
doubting thomas that you are, Weave, I went to the source, as it were.
http://ftp.gnu.org/gnu/fileutils/fileutils-4.1.tar.gz

Once again, GNU/Linux doesn't let me down, and performs as expected.

This assures me that cp's "-a" switch will copy sparse files unmolested.
The cp man page clarifies the conditions underwhich the sparse detection
and replacement is employed.   Interestingly, the code below implies
that since the "-a" switch does not CAUSE --SPARSE=auto, you
could opt to force (=always) or condense (=never), which would then, not
be a bona-fide archived copy.

If you are a belt-and-suspenders type, I suppose you could
# cp -a --SPARSE=auto $SRC $DEST

M

-----------------------
Here's the case statement for the the args.  You can see that
"a" does not override sparse.
----------------------

while ((c = getopt_long (argc, argv, "abdfHilLprsuvxPRS:V:", long_opts, NULL))
!= -1)
{
switch (c)
{
case 0:
break;


        case SPARSE_OPTION:
          x.sparse_mode = XARGMATCH ("--sparse", optarg,
                                     sparse_type_string, sparse_type);
          break;

        case 'a':               /* Like -dpR. */
          x.dereference = DEREF_NEVER;
          x.preserve_owner_and_group = 1;
          x.preserve_chmod_bits = 1;
          x.preserve_timestamps = 1;
          x.require_preserve = 1;
          x.recursive = 1;
          x.copy_as_regular = 0;
          break;

        case 'V':  /* FIXME: this is deprecated.  Remove it in 2001.  */
          error (0, 0,
                 _("warning: --version-control (-V) is obsolete;  support for\
 it\nwill be removed in some future release.  Use --backup=%s instead."
                   ), optarg);
          /* Fall through.  */

        case 'b':

-------------------------------------------etc... etc... etc...


FireFox TIP O' THE DAY... "/" temporarily brings up the find text widget... just like in less (1)!

Brian Weaver wrote:
Keep in mind that any "copy" command you use is like to get rid of any
"sparce" space in the files. If you use cp you might want to use the
'--sparse' option. The rsync command also has some options for handing
sparse files as well.

The dd command automatically handles sparse files because it simply
copies the disk blocks, but as Shane pointed out you get all the
fragmentation from the original disc too.

-Weave

Marty Ferguson [EMAIL PROTECTED] wrote on Wed, Jan 05, 2005 at 04:33:32PM -0500:

I still like Lance's solution, but for 1 alteration.
Being lazy, I just use
# cp -a
to create a recursive archive copy of the orginial filesystem.
The good thing (compared to dd) is that, since no *nix has a
"defrag" you end up with one big whoppin chunk-o freespace using
cp -a.  dd will duplicate the fragmentation.  The contiguous-ness
probably goes the same for dump | restore into a brand-new mkfs'd
ext3, but I never compared.

M

Every time is too many I would care to mention...
or count on both hands.


Shane O'Donnell wrote:

Maybe it was because I missed the resize2fs step in the instructions, but I
can't tell you how many times I've screwed myself using dd to copy drives
over.

Most new HDs come with a manufacturer's utility to do this and so far, it's
worked for me every time.

Keep in mind that:

- "every time" is about 3-4 times - "every time" includes IDE-only
- "every time" usually involves only "home user" filesystems (e.g., fat,
ext2, etc.)


Shane "short on experience, long on advice" O.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of [EMAIL PROTECTED]
Sent: Wednesday, January 05, 2005 3:23 PM
To: Triangle Linux Users Group discussion list
Subject: Re: [TriLUG] HDD Migration


On Wed, Jan 05, 2005 at 02:19:00PM -0500, Jason Browne wrote:


I am trying to get some tips on migrating an install of Linux to another,
bigger HDD?  It is a straight 1 HDD to 1 HDD change...  I know I could use

dd


, but I am trying to see if there is a better way.


dd has worked fine for me many times, as long as you do resize2fs after
the dump.

If you recreate your top level directories (/tmp /bin /sbin etc), you
can use 'cp -a' for most of them with good results.  Don't do it for
lost+found, proc, dev, and sys(I think sys was special at least) though.

For dev, just copy over MAKEDEV and any other non device files, along
with all folders. Then run MAKEDEV in the new /dev This is all off the top of my head, and probably quite a bit mroe work then a pure copy, but it went fairly quickly in the few times I did it, and is a good way to make sure everything copied over sanely.


Or, there's ways of just using tar or cpio to do similiar in one step.

But as I said, dd is easy, and hasn't screwed up in my experience.  Just
make sure you shut down as many things as possible to keep your
filesystem from being too much of a moving target. (log files
especially)


-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc


--
TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ  : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc

Reply via email to