From owner-freebsd-stable@FreeBSD.ORG Wed Sep 6 13:36:21 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 141C116A4DD for ; Wed, 6 Sep 2006 13:36:21 +0000 (UTC) (envelope-from ulrich.spoerlein@1822direkt.com) Received: from mailout0.1822direkt.com (mailout0.1822direkt.com [213.83.45.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5812A43D49 for ; Wed, 6 Sep 2006 13:36:19 +0000 (GMT) (envelope-from ulrich.spoerlein@1822direkt.com) Received: (from uucp@localhost) by mailout0.1822direkt.com (8.13.4/8.13.3) id k86DZVjH069436 for ; Wed, 6 Sep 2006 15:35:31 +0200 (CEST) (envelope-from ulrich.spoerlein@1822direkt.com) Received: from mailout0.1822direkt.com(213.83.45.184), claiming to be "misc-cluster.1822direkt.com" via SMTP by mailout0.1822direkt.com, id smtpdXi012n; Wed Sep 6 15:35:27 2006 Received: (qmail 47108 invoked from network); 6 Sep 2006 13:35:26 -0000 Received: from unknown (HELO dvpc03) ([127.0.0.1]) (envelope-sender ) by 127.0.0.1 (qmail-ldap-1.03) with SMTP for ; 6 Sep 2006 13:35:08 -0000 From: Ulrich =?iso-8859-1?q?Sp=F6rlein?= Organization: 1822direkt.com To: stable@freebsd.org Date: Wed, 6 Sep 2006 15:34:57 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <239947161@misc1.1822direkt.com> Cc: Subject: Snapshot duration, performance and how to avoid I/O lock 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: Wed, 06 Sep 2006 13:36:21 -0000 Hi, I have to create regular snapshots of several volumes roughly 1.4TB in size (each). But using mksnap_ffs takes a lot of time (45 minutes) and it looks like it could be speed up. iostat reports some 2MB/s of I/O tty da0 da1 sa0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 77 16.00 120 1.87 0.00 0 0.00 0.00 0 0.00 0 0 8 4 89 0 231 16.00 131 2.04 0.00 0 0.00 0.00 0 0.00 0 0 6 2 91 0 77 16.00 127 1.98 0.00 0 0.00 0.00 0 0.00 0 0 5 3 92 0 204 16.00 123 1.92 0.00 0 0.00 0.00 0 0.00 0 0 6 3 91 0 77 16.00 128 2.00 0.00 0 0.00 0.00 0 0.00 0 0 6 3 91 gstat reports dT: 0.501s w: 0.500s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1 126 84 1341 11.8 42 671 2.7 99.7| da0 The filesystem under snapshotting was *empty*, and right now is at Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s2d 1376038286 815092 1265140132 0% /export/vol1 How come, a snapshot of an empty file system takes more than 800MB? Aren't the blocks copy-on-write? Why is the disk 100% busy while only a mere 2MB/s are pushed? This is on a 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xdc000000-0xddffffff,0xd8300000-0xd8300fff irq 48 at device 1.0 on pci3 twa0: [FAST] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.04.00.005, BIOS BE9X 3.04.00.002 with a RAID5 over 7 SATA disks. da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 1430448MB (2929557504 512 byte sectors: 255H 63S/T 182356C) Another thing is blocking other disk I/O while snapshotting. Right now I did a ls(1) in the .snap directory, so I understand the filesystem is now suspended. The workaround would then be to "dont do that". But what if other snapshots are accessed during that time? I want to provide yesterdays snapshot to our users while taking the current snapshot and providing access to the newest data at the same time. Cheers Ulrich Spoerlein