From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 14:02:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA72A16A4CE for ; Mon, 29 Mar 2004 14:02:55 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A92243D46 for ; Mon, 29 Mar 2004 14:02:55 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Mar 2004 17:02:54 -0500 Message-ID: From: Don Bowman To: "'current@freebsd.org'" Date: Mon, 29 Mar 2004 17:02:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: question about dump performance on a snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 22:02:55 -0000 How long should it take to run 'dump' on a snapshot? I have a 6-disk raid 5 with 15K RPM scsi disk, so quite fast. It is 300GB in size, with 20% occupied. There are ~6000 files on this filesystem, all postgresql. I stopped postgresql, did a file system snapshot, and restarted postgresql. I then commenced a dump on the snap as below: dump -0 -a -C 32 -f $dumpfile -u $snapfile dumpfile and snapfile are both on the same filesystem. for the last 35 minutes, the size of the dump file has not gone up, and dump is taking 0% cpu: # dump -0 -a -C 32 -f $backupfile -u $outfile DUMP: Date of this level 0 dump: Mon Mar 29 16:32:25 2004 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /data/snapshot/snap.1 to /data/backup/dump.1 DUMP: mapping (Pass I) [regular files] DUMP: Cache 32 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 59867851 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] load: 0.00 cmd: dump 39347 [runnable] 1.20u 5.70s 0% 48616k # ps -wwax |grep dump 39584 p1 L+ 0:00.00 grep dump 39336 d0 I+ 0:01.61 dump -0 -a -C 32 -f /data/backup/dump.1 -u /data/snapshot/snap.1 (dump) 39347 d0 I+ 0:06.90 dump: /data/snapshot/snap.1: pass 4: 0.94% done, finished in 1:34 (dump) 39348 d0 I+ 0:08.18 dump -0 -a -C 32 -f /data/backup/dump.1 -u /data/snapshot/snap.1 (dump) 39349 d0 I+ 0:08.18 dump -0 -a -C 32 -f /data/backup/dump.1 -u /data/snapshot/snap.1 (dump) 39350 d0 I+ 0:08.26 dump -0 -a -C 32 -f /data/backup/dump.1 -u /data/snapshot/snap.1 (dump) Although the dump always indicates it is 'runnable' when i hit ^T, it doesn't run, and doesn't consume any cpu. The machine is idle. machine is running current cvsup from march 21 on a dual xeon 2.8 with asr raid controller. # tunefs -p /dev/da0s1e tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L)