Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Mar 2006 14:50:22 -0800
From:      John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To:        Patrick Tracanelli <eksffa@freebsdbrasil.com.br>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: cloning a FreeBSD HDD
Message-ID:  <20060329225022.GW7001@funkthat.com>
In-Reply-To: <442A882B.8000207@freebsdbrasil.com.br>
References:  <44296F41.1050209@osoft.us> <4429972C.5030806@freebsdbrasil.com.br> <20060328.210412.18287651.imp@bsdimp.com> <200603291953.56112.doconnor@gsoft.com.au> <442A882B.8000207@freebsdbrasil.com.br>

next in thread | previous in thread | raw e-mail | index | archive | help
Patrick Tracanelli wrote this message on Wed, Mar 29, 2006 at 10:14 -0300:
> Daniel O'Connor wrote:
> >On Wednesday 29 March 2006 14:34, M. Warner Losh wrote:
> >
> >>dump + restore is slow but reliabe.
> >
> >
> >Faster than dd for disks that aren't full :)
> >
> >It also gives you a defrag as well as allowing you to change FS options.
> 
> Yes, pretty much faster for non-full disks, even compared to paralell 
> dd(1). And we always have the "-L" option to snapshot and dump(1) from 
> live file systems, what makes it an interesting and completly viable 
> choice to clone the disks in multiuser mode (no need to go single user).
> 
> It is my choice to copy a disk into one other. It is even possible to 
> copy a disk to a slower one (again, if the source is not full and if the 
> dst disk have enough space to store all data currently in use in the 
> source disk), and better (customizable new partitions) results when 
> copying to a larger second disk, when compared to dd(1).

Though if you are using extended attributes, the dump/restore pair won't
transfer them...  :(

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060329225022.GW7001>