From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 00:39:32 2010 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 BEEC31065692 for ; Sat, 13 Feb 2010 00:39:32 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 2599C8FC1E for ; Sat, 13 Feb 2010 00:39:31 +0000 (UTC) Received: by gxk10 with SMTP id 10so2801283gxk.3 for ; Fri, 12 Feb 2010 16:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Pv4B+O6T0BR4MUvOHd8vF8wVm7F1/+/HC5QfsnUePh0=; b=su7xD0ZvQipqwZlS8Zdj5Br18lBxh0oAbfTT5lEQ+JiJVIQtaWU3R0j7fgb93W3qFn lKhgonOf1AYUyWVHft+efPIG8A7B6lv0uFTAJLsLsIkxLvL74paUUh5kJfatNJktypmK E2Mbm01LHEZqgjzTPZ0JQYjk2SC70LR5joyfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ja+sCc7NjffUXH0YW/bLmoItrzIJ35VctuQ/0aCWMmxc1PQgNqCnxcphroizkZ08/P 3TRH+eCWpkk8DHGr841Gc6gEYNht3zLh58h3PJJBo0J3Fnj89RfuOsS9oo0a+XlEpK4C V5lE1ki9lCw8w4Y2yTbaTutQg2dnu6PLHmBgo= MIME-Version: 1.0 Received: by 10.151.89.37 with SMTP id r37mr3454682ybl.60.1266021570518; Fri, 12 Feb 2010 16:39:30 -0800 (PST) In-Reply-To: References: Date: Fri, 12 Feb 2010 16:39:30 -0800 Message-ID: From: Matt Reimer To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS file storage info 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: Sat, 13 Feb 2010 00:39:32 -0000 On Fri, Feb 12, 2010 at 3:50 PM, Ivan Voras wrote: > Hi, > > Because of ZFS' interesting way of storing files, I'm wondering if there is > a way to get information such as how fragmented a file is? I'm thinking > about something like an utility that for a given file gives "file X is > stored in Y fragments"? > [root@gandalf ~]# ls -li /usr/bin/vi 6987 -r-xr-xr-x 6 root wheel 337136 Nov 21 14:31 /usr/bin/vi [root@gandalf ~]# zdb -ddddd glamdring/usr 6987 Dataset glamdring/usr [ZPL], ID 31, cr_txg 97, 1.59G, 77833 objects, rootbp [L0 DMU objset] 400L/200P DVA[0]=<0:10800c33e00:600> DVA[1]=<0:21000487800:600> fletcher4 lzjb LE contiguous birth=3345 fill=77833 cksum=1189b0387a:6d5fe773294:15d9bc7539ad2:2fb4ba66521d1e ZIL header: claim_txg 0, seq 0 first block: [L0 ZIL intent log] 20000L/20000P DVA[0]=<0:1b9730000:30000> zilog uncompressed LE contiguous birth=3233 fill=0 cksum=7fb9ac2ef6d387ee:edbcafeec75face4:1f:1 Block seqno 1, won't claim, [L0 ZIL intent log] 20000L/20000P DVA[0]=<0:1b9730000:30000> zilog uncompressed LE contiguous birth=3233 fill=0 cksum=7fb9ac2ef6d387ee:edbcafeec75face4:1f:1 Object lvl iblk dblk lsize asize type 6987 2 16K 128K 384K 388K ZFS plain file 264 bonus ZFS znode path /bin/ex uid 0 gid 0 atime Sat Feb 13 07:37:52 2010 mtime Sat Nov 21 14:31:07 2009 ctime Fri Feb 12 05:52:32 2010 crtime Fri Feb 12 05:52:32 2010 gen 145 mode 100555 size 337136 parent 4 links 6 xattr 0 rdev 0x0000000000000000 Indirect blocks: 0 L1 0:10bef000:c00 4000L/400P F=3 B=145 0 L0 0:10bf0000:30000 20000L/20000P F=1 B=145 20000 L0 0:10c30000:30000 20000L/20000P F=1 B=145 40000 L0 0:10c70000:30000 20000L/20000P F=1 B=145 segment [0000000000000000, 0000000000060000) size 384K You're interested in the "Indirect blocks" portion. Google raidzmap.tar.gz, download and build it, then do the following. Note that you'll drop the third portion of the zfs offset tuple (e.g. the "c00" in 0:10bef000:c00) and use the physical size (the hex number next to the "P" in "400P"). The devidx numbers correspond to the devices comprising the pool, zero-based. The offset numbers are the hex offset in blocks from the beginning of the disk. In the list of physical blocks the parity blocks come first, then the data blocks. Firstdatacol is the offset into the list of physical blocks where the data blocks begin. For example, in the first raidzmap command below, firstdatacol is 2 which corresponds to "devidx = 0, offset = 2ca7e00, size = 200". IIRC, YMMV, etc. [root@gandalf ~]# ./raidzmap glamdring:0:10bef000:400 Columns = 4, bigcols = 4, asize = c00, firstdatacol = 2 devidx = 4, offset = 2ca7c00, size = 200 devidx = 5, offset = 2ca7c00, size = 200 devidx = 0, offset = 2ca7e00, size = 200 devidx = 1, offset = 2ca7e00, size = 200 [root@gandalf ~]# ./raidzmap glamdring:0:10bf0000:20000 Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2 devidx = 0, offset = 2ca8000, size = 8000 devidx = 1, offset = 2ca8000, size = 8000 devidx = 2, offset = 2ca8000, size = 8000 devidx = 3, offset = 2ca8000, size = 8000 devidx = 4, offset = 2ca8000, size = 8000 devidx = 5, offset = 2ca8000, size = 8000 [root@gandalf ~]# ./raidzmap glamdring:0:10c30000:20000 Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2 devidx = 2, offset = 2cb2a00, size = 8000 devidx = 3, offset = 2cb2a00, size = 8000 devidx = 4, offset = 2cb2a00, size = 8000 devidx = 5, offset = 2cb2a00, size = 8000 devidx = 0, offset = 2cb2c00, size = 8000 devidx = 1, offset = 2cb2c00, size = 8000 [root@gandalf ~]# ./raidzmap glamdring:0:10c70000:20000 Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2 devidx = 4, offset = 2cbd400, size = 8000 devidx = 5, offset = 2cbd400, size = 8000 devidx = 0, offset = 2cbd600, size = 8000 devidx = 1, offset = 2cbd600, size = 8000 devidx = 2, offset = 2cbd600, size = 8000 devidx = 3, offset = 2cbd600, size = 8000 Matt