From owner-freebsd-fs@FreeBSD.ORG Thu Mar 8 16:43:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC401065672 for ; Thu, 8 Mar 2012 16:43:17 +0000 (UTC) (envelope-from drue@therub.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC3B8FC19 for ; Thu, 8 Mar 2012 16:43:17 +0000 (UTC) Received: by iahk25 with SMTP id k25so1204964iah.13 for ; Thu, 08 Mar 2012 08:43:17 -0800 (PST) Received: by 10.50.184.199 with SMTP id ew7mr7599732igc.37.1331223585819; Thu, 08 Mar 2012 08:19:45 -0800 (PST) Received: from therub.org (173-8-105-230-Minnesota.hfc.comcastbusiness.net. [173.8.105.230]) by mx.google.com with ESMTPS id mk10sm14875354igc.4.2012.03.08.08.19.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 08:19:44 -0800 (PST) Date: Thu, 8 Mar 2012 10:19:41 -0600 From: Dan Rue To: freebsd-fs@freebsd.org Message-ID: <20120308161940.GA71851@therub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQkqmVI3P00rv+vR0GOCSeSwqnBirKhkZ0/TkR4cPejzGDEQ2i3ZlchDnUE37/hXVsrFHWIg Subject: ZFS and mdconfig -t vnode - Unexpected behavior X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:43:17 -0000 I have discovered an unexpected behavior when using ZFS against a vnode. When running mdconfig -d against a vnode, there is a long delay before the blocks are fully written to the backing store file. Consider the following test script: #!/bin/sh rm foo dd if=/dev/zero of=foo bs=4096 count=0 seek=1955584 du -k foo md=`mdconfig -a -t vnode -f foo` dd if=/dev/random of=/dev/${md} bs=4096 count=100 mdconfig -d -u $md while [ 1 ]; do fsync foo du -k foo blocks=`du -k foo | awk '{print $1; }'` if [ $blocks -gt 100 ]; then exit fi sleep 1 done A good run looks like this (UFS): # time sh t.sh 0+0 records in 0+0 records out 0 bytes transferred in 0.000017 secs (0 bytes/sec) 48 foo 100+0 records in 100+0 records out 409600 bytes transferred in 0.179925 secs (2276505 bytes/sec) 464 foo real 0m0.203s user 0m0.001s sys 0m0.018s A bad run looks like this (ZFS): # time sh t.sh 0+0 records in 0+0 records out 0 bytes transferred in 0.000015 secs (0 bytes/sec) 1 foo 100+0 records in 100+0 records out 409600 bytes transferred in 0.089111 secs (4596522 bytes/sec) 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 1 foo 515 foo real 0m27.370s user 0m0.009s Under ZFS, it can take as long as 30 seconds before the block size as reported by du -k has been updated. The fsync appears to be a noop. Under UFS, du -k shows the correct block size every time, immediately after mdconfig -d. This is the expected behavior. This has been tested against ZFS on FreeBSD 8.1, 8.2, and 9 stable, in several different environments. Are there any ZFS tunables that could be related to this? What could be the cause of this behavior? Thanks, drue