From owner-freebsd-stable@FreeBSD.ORG Mon Sep 1 22:31:45 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77869106566C; Mon, 1 Sep 2008 22:31:45 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE4E8FC0A; Mon, 1 Sep 2008 22:31:44 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m81MVTtB067063; Mon, 1 Sep 2008 18:31:30 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m81MVTJK048487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Sep 2008 18:31:29 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200809012231.m81MVTJK048487@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Sep 2008 18:31:36 -0400 To: Jeremy Chadwick , Kevin Oberman From: Mike Tancsa In-Reply-To: <20080901213856.GA17155@icarus.home.lan> References: <200809011336.m81Da5BT046532@lava.sentex.ca> <20080901160013.0005F4500F@ptavv.es.net> <20080901213856.GA17155@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Derek =?iso-8859-1?Q?Kuli=C5?= ?ski , Michael , freebsd-stable@FreeBSD.org Subject: Re: bin/121684: : dump(8) frequently hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 22:31:45 -0000 At 05:38 PM 9/1/2008, Jeremy Chadwick wrote: >Can someone explain what "dump frequently hangs" actually means? > >Does it lock up the entire machine indefinitely (and if so, how long did >you wait for it to (hopefully) recover)? As in the process hanging. For me, it was fixed quite some time ago. [zoo]# ps -auxlww | grep dump root 32093 0.0 3.8 39972 38036 ?? D Fri11PM 0:00.43 /sbin/dump -C24 0 1 0 20 0 pause root 73970 0.0 2.7 28708 26688 ?? D Thu11PM 0:00.14 /sbin/dump -C24 0 1 1 20 0 pause root 80852 0.0 3.8 39972 38000 ?? D 11:30PM 0:18.43 /sbin/dump -C24 0 1 0 20 0 pause root 98637 0.0 0.1 3308 1040 pd RL+ 8:20AM 0:00.00 grep dump 0 72305 0 96 0 - [zoo]# kill -9 80852 [zoo]# kill -9 80852 [zoo]# kill -9 80852 [zoo]# ps -auxlww | grep dump root 32093 0.0 3.8 39972 38036 ?? D Fri11PM 0:00.43 /sbin/dump -C24 0 1 0 20 0 pause root 73970 0.0 2.7 28708 26688 ?? D Thu11PM 0:00.14 /sbin/dump -C24 0 1 1 20 0 pause root 80852 0.0 3.8 39972 38000 ?? D 11:30PM 0:18.43 /sbin/dump -C24 0 1 0 20 0 pause root 98639 0.0 0.1 3308 1040 pd R+ 8:20AM 0:00.00 grep dump 0 72305 0 96 0 - [zoo]# >[1]: rsync is great for backups, and very fast, but there's the issue of >modifying atimes. I committed a patch to ports/net/rsync which adds an >--atimes flag, except its behaviour is not what you'd expect: the file >which was copied, at the destination, has the correct atime (of the >source), but the source itself ends up getting its atime modified, so >you're essentially destroying the atime data on the source. One of the reasons I dont use it for backups. Also its a pain with things like /dev and other special files. ---Mike