Re: cloning a FreeBSD HDD
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. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp5f2b3kpFVA.pgp Description: PGP signature
Re: cloning a FreeBSD HDD
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). -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cloning a FreeBSD HDD
On Wed, Mar 29, 2006 at 10:14:19AM -0300, Patrick Tracanelli wrote: 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). In a prior life, I had to generate a bunch (50 or 60) disk images from a master server image. The server image was updated periodically, so we decided to always go for doing it on the fly, rather than just restoring a known-good dumpfile from some place. (Questionable in hindsight, but...) Anyhow, we were using SCSI disks, so I got a shelf full of scsi disk canisters (since we had standardized on a particular one) and then wrote a zsh script to do the dumping. Zsh has a particular ability to have it duplicate the contents of a single input stream to multiple output streams. So we would fire up one dump on the master disk, and then pipe the output to multiple copies of restore running (one per disk) simultaneously. It was way faster than doing them sequentially. And, impressive to watch the access lights on the drives when you were making seven disk drives copies at once... -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cloning a FreeBSD HDD
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Call for FreeBSD Status Reports
Hi All, It is time for the quarterly Status Reports. As always, reports are encouraged for anything that relates to FreeBSD development, documentation, independent projects, or anything else that might be interesting to the community as a whole. Reports should be one to two paragraphs in length. The template for submissions is here: http://www.freebsd.org/news/status/report-sample.xml Submissions should be submitted to monthly at FreeBSD.org by April 7th. Regards, Brad Davis ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Packet drops and queue length upon bandwidth limiting in PF
Hi friends, I am a relative newbie, so please don't flame me if my question doesn't make sense. In a network experiment to determine appropriate length of router buffers, I am using pfctl on FreeBSD 5.3 to limit the bandwidth to 100 Mbps on a 1 Gig link and limit the queue to 240 packets, and I use iperf for sending out data. Connection is maintained between two routers running FreeBSD 5.3, connected by a 1 Gig link. I monitor on sender the pfctl and iperf statisitcs. As I see the iperf throughput go down from 94 Mbps to 50 Mbps and then rise again in accordance with the classic sawtooth curve of TCP, it is clear that there must have been a packet drop, but pfctl -s -queue -v -v at the sender shows 0 losses and 0 drops. Moreover, the queue length as reported never overflows. Even netstat shows 0 retransmissions! I tried this with queue lengths of 50, 100, 240, 10 and 5. Only when queue length is on the order of 5 or 10 do I see packet drops in pfctl report (and also retransmissions in the netstat report); however, since I have limited the bandwidth and the outgoing traffic is shaped by this limitation, it is clear that there must be some packet losses in other cases as well. So, I tend to think that some other queueing is occuring apart from the ALTQ, and drops are occuring there. If so, how can I obtain those statistics? Thanks a lot for your help! Ashish ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
