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 -
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
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
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
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.
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
6 matches
Mail list logo
