From owner-freebsd-fs@FreeBSD.ORG Sun Apr 1 04:31:23 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3100106566C; Sun, 1 Apr 2012 04:31:23 +0000 (UTC) (envelope-from pgollucci@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8483B8FC08; Sun, 1 Apr 2012 04:31:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q314VNiL079232; Sun, 1 Apr 2012 04:31:23 GMT (envelope-from pgollucci@freefall.freebsd.org) Received: (from pgollucci@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q314VNYu079228; Sun, 1 Apr 2012 04:31:23 GMT (envelope-from pgollucci) Date: Sun, 1 Apr 2012 04:31:23 GMT Message-Id: <201204010431.q314VNYu079228@freefall.freebsd.org> To: pgollucci@FreeBSD.org, pgollucci@FreeBSD.org, freebsd-fs@FreeBSD.org From: pgollucci@FreeBSD.org Cc: Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device 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: Sun, 01 Apr 2012 04:31:23 -0000 Synopsis: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device State-Changed-From-To: closed->open State-Changed-By: pgollucci State-Changed-When: Sun Apr 1 04:30:46 UTC 2012 State-Changed-Why: re-open http://www.freebsd.org/cgi/query-pr.cgi?pr=155411 From owner-freebsd-fs@FreeBSD.ORG Sun Apr 1 07:40:17 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6B8C1065670 for ; Sun, 1 Apr 2012 07:40:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 98AA88FC0A for ; Sun, 1 Apr 2012 07:40:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q317eHXv076472 for ; Sun, 1 Apr 2012 07:40:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q317eHiP076471; Sun, 1 Apr 2012 07:40:17 GMT (envelope-from gnats) Date: Sun, 1 Apr 2012 07:40:17 GMT Message-Id: <201204010740.q317eHiP076471@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Jaakko Heinonen Cc: Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaakko Heinonen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 07:40:17 -0000 The following reply was made to PR kern/155411; it has been noted by GNATS. From: Jaakko Heinonen To: pgollucci@FreeBSD.org Cc: bug-followup@FreeBSD.org, delphij@FreeBSD.org Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device Date: Sun, 1 Apr 2012 10:37:28 +0300 It seems that r227802 hasn't been MFCd to stable/9. Can you test with the head version or apply r227802 to stable/9? -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Sun Apr 1 21:06:17 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D31181065672; Sun, 1 Apr 2012 21:06:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ED4AA8FC19; Sun, 1 Apr 2012 21:06:16 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA16068; Mon, 02 Apr 2012 00:06:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SERyS-000DEq-FQ; Mon, 02 Apr 2012 00:06:08 +0300 Message-ID: <4F78C33D.7080708@FreeBSD.org> Date: Mon, 02 Apr 2012 00:06:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Edward Tomasz Napierala X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: ls NFSv4 is not perfect 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: Sun, 01 Apr 2012 21:06:17 -0000 It seems that aclmode() function in bin/ls/print.c caches ACL support properties of a filesystem. Unfortunately this optimization doesn't always work. An example: a UFS directory unionfs-mounted over ZFS directory. Files that reside in ZFS and are not shadowed by UFS do have ACL_NFS4 stuff, files in UFS don't have it. An example of ls -l behavior in this case: -rw-r--r-- 1 mrtg mrtg 3881 1 Apr 06:55 corevoltages-year.png -rw-r--r-- 1 mrtg mrtg 5605 1 Apr 06:55 userload-year.png -rw-r--r-- 1 mrtg mrtg 2782 1 Apr 06:55 uptime-year.png ls: /var/www/stats/mrtg/cpufreq.old: Operation not supported -rw-r--r-- 1 mrtg mrtg 61200 1 Apr 23:00 cpufreq.old ls: /var/www/stats/mrtg/irqrate.old: Operation not supported -rw-r--r-- 1 mrtg mrtg 55538 1 Apr 23:00 irqrate.old ls: /var/www/stats/mrtg/cpuload.old: Operation not supported -rw-r--r-- 1 mrtg mrtg 58826 1 Apr 23:00 cpuload.old ls: /var/www/stats/mrtg/cpuload2.old: Operation not supported The older files are in ZFS, the newer are in UFS. ktrace, just in case: CALL __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000) NAMI "/var/www/stats/mrtg/uptime.html" RET __acl_get_link 0 CALL write(0x1,0x8010be000,0x3b) ... CALL __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000) NAMI "/var/www/stats/mrtg/xxx" RET __acl_get_link -1 errno 45 Operation not supported Not sure what's the best approach here. Maybe just silence this particular error code? P.S. I know, an untypical case :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 00:54:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4225D106566B; Mon, 2 Apr 2012 00:54:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7848FC1D; Mon, 2 Apr 2012 00:54:23 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EACn4eE+DaFvO/2dsb2JhbABDhVSwLoQPghAjBFJEGQIEVQaIHK0liROQBIEYBI5ohnmQL4MD X-IronPort-AV: E=Sophos;i="4.75,354,1330923600"; d="scan'208";a="163247868" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 01 Apr 2012 20:54:17 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 199DDB3FCC; Sun, 1 Apr 2012 20:54:17 -0400 (EDT) Date: Sun, 1 Apr 2012 20:54:17 -0400 (EDT) From: Rick Macklem To: FS List Message-ID: <1184428460.2076443.1333328057090.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <302424888.2076325.1333327897003.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2076442_2065523745.1333328057088" X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: alc@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: RFC: which patch is preferred for fix to PR#165923 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: Mon, 02 Apr 2012 00:54:24 -0000 ------=_Part_2076442_2065523745.1333328057088 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit First, a little background w.r.t. an offlist discussion of PR# 165923. A critical part of the problem reported is the credentials used to to the Write RPCs in the NFS client's VOP_PUTPAGES(). Currently the code simply uses the credentials of the thread that called VOP_PUTPAGES(), which is often incorrect, especially when the caller is "root" and the NFS server is doing "root squashing" (ie mapping root->nobody or similar). Although there is no correct answer w.r.t. what credentials should be used, there seemed to be rough consensus that the credentials of the process that did the mmap() call would be best. (If there are multiple writers, you could use either the 1st or most recent mmap(), but since all writers had write permissions at open(), I don't think it matters much which you use, but others can comment on this.) However, there seems to be some disagreement as to how a patch to use the mmap() credentials should be done. putpages-a.patch - This one captures the credentials during the mmap() call by using the property that only mmap() calls vnode_pager_alloc() with "prot != 0" and references them in a new field in vm_object_t. putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() call, which is done by mmap(). For all file systems except NFS clients, it is a null op. For the NFS clients, they reference the credentials in a new field of the NFS specific part of the vnode. - I don't have a patch for the third one, but I believe Joel was proposing something similar to putpages-a.patch, except that the credentials are passed as an extra argument to VOP_PUTPAGES(), instead of the NFS client's VOP_PUTPAGES() looking in the vnode's vm_object_t for the cred. I've attached the first 2, in case anyone wants to look at them. Here's my take on the advantages/disadvantages of each patch: Advantages Disadvantages patch-a simple, doesn't require VOP changes and, therefore, can be MFC'd easily saves a largely NFS specific item in vm_object_t depends on the fact that only mmap() calls vnode_pager_alloc() with prot != 0 patch-b basically has the advantages/disadvantages of patch1 reversed, although it is pretty simple, too patch3 although it sounds cleaner to pass "cred" as an extra argument to VOP_PUTPAGES(), that makes it iffy (I'll let Joel discuss this) to MFC Sorry this was so long winded, but I figured it needed some explanation. I am hoping others have opinions w.r.t. which patch is more appropriate and that it comes to a rough consensus, so I'll know which one to prepare for a commit to head (and possible MFC). Hopefully Joel and Kostik will post, explaining their preferences. (Alternately, if they give me permission, I can re-post their previous offlist comments.) Thanks in advance for any comments on this, rick ------=_Part_2076442_2065523745.1333328057088 Content-Type: text/x-patch; name=putpages-a.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=putpages-a.patch LS0tIHZtL3Zub2RlX3BhZ2VyLmMuc2F2CTIwMTItMDMtMTMgMjA6MjM6MDMuMDAwMDAwMDAwIC0w NDAwCisrKyB2bS92bm9kZV9wYWdlci5jCTIwMTItMDMtMTUgMDk6NDE6MDIuMDAwMDAwMDAwIC0w NDAwCkBAIC02Miw2ICs2Miw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRDogcHJvamVjdHMvbmZzdjQu MS1jbGkKICNpbmNsdWRlIDxzeXMvYnVmLmg+CiAjaW5jbHVkZSA8c3lzL3ZtbWV0ZXIuaD4KICNp bmNsdWRlIDxzeXMvbGltaXRzLmg+CisjaW5jbHVkZSA8c3lzL21tYW4uaD4KICNpbmNsdWRlIDxz eXMvY29uZi5oPgogI2luY2x1ZGUgPHN5cy9zZl9idWYuaD4KIApAQCAtMjIzLDYgKzIyNCwxMCBA QCByZXRyeToKIAogCQlvYmplY3QtPnVuX3BhZ2VyLnZucC52bnBfc2l6ZSA9IHNpemU7CiAJCW9i amVjdC0+dW5fcGFnZXIudm5wLndyaXRlbWFwcGluZ3MgPSAwOworCQlpZiAoKHByb3QgJiBQUk9U X1dSSVRFKSAhPSAwKQorCQkJb2JqZWN0LT51bl9wYWdlci52bnAuY3JlZCA9IGNyaG9sZChjcmVk KTsKKwkJZWxzZQorCQkJb2JqZWN0LT51bl9wYWdlci52bnAuY3JlZCA9IE5VTEw7CiAKIAkJb2Jq ZWN0LT5oYW5kbGUgPSBoYW5kbGU7CiAJCVZJX0xPQ0sodnApOwpAQCAtMjM4LDYgKzI0Myw5IEBA IHJldHJ5OgogCQlWSV9VTkxPQ0sodnApOwogCX0gZWxzZSB7CiAJCW9iamVjdC0+cmVmX2NvdW50 Kys7CisJCWlmIChvYmplY3QtPnVuX3BhZ2VyLnZucC5jcmVkID09IE5VTEwgJiYKKwkJICAgIChw cm90ICYgUFJPVF9XUklURSkgIT0gMCkKKwkJCW9iamVjdC0+dW5fcGFnZXIudm5wLmNyZWQgPSBj cmhvbGQoY3JlZCk7CiAJCVZNX09CSkVDVF9VTkxPQ0sob2JqZWN0KTsKIAl9CiAJdnJlZih2cCk7 CkBAIC0yNTMsNiArMjYxLDcgQEAgdm5vZGVfcGFnZXJfZGVhbGxvYyhvYmplY3QpCiB7CiAJc3Ry dWN0IHZub2RlICp2cDsKIAlpbnQgcmVmczsKKwlzdHJ1Y3QgdWNyZWQgKmNyZWQ7CiAKIAl2cCA9 IG9iamVjdC0+aGFuZGxlOwogCWlmICh2cCA9PSBOVUxMKQpAQCAtMjY0LDYgKzI3Myw4IEBAIHZu b2RlX3BhZ2VyX2RlYWxsb2Mob2JqZWN0KQogCiAJb2JqZWN0LT5oYW5kbGUgPSBOVUxMOwogCW9i amVjdC0+dHlwZSA9IE9CSlRfREVBRDsKKwljcmVkID0gb2JqZWN0LT51bl9wYWdlci52bnAuY3Jl ZDsKKwlvYmplY3QtPnVuX3BhZ2VyLnZucC5jcmVkID0gTlVMTDsKIAlpZiAob2JqZWN0LT5mbGFn cyAmIE9CSl9ESVNDT05ORUNUV05UKSB7CiAJCXZtX29iamVjdF9jbGVhcl9mbGFnKG9iamVjdCwg T0JKX0RJU0NPTk5FQ1RXTlQpOwogCQl3YWtldXAob2JqZWN0KTsKQEAgLTI3Niw2ICsyODcsOCBA QCB2bm9kZV9wYWdlcl9kZWFsbG9jKG9iamVjdCkKIAl2cC0+dl9vYmplY3QgPSBOVUxMOwogCXZw LT52X3ZmbGFnICY9IH5WVl9URVhUOwogCVZNX09CSkVDVF9VTkxPQ0sob2JqZWN0KTsKKwlpZiAo Y3JlZCAhPSBOVUxMKQorCQljcmZyZWUoY3JlZCk7CiAJd2hpbGUgKHJlZnMtLSA+IDApCiAJCXZ1 bnJlZih2cCk7CiAJVk1fT0JKRUNUX0xPQ0sob2JqZWN0KTsKLS0tIHZtL3ZtX29iamVjdC5oLnNh dgkyMDEyLTAzLTEzIDIwOjIxOjI2LjAwMDAwMDAwMCAtMDQwMAorKysgdm0vdm1fb2JqZWN0LmgJ MjAxMi0wMy0xMyAyMDoyNzowNC4wMDAwMDAwMDAgLTA0MDAKQEAgLTEwOSwxMCArMTA5LDEyIEBA IHN0cnVjdCB2bV9vYmplY3QgewogCQkgKiBWTm9kZSBwYWdlcgogCQkgKgogCQkgKgl2bnBfc2l6 ZSAtIGN1cnJlbnQgc2l6ZSBvZiBmaWxlCisJCSAqCWNyZWQgLSBjcmVkZW50aWFscyBmb3IgTkZT IEkvTwogCQkgKi8KIAkJc3RydWN0IHsKIAkJCW9mZl90IHZucF9zaXplOwogCQkJdm1fb29mZnNl dF90IHdyaXRlbWFwcGluZ3M7CisJCQlzdHJ1Y3QgdWNyZWQgKmNyZWQ7CiAJCX0gdm5wOwogCiAJ CS8qCi0tLSBuZnNjbGllbnQvbmZzX2Jpby5jLnNhdgkyMDEyLTAzLTEzIDIwOjUzOjIwLjAwMDAw MDAwMCAtMDQwMAorKysgbmZzY2xpZW50L25mc19iaW8uYwkyMDEyLTAzLTE1IDA5OjU4OjEzLjAw MDAwMDAwMCAtMDQwMApAQCAtMjcxLDExICsyNzEsMTEgQEAgbmZzX3B1dHBhZ2VzKHN0cnVjdCB2 b3BfcHV0cGFnZXNfYXJncyAqYQogCXN0cnVjdCBuZnNtb3VudCAqbm1wOwogCXN0cnVjdCBuZnNu b2RlICpucDsKIAl2bV9wYWdlX3QgKnBhZ2VzOworCXZtX29iamVjdF90IG9iamVjdDsKIAogCXZw ID0gYXAtPmFfdnA7CiAJbnAgPSBWVE9ORlModnApOwogCXRkID0gY3VydGhyZWFkOwkJCQkvKiBY WFggKi8KLQljcmVkID0gY3VydGhyZWFkLT50ZF91Y3JlZDsJCS8qIFhYWCAqLwogCW5tcCA9IFZG U1RPTkZTKHZwLT52X21vdW50KTsKIAlwYWdlcyA9IGFwLT5hX207CiAJY291bnQgPSBhcC0+YV9j b3VudDsKQEAgLTI4Myw2ICsyODMsMTkgQEAgbmZzX3B1dHBhZ2VzKHN0cnVjdCB2b3BfcHV0cGFn ZXNfYXJncyAqYQogCW5wYWdlcyA9IGJ0b2MoY291bnQpOwogCW9mZnNldCA9IElEWF9UT19PRkYo cGFnZXNbMF0tPnBpbmRleCk7CiAJCisJaWYgKChvYmplY3QgPSB2cC0+dl9vYmplY3QpID09IE5V TEwpIHsKKwkJbmZzX3ByaW50ZigibmZzX3B1dHBhZ2VzOiBjYWxsZWQgd2l0aCBub24tbWVyZ2Vk IGNhY2hlIHZub2RlPz9cbiIpOworCQlyZXR1cm4gKFZNX1BBR0VSX0VSUk9SKTsKKwl9CisJLyoK KwkgKiBJIGRvbid0IHRoaW5rIGFjcXVpcmluZyBhIHJlZmVyZW5jZSBjb3VudCBvbiBjcmVkIGlz IHJlcXVpcmVkIGhlcmUsCisJICogYnV0IGRvIGl0IGFueWhvdywganVzdCBpbiBjYXNlLgorCSAq LworCWlmIChvYmplY3QtPnVuX3BhZ2VyLnZucC5jcmVkICE9IE5VTEwpCisJCWNyZWQgPSBjcmhv bGQob2JqZWN0LT51bl9wYWdlci52bnAuY3JlZCk7CisJZWxzZQorCQljcmVkID0gY3Job2xkKGN1 cnRocmVhZC0+dGRfdWNyZWQpOwkvKiBYWFggKi8KKwogCW10eF9sb2NrKCZubXAtPm5tX210eCk7 CiAJaWYgKChubXAtPm5tX2ZsYWcgJiBORlNNTlRfTkZTVjMpICE9IDAgJiYKIAkgICAgKG5tcC0+ bm1fc3RhdGUgJiBORlNTVEFfR09URlNJTkZPKSA9PSAwKSB7CkBAIC0zMzksNiArMzUyLDcgQEAg bmZzX3B1dHBhZ2VzKHN0cnVjdCB2b3BfcHV0cGFnZXNfYXJncyAqYQogCSAgICBpb21vZGUgPSBO RlNWM1dSSVRFX0ZJTEVTWU5DOwogCiAJZXJyb3IgPSAobm1wLT5ubV9ycGNvcHMtPm5yX3dyaXRl cnBjKSh2cCwgJnVpbywgY3JlZCwgJmlvbW9kZSwgJm11c3RfY29tbWl0KTsKKwljcmZyZWUoY3Jl ZCk7CiAKIAlwbWFwX3FyZW1vdmUoa3ZhLCBucGFnZXMpOwogCXJlbHBidWYoYnAsICZuZnNfcGJ1 Zl9mcmVlY250KTsKLS0tIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYy5zYXYJMjAxMi0wMy0xMyAy MDozMjo0OC4wMDAwMDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYwkyMDEy LTAzLTE1IDA5OjU4OjQzLjAwMDAwMDAwMCAtMDQwMApAQCAtMjc2LDExICsyNzYsMTEgQEAgbmNs X3B1dHBhZ2VzKHN0cnVjdCB2b3BfcHV0cGFnZXNfYXJncyAqYQogCXN0cnVjdCBuZnNtb3VudCAq bm1wOwogCXN0cnVjdCBuZnNub2RlICpucDsKIAl2bV9wYWdlX3QgKnBhZ2VzOworCXZtX29iamVj dF90IG9iamVjdDsKIAogCXZwID0gYXAtPmFfdnA7CiAJbnAgPSBWVE9ORlModnApOwogCXRkID0g Y3VydGhyZWFkOwkJCQkvKiBYWFggKi8KLQljcmVkID0gY3VydGhyZWFkLT50ZF91Y3JlZDsJCS8q IFhYWCAqLwogCW5tcCA9IFZGU1RPTkZTKHZwLT52X21vdW50KTsKIAlwYWdlcyA9IGFwLT5hX207 CiAJY291bnQgPSBhcC0+YV9jb3VudDsKQEAgLTI4OCw2ICsyODgsMTkgQEAgbmNsX3B1dHBhZ2Vz KHN0cnVjdCB2b3BfcHV0cGFnZXNfYXJncyAqYQogCW5wYWdlcyA9IGJ0b2MoY291bnQpOwogCW9m ZnNldCA9IElEWF9UT19PRkYocGFnZXNbMF0tPnBpbmRleCk7CiAJCisJaWYgKChvYmplY3QgPSB2 cC0+dl9vYmplY3QpID09IE5VTEwpIHsKKwkJbmNsX3ByaW50ZigibmZzX3B1dHBhZ2VzOiBjYWxs ZWQgd2l0aCBub24tbWVyZ2VkIGNhY2hlIHZub2RlPz9cbiIpOworCQlyZXR1cm4gKFZNX1BBR0VS X0VSUk9SKTsKKwl9CisJLyoKKwkgKiBJIGRvbid0IHRoaW5rIGFjcXVpcmluZyBhIHJlZmVyZW5j ZSBjb3VudCBvbiBjcmVkIGlzIHJlcXVpcmVkIGhlcmUsCisJICogYnV0IGRvIGl0IGFueWhvdywg anVzdCBpbiBjYXNlLgorCSAqLworCWlmIChvYmplY3QtPnVuX3BhZ2VyLnZucC5jcmVkICE9IE5V TEwpCisJCWNyZWQgPSBjcmhvbGQob2JqZWN0LT51bl9wYWdlci52bnAuY3JlZCk7CisJZWxzZQor CQljcmVkID0gY3Job2xkKGN1cnRocmVhZC0+dGRfdWNyZWQpOwkvKiBYWFggKi8KKwogCW10eF9s b2NrKCZubXAtPm5tX210eCk7CiAJaWYgKChubXAtPm5tX2ZsYWcgJiBORlNNTlRfTkZTVjMpICE9 IDAgJiYKIAkgICAgKG5tcC0+bm1fc3RhdGUgJiBORlNTVEFfR09URlNJTkZPKSA9PSAwKSB7CkBA IC0zNDQsNiArMzU3LDcgQEAgbmNsX3B1dHBhZ2VzKHN0cnVjdCB2b3BfcHV0cGFnZXNfYXJncyAq YQogCSAgICBpb21vZGUgPSBORlNXUklURV9GSUxFU1lOQzsKIAogCWVycm9yID0gbmNsX3dyaXRl cnBjKHZwLCAmdWlvLCBjcmVkLCAmaW9tb2RlLCAmbXVzdF9jb21taXQsIDApOworCWNyZnJlZShj cmVkKTsKIAogCXBtYXBfcXJlbW92ZShrdmEsIG5wYWdlcyk7CiAJcmVscGJ1ZihicCwgJm5jbF9w YnVmX2ZyZWVjbnQpOwo= ------=_Part_2076442_2065523745.1333328057088 Content-Type: text/x-patch; name=putpages-b.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=putpages-b.patch LS0tIG5mc2NsaWVudC9uZnNfdm5vcHMuYy5zYXYJMjAxMi0wMy0yMiAyMDowMTowNy4wMDAwMDAw MDAgLTA0MDAKKysrIG5mc2NsaWVudC9uZnNfdm5vcHMuYwkyMDEyLTAzLTIyIDIwOjM0OjQxLjAw MDAwMDAwMCAtMDQwMApAQCAtNTMsNiArNTMsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IGhlYWQv c3lzL25mc2NsaWVudC9uCiAjaW5jbHVkZSA8c3lzL2phaWwuaD4KICNpbmNsdWRlIDxzeXMvbWFs bG9jLmg+CiAjaW5jbHVkZSA8c3lzL21idWYuaD4KKyNpbmNsdWRlIDxzeXMvbW1hbi5oPgogI2lu Y2x1ZGUgPHN5cy9uYW1laS5oPgogI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KICNpbmNsdWRlIDxz eXMvdm5vZGUuaD4KQEAgLTE0Nyw2ICsxNDgsNyBAQCBzdGF0aWMgdm9wX3JlYWRsaW5rX3QJbmZz X3JlYWRsaW5rOwogc3RhdGljIHZvcF9wcmludF90CW5mc19wcmludDsKIHN0YXRpYyB2b3BfYWR2 bG9ja190CW5mc19hZHZsb2NrOwogc3RhdGljIHZvcF9hZHZsb2NrYXN5bmNfdCBuZnNfYWR2bG9j a2FzeW5jOworc3RhdGljIHZvcF9tbWFwX25vdGlmeV90IG5mc19tbWFwX25vdGlmeTsKIAogLyoK ICAqIEdsb2JhbCB2ZnMgZGF0YSBzdHJ1Y3R1cmVzIGZvciBuZnMKQEAgLTE4MCw2ICsxODIsNyBA QCBzdHJ1Y3Qgdm9wX3ZlY3RvciBuZnNfdm5vZGVvcHMgPSB7CiAJLnZvcF9zdHJhdGVneSA9CQlu ZnNfc3RyYXRlZ3ksCiAJLnZvcF9zeW1saW5rID0JCW5mc19zeW1saW5rLAogCS52b3Bfd3JpdGUg PQkJbmZzX3dyaXRlLAorCS52b3BfbW1hcF9ub3RpZnkgPQluZnNfbW1hcF9ub3RpZnksCiB9Owog CiBzdHJ1Y3Qgdm9wX3ZlY3RvciBuZnNfZmlmb29wcyA9IHsKQEAgLTM1MjUsMyArMzUyOCwxNCBA QCBzdHJ1Y3QgYnVmX29wcyBidWZfb3BzX25mcyA9IHsKIAkuYm9wX3N5bmMJPQlidWZzeW5jLAog CS5ib3BfYmRmbHVzaAk9CWJ1ZmJkZmx1c2gsCiB9OworCitzdGF0aWMgaW50CituZnNfbW1hcF9u b3RpZnkoc3RydWN0IHZvcF9tbWFwX25vdGlmeV9hcmdzICphcCkKK3sKKwlzdHJ1Y3QgbmZzbm9k ZSAqbnAgPSBWVE9ORlMoYXAtPmFfdnApOworCisJaWYgKG5wLT5uX3BwY3JlZCA9PSBOVUxMICYm IChhcC0+YV9wcm90ICYgUFJPVF9XUklURSkgIT0gMCkKKwkJbnAtPm5fcHBjcmVkID0gY3Job2xk KGFwLT5hX2NyZWQpOworCXJldHVybiAoMCk7Cit9CisKLS0tIG5mc2NsaWVudC9uZnNub2RlLmgu c2F2CTIwMTItMDMtMjIgMjA6MDU6MDcuMDAwMDAwMDAwIC0wNDAwCisrKyBuZnNjbGllbnQvbmZz bm9kZS5oCTIwMTItMDMtMjIgMjA6MDY6MDAuMDAwMDAwMDAwIC0wNDAwCkBAIC0xMjgsNiArMTI4 LDcgQEAgc3RydWN0IG5mc25vZGUgewogCXVpbnQzMl90CQluX25hbWVsZW47CiAJaW50CQkJbl9k aXJlY3Rpb19vcGVuczsKIAlpbnQgICAgICAgICAgICAgICAgICAgICBuX2RpcmVjdGlvX2FzeW5j d3I7CisJc3RydWN0IHVjcmVkCQkqbl9wcGNyZWQ7CS8qIENyZWQuIGZvciBwdXRwYWdlcyAqLwog fTsKIAogI2RlZmluZSBuX2F0aW0JCW5fdW4xLm5mX2F0aW0KLS0tIG5mc2NsaWVudC9uZnNfbm9k ZS5jLnNhdgkyMDEyLTAzLTIyIDIwOjA2OjA5LjAwMDAwMDAwMCAtMDQwMAorKysgbmZzY2xpZW50 L25mc19ub2RlLmMJMjAxMi0wMy0yMiAyMDowNzowNC4wMDAwMDAwMDAgLTA0MDAKQEAgLTIwOCw2 ICsyMDgsNyBAQCBuZnNfaW5hY3RpdmUoc3RydWN0IHZvcF9pbmFjdGl2ZV9hcmdzICphCiAJc3Ry dWN0IG5mc25vZGUgKm5wOwogCXN0cnVjdCBzaWxseXJlbmFtZSAqc3A7CiAJc3RydWN0IHRocmVh ZCAqdGQgPSBjdXJ0aHJlYWQ7CS8qIFhYWCAqLworCXN0cnVjdCB1Y3JlZCAqY3JlZDsKIAogCW5w ID0gVlRPTkZTKGFwLT5hX3ZwKTsKIAltdHhfbG9jaygmbnAtPm5fbXR4KTsKQEAgLTIyOSw3ICsy MzAsMTEgQEAgbmZzX2luYWN0aXZlKHN0cnVjdCB2b3BfaW5hY3RpdmVfYXJncyAqYQogCQltdHhf bG9jaygmbnAtPm5fbXR4KTsKIAl9CiAJbnAtPm5fZmxhZyAmPSBOTU9ESUZJRUQ7CisJY3JlZCA9 IG5wLT5uX3BwY3JlZDsKKwlucC0+bl9wcGNyZWQgPSBOVUxMOwogCW10eF91bmxvY2soJm5wLT5u X210eCk7CisJaWYgKGNyZWQgIT0gTlVMTCkKKwkJY3JmcmVlKGNyZWQpOwogCXJldHVybiAoMCk7 CiB9CiAKQEAgLTI3MCw2ICsyNzUsOCBAQCBuZnNfcmVjbGFpbShzdHJ1Y3Qgdm9wX3JlY2xhaW1f YXJncyAqYXApCiAJCQlmcmVlKChjYWRkcl90KWRwMiwgTV9ORlNESVJPRkYpOwogCQl9CiAJfQor CWlmIChucC0+bl9wcGNyZWQgIT0gTlVMTCkKKwkJY3JmcmVlKG5wLT5uX3BwY3JlZCk7CiAJaWYg KG5wLT5uX2Zoc2l6ZSA+IE5GU19TTUFMTEZIKSB7CiAJCWZyZWUoKGNhZGRyX3QpbnAtPm5fZmhw LCBNX05GU0JJR0ZIKTsKIAl9Ci0tLSBuZnNjbGllbnQvbmZzX2Jpby5jLnNhdgkyMDEyLTAzLTIy IDIwOjExOjA0LjAwMDAwMDAwMCAtMDQwMAorKysgbmZzY2xpZW50L25mc19iaW8uYwkyMDEyLTAz LTIyIDIwOjQwOjEzLjAwMDAwMDAwMCAtMDQwMApAQCAtMjk5LDYgKzI5OSw5IEBAIG5mc19wdXRw YWdlcyhzdHJ1Y3Qgdm9wX3B1dHBhZ2VzX2FyZ3MgKmEKIAkJbXR4X2xvY2soJm5wLT5uX210eCk7 CiAJfQogCisJLyogU2V0IHRoZSBjcmVkIHRvIG5fcHBjcmVkIGZvciB0aGUgd3JpdGUgcnBjcy4g Ki8KKwlpZiAobnAtPm5fcHBjcmVkICE9IE5VTEwpCisJCWNyZWQgPSBucC0+bl9wcGNyZWQ7CiAJ Zm9yIChpID0gMDsgaSA8IG5wYWdlczsgaSsrKQogCQlydHZhbHNbaV0gPSBWTV9QQUdFUl9FUlJP UjsKIAotLS0ga2Vybi92bm9kZV9pZi5zcmMuc2F2CTIwMTItMDMtMjIgMTA6MTg6MDAuMDAwMDAw MDAwIC0wNDAwCisrKyBrZXJuL3Zub2RlX2lmLnNyYwkyMDEyLTAzLTIyIDEwOjM4OjU0LjAwMDAw MDAwMCAtMDQwMApAQCAtNjYwLDYgKzY2MCwxNiBAQCB2b3BfdW5wX2RldGFjaCB7CiAJSU4gc3Ry dWN0IHZub2RlICp2cDsKIH07CiAKKyUlIG1tYXBfbm90aWZ5CXZwCUwgTCBMCisKK3ZvcF9tbWFw X25vdGlmeSB7CisJSU4gc3RydWN0IHZub2RlICp2cDsKKwlJTiB2bV9vZmZzZXRfdCBmb2ZmOwor CUlOIGludCBmbGFnczsKKwlJTiB2bV9wcm90X3QgcHJvdDsKKwlJTiBzdHJ1Y3QgdWNyZWQgKmNy ZWQ7Cit9OworCiAjIFRoZSBWT1BzIGJlbG93IGFyZSBzcGFyZXMgYXQgdGhlIGVuZCBvZiB0aGUg dGFibGUgdG8gYWxsb3cgbmV3IFZPUHMgdG8gYmUKICMgYWRkZWQgaW4gc3RhYmxlIGJyYW5jaGVz IHdpdGhvdXQgYnJlYWtpbmcgdGhlIEtCSS4gIE5ldyBWT1BzIGluIEhFQUQgc2hvdWxkCiAjIGJl IGFkZGVkIGFib3ZlIHRoZXNlIHNwYXJlcy4gIFdoZW4gbWVyZ2luZyBhIG5ldyBWT1AgdG8gYSBz dGFibGUgYnJhbmNoLAotLS0ga2Vybi92ZnNfZGVmYXVsdC5jLnNhdgkyMDEyLTAzLTIyIDEwOjQy OjA4LjAwMDAwMDAwMCAtMDQwMAorKysga2Vybi92ZnNfZGVmYXVsdC5jCTIwMTItMDMtMjIgMTA6 NDY6NDEuMDAwMDAwMDAwIC0wNDAwCkBAIC0xMjYsNiArMTI2LDcgQEAgc3RydWN0IHZvcF92ZWN0 b3IgZGVmYXVsdF92bm9kZW9wcyA9IHsKIAkudm9wX3VucF9iaW5kID0JCXZvcF9zdGR1bnBfYmlu ZCwKIAkudm9wX3VucF9jb25uZWN0ID0Jdm9wX3N0ZHVucF9jb25uZWN0LAogCS52b3BfdW5wX2Rl dGFjaCA9CXZvcF9zdGR1bnBfZGV0YWNoLAorCS52b3BfbW1hcF9ub3RpZnkgPQlWT1BfTlVMTCwK IH07CiAKIC8qCi0tLSBmcy9uZnNjbGllbnQvbmZzX2Nsdm5vcHMuYy5zYXYJMjAxMi0wMy0yMiAx OTo0NToyMi4wMDAwMDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2x2bm9wcy5jCTIw MTItMDMtMjIgMjA6MzU6MTEuMDAwMDAwMDAwIC0wNDAwCkBAIC00Nyw2ICs0Nyw3IEBAIF9fRkJT RElEKCIkRnJlZUJTRDogaGVhZC9zeXMvZnMvbmZzY2xpZW4KICNpbmNsdWRlIDxzeXMvc3lzdG0u aD4KICNpbmNsdWRlIDxzeXMvcmVzb3VyY2V2YXIuaD4KICNpbmNsdWRlIDxzeXMvcHJvYy5oPgor I2luY2x1ZGUgPHN5cy9tbWFuLmg+CiAjaW5jbHVkZSA8c3lzL21vdW50Lmg+CiAjaW5jbHVkZSA8 c3lzL2Jpby5oPgogI2luY2x1ZGUgPHN5cy9idWYuaD4KQEAgLTE1MCw2ICsxNTEsNyBAQCBzdGF0 aWMgdm9wX2FkdmxvY2tfdAluZnNfYWR2bG9jazsKIHN0YXRpYyB2b3BfYWR2bG9ja2FzeW5jX3Qg bmZzX2FkdmxvY2thc3luYzsKIHN0YXRpYyB2b3BfZ2V0YWNsX3QgbmZzX2dldGFjbDsKIHN0YXRp YyB2b3Bfc2V0YWNsX3QgbmZzX3NldGFjbDsKK3N0YXRpYyB2b3BfbW1hcF9ub3RpZnlfdCBuZnNf bW1hcF9ub3RpZnk7CiAKIC8qCiAgKiBHbG9iYWwgdmZzIGRhdGEgc3RydWN0dXJlcyBmb3IgbmZz CkBAIC0xODcsNiArMTg5LDcgQEAgc3RydWN0IHZvcF92ZWN0b3IgbmV3bmZzX3Zub2Rlb3BzID0g ewogCS52b3Bfd3JpdGUgPQkJbmNsX3dyaXRlLAogCS52b3BfZ2V0YWNsID0JCW5mc19nZXRhY2ws CiAJLnZvcF9zZXRhY2wgPQkJbmZzX3NldGFjbCwKKwkudm9wX21tYXBfbm90aWZ5ID0JbmZzX21t YXBfbm90aWZ5LAogfTsKIAogc3RydWN0IHZvcF92ZWN0b3IgbmV3bmZzX2ZpZm9vcHMgPSB7CkBA IC0zNDc0LDMgKzM0NzcsMTMgQEAgbmZzX3BhdGhjb25mKHN0cnVjdCB2b3BfcGF0aGNvbmZfYXJn cyAqYQogCXJldHVybiAoZXJyb3IpOwogfQogCitzdGF0aWMgaW50CituZnNfbW1hcF9ub3RpZnko c3RydWN0IHZvcF9tbWFwX25vdGlmeV9hcmdzICphcCkKK3sKKwlzdHJ1Y3QgbmZzbm9kZSAqbnAg PSBWVE9ORlMoYXAtPmFfdnApOworCisJaWYgKG5wLT5uX3BwY3JlZCA9PSBOVUxMICYmIChhcC0+ YV9wcm90ICYgUFJPVF9XUklURSkgIT0gMCkKKwkJbnAtPm5fcHBjcmVkID0gY3Job2xkKGFwLT5h X2NyZWQpOworCXJldHVybiAoMCk7Cit9CisKLS0tIGZzL25mc2NsaWVudC9uZnNub2RlLmguc2F2 CTIwMTItMDMtMjIgMTk6NTI6MzEuMDAwMDAwMDAwIC0wNDAwCisrKyBmcy9uZnNjbGllbnQvbmZz bm9kZS5oCTIwMTItMDMtMjIgMTk6NTM6NTYuMDAwMDAwMDAwIC0wNDAwCkBAIC0xMjMsNiArMTIz LDcgQEAgc3RydWN0IG5mc25vZGUgewogCWludCAgICAgICAgICAgICAgICAgICAgIG5fZGlyZWN0 aW9fYXN5bmN3cjsKIAl1X2ludDY0X3QJCSBuX2NoYW5nZTsJLyogb2xkIENoYW5nZSBhdHRyaWJ1 dGUgKi8KIAlzdHJ1Y3QgbmZzdjRub2RlCSpuX3Y0OwkJLyogZXh0cmEgVjQgc3R1ZmYgKi8KKwlz dHJ1Y3QgdWNyZWQJCSpuX3BwY3JlZDsJLyogQ3JlZC4gZm9yIHB1dHBhZ2VzICovCiB9OwogCiAj ZGVmaW5lCW5fYXRpbQkJbl91bjEubmZfYXRpbQotLS0gZnMvbmZzY2xpZW50L25mc19jbG5vZGUu Yy5zYXYJMjAxMi0wMy0yMiAxOTo1NDo0NC4wMDAwMDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVu dC9uZnNfY2xub2RlLmMJMjAxMi0wMy0yMiAyMDowMDoyOC4wMDAwMDAwMDAgLTA0MDAKQEAgLTIx MCw2ICsyMTAsNyBAQCBuY2xfaW5hY3RpdmUoc3RydWN0IHZvcF9pbmFjdGl2ZV9hcmdzICphCiAJ c3RydWN0IG5mc25vZGUgKm5wOwogCXN0cnVjdCBzaWxseXJlbmFtZSAqc3A7CiAJc3RydWN0IHZu b2RlICp2cCA9IGFwLT5hX3ZwOworCXN0cnVjdCB1Y3JlZCAqY3JlZDsKIAogCW5wID0gVlRPTkZT KHZwKTsKIApAQCAtMjQzLDcgKzI0NCwxMSBAQCBuY2xfaW5hY3RpdmUoc3RydWN0IHZvcF9pbmFj dGl2ZV9hcmdzICphCiAJCW10eF9sb2NrKCZucC0+bl9tdHgpOwogCX0KIAlucC0+bl9mbGFnICY9 IE5NT0RJRklFRDsKKwljcmVkID0gbnAtPm5fcHBjcmVkOworCW5wLT5uX3BwY3JlZCA9IE5VTEw7 CiAJbXR4X3VubG9jaygmbnAtPm5fbXR4KTsKKwlpZiAoY3JlZCAhPSBOVUxMKQorCQljcmZyZWUo Y3JlZCk7CiAJcmV0dXJuICgwKTsKIH0KIApAQCAtMzAwLDYgKzMwNSw4IEBAIG5jbF9yZWNsYWlt KHN0cnVjdCB2b3BfcmVjbGFpbV9hcmdzICphcCkKIAkJCUZSRUUoKGNhZGRyX3QpZHAyLCBNX05G U0RJUk9GRik7CiAJCX0KIAl9CisJaWYgKG5wLT5uX3BwY3JlZCAhPSBOVUxMKQorCQljcmZyZWUo bnAtPm5fcHBjcmVkKTsKIAlGUkVFKChjYWRkcl90KW5wLT5uX2ZocCwgTV9ORlNGSCk7CiAJaWYg KG5wLT5uX3Y0ICE9IE5VTEwpCiAJCUZSRUUoKGNhZGRyX3QpbnAtPm5fdjQsIE1fTkZTVjROT0RF KTsKLS0tIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYy5zYXYJMjAxMi0wMy0yMiAyMDowNzo1Ni4w MDAwMDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYwkyMDEyLTAzLTIyIDIw OjEwOjQ3LjAwMDAwMDAwMCAtMDQwMApAQCAtMzA0LDYgKzMwNCw5IEBAIG5jbF9wdXRwYWdlcyhz dHJ1Y3Qgdm9wX3B1dHBhZ2VzX2FyZ3MgKmEKIAkJbXR4X2xvY2soJm5wLT5uX210eCk7CiAJfQog CisJLyogU2V0IHRoZSBjcmVkIHRvIG5fcHBjcmVkIGZvciB0aGUgd3JpdGUgcnBjcy4gKi8KKwlp ZiAobnAtPm5fcHBjcmVkICE9IE5VTEwpCisJCWNyZWQgPSBucC0+bl9wcGNyZWQ7CiAJZm9yIChp ID0gMDsgaSA8IG5wYWdlczsgaSsrKQogCQlydHZhbHNbaV0gPSBWTV9QQUdFUl9FUlJPUjsKIAot LS0gdm0vdm1fbW1hcC5jLnNhdgkyMDEyLTAzLTIyIDEwOjMzOjIyLjAwMDAwMDAwMCAtMDQwMAor Kysgdm0vdm1fbW1hcC5jCTIwMTItMDMtMjIgMTA6MzY6MzUuMDAwMDAwMDAwIC0wNDAwCkBAIC0x Mjg5LDYgKzEyODksOCBAQCB2bV9tbWFwX3Zub2RlKHN0cnVjdCB0aHJlYWQgKnRkLCB2bV9zaXpl CiAJfQogCWlmICgoZXJyb3IgPSBWT1BfR0VUQVRUUih2cCwgJnZhLCBjcmVkKSkpCiAJCWdvdG8g ZG9uZTsKKwlpZiAoKGVycm9yID0gVk9QX01NQVBfTk9USUZZKHZwLCBmb2ZmLCBmbGFncywgcHJv dCwgY3JlZCkpICE9IDApCisJCWdvdG8gZG9uZTsKICNpZmRlZiBNQUMKIAllcnJvciA9IG1hY192 bm9kZV9jaGVja19tbWFwKGNyZWQsIHZwLCBwcm90LCBmbGFncyk7CiAJaWYgKGVycm9yICE9IDAp Ci0tLSBzeXMvdm5vZGUuaC5zYXYJMjAxMi0wMy0yMiAxMTowMDo0OS4wMDAwMDAwMDAgLTA0MDAK KysrIHN5cy92bm9kZS5oCTIwMTItMDMtMjIgMTE6MDE6MjUuMDAwMDAwMDAwIC0wNDAwCkBAIC00 Myw2ICs0Myw4IEBACiAjaW5jbHVkZSA8c3lzL2FjbC5oPgogI2luY2x1ZGUgPHN5cy9rdHIuaD4K IAorI2luY2x1ZGUgPHZtL3ZtLmg+CisKIC8qCiAgKiBUaGUgdm5vZGUgaXMgdGhlIGZvY3VzIG9m IGFsbCBmaWxlIGFjdGl2aXR5IGluIFVOSVguICBUaGVyZSBpcyBhCiAgKiB1bmlxdWUgdm5vZGUg YWxsb2NhdGVkIGZvciBlYWNoIGFjdGl2ZSBmaWxlLCBlYWNoIGN1cnJlbnQgZGlyZWN0b3J5LAo= ------=_Part_2076442_2065523745.1333328057088-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 01:04:39 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ACB6106564A for ; Mon, 2 Apr 2012 01:04:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 365CE8FC1B for ; Mon, 2 Apr 2012 01:04:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJb6eE+DaFvO/2dsb2JhbABDhVSwLoQPggkBAQUjVhsYAgINGQJZBgojh2+tKIkRgS+JW4R6gRgElWGQL4MDgTg X-IronPort-AV: E=Sophos;i="4.75,354,1330923600"; d="scan'208";a="163248538" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 01 Apr 2012 21:04:38 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 51362B4028; Sun, 1 Apr 2012 21:04:38 -0400 (EDT) Date: Sun, 1 Apr 2012 21:04:38 -0400 (EDT) From: Rick Macklem To: Sven Brandenburg Message-ID: <1428634009.2076834.1333328678316.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F746D8C.8010903@crashme.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv3, ZFS, 10GE performance 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: Mon, 02 Apr 2012 01:04:39 -0000 Sven Brandenburg wrote: > On 03/26/2012 11:47 PM, Rick Macklem wrote: > > MAX_BSIZE is 64kb. I'd like to try making that bigger, but haven't > > gotten > > around to it yet. (If you wanted to try bumping MAX_BSIZE to 128Kb > > on both > > client and server and seeing what happens, that might be > > interesting, since > > my understanding is that ZFS uses a 128Kb block size.) > > I finally came around and tested it (with 256k and 1M) - there is good > and bad news. > The good news is the system does indeed boot (off of zfs at least, no > idea on ufs) and it does increase performance. > I am now seeing roughly 800MB/s off the bat which is quite nice. > The bad news is that I had to use a Linux client because the FreeBSD > client declined to work: > mount_nfs: /mnt, : No buffer space available > > (Although I will freely admit that my knowledge of where to ajdust > this > value is rather limited: What I did was changing MAXBSIZE MAXPHYS to > 1M > in /usr/src/sys/sys/param.h, remaking world+kernel then reboot. > I forgot MAXPHYS in my first try and this crashed the client machine > as > soon as I tried to mount something via nfs. Notably, the server seems > to > be working ok even with a mismatched MAXPHYS/MAXBSIZE). > > So far, the results are very promising. > I did a quick test after rebuilding a kernel with MAXBSIZE set to 131072 and it seemed to work ok. UFS plus NFS. I haven't tried anything larger than 128K. (I don't think you need to change your userland if you are increasing MAXBSIZE just so NFS can do bigger transfers, but I'm not sure;-) Btw, I didn't mean to suggest this as something to do for a production system, but just as a "bleeding edge" experiment, in case you wanted to do so. I don't see a problem with using 64Kb rsize + a readahead of 8. Have fun with it, rick > regards, > Sven From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 06:12:43 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EF0E106566B; Mon, 2 Apr 2012 06:12:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E7D088FC12; Mon, 2 Apr 2012 06:12:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q326Cg0u042618; Mon, 2 Apr 2012 06:12:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q326CgoE042614; Mon, 2 Apr 2012 06:12:42 GMT (envelope-from linimon) Date: Mon, 2 Apr 2012 06:12:42 GMT Message-Id: <201204020612.q326CgoE042614@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166566: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable 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: Mon, 02 Apr 2012 06:12:43 -0000 Old Synopsis: zfs split renders 2 disk (MBR based) mirror unbootable New Synopsis: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 2 06:12:29 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166566 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 06:18:46 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0675C106566B; Mon, 2 Apr 2012 06:18:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CEE538FC08; Mon, 2 Apr 2012 06:18:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q326IjsP044681; Mon, 2 Apr 2012 06:18:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q326IjeR044677; Mon, 2 Apr 2012 06:18:45 GMT (envelope-from linimon) Date: Mon, 2 Apr 2012 06:18:45 GMT Message-Id: <201204020618.q326IjeR044677@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166477: [nfs] NFS data corruption. 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: Mon, 02 Apr 2012 06:18:46 -0000 Old Synopsis: NFS data corruption. New Synopsis: [nfs] NFS data corruption. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 2 06:18:31 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166477 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 07:20:15 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D46C106564A for ; Mon, 2 Apr 2012 07:20:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 184678FC08 for ; Mon, 2 Apr 2012 07:20:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q327KEAj005923 for ; Mon, 2 Apr 2012 07:20:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q327KExo005922; Mon, 2 Apr 2012 07:20:14 GMT (envelope-from gnats) Date: Mon, 2 Apr 2012 07:20:14 GMT Message-Id: <201204020720.q327KExo005922@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/166566: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 07:20:15 -0000 The following reply was made to PR kern/166566; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, hartzell@alerce.com Cc: Subject: Re: kern/166566: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable Date: Mon, 02 Apr 2012 10:15:01 +0300 A few things missing from your port: 1. "Doesn't boot" is quite a poor description in comparison with other details that you provided. You should give more detailed information of the boot failure. 2. gpart information for ada3 3. You don't say which disk ended up as zroot and as zsplitroot after the split. 4. You don't say which disk is configured as a boot disk in BIOS. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 07:30:17 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E542C1065672 for ; Mon, 2 Apr 2012 07:30:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D07278FC0A for ; Mon, 2 Apr 2012 07:30:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q327UHpx031076 for ; Mon, 2 Apr 2012 07:30:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q327UHZ0031075; Mon, 2 Apr 2012 07:30:17 GMT (envelope-from gnats) Date: Mon, 2 Apr 2012 07:30:17 GMT Message-Id: <201204020730.q327UHZ0031075@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Xin LI Cc: Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Xin LI List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 07:30:18 -0000 The following reply was made to PR kern/155411; it has been noted by GNATS. From: Xin LI To: Jaakko Heinonen Cc: pgollucci@FreeBSD.org, bug-followup@FreeBSD.org, delphij@FreeBSD.org Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device Date: Mon, 02 Apr 2012 00:22:37 -0700 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4609570B1C9ADC247DDEA149 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/01/12 00:37, Jaakko Heinonen wrote: >=20 > It seems that r227802 hasn't been MFCd to stable/9. Can you test with > the head version or apply r227802 to stable/9? I've committed a MFC of r227802. This was rejected for stable/9 because it was too late for 9.0-RELEASE but I should have merged it right after 9.0-RELEASE (which I forgot). We have been using this change in production for quite a while now. Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die --------------enig4609570B1C9ADC247DDEA149 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk95U8cACgkQOfuToMruuMCovwCeLwwOEHorCExT8zWTGsLvQ8GU k9IAniGIOvyyO7A80Z3Jnt3z1Scqza4v =qmom -----END PGP SIGNATURE----- --------------enig4609570B1C9ADC247DDEA149-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 09:28:07 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 38766106566B for ; Mon, 2 Apr 2012 09:28:07 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1F38FC15 for ; Mon, 2 Apr 2012 09:28:06 +0000 (UTC) Received: by lagv3 with SMTP id v3so4244810lag.13 for ; Mon, 02 Apr 2012 02:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=Bjn10xEBsoQNyXCpafFSxqzG6tlDwC8T2TC4GOsDx1Y=; b=GTjRlhwfbAvlpu87mopOdCjZNZOH9PkdmulzsDmPOKbDKSW8ZkzSQ8zJ9QwIbR1YSv xO8yYSBq6w8mbY3avayb3vhBkGZhMm45LDOcLrf4tSxIFy93YldQna8UhBrl7nQtaPSP bjCu0506WTLyD/jLlI1W1qiwK7v6ahjntOFFI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=Bjn10xEBsoQNyXCpafFSxqzG6tlDwC8T2TC4GOsDx1Y=; b=TLiFBToXLVZ95DwH1y9VJHRJn8t3qYcGrsMSFYv/Nf0UihX89IgOsaPb1Pqxy7TYE+ GWNPRc0dC1Ek7ynkbkg5VATwLgeqqJ/elmYsthT19r3ttFNIuxO8y0b5Sc3h/FxPhP4P 0/zRaOJtnEE0mtUcvi+f5dvabbpg+UKLEt+UIBNhPxilCRN1TZ5UM56HrdmOELfhal5x i3DpIPDL4izE7KugC3Iq7u5pPrkfO7RCh3rVtxwSXYVW6OxjwkkDbi/AdVSOWSzqYjNz NqzSkF7IOYvHf9I9vTb9l9qeZx4phegi5SUabxZVQRt98fwxveyYwfvViLNs408MfvXM 5G6A== MIME-Version: 1.0 Received: by 10.152.133.144 with SMTP id pc16mr8827982lab.0.1333358885504; Mon, 02 Apr 2012 02:28:05 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Mon, 2 Apr 2012 02:28:05 -0700 (PDT) X-Originating-IP: [85.110.29.196] Date: Mon, 2 Apr 2012 12:28:05 +0300 X-Google-Sender-Auth: z3WaBJ_ygojjH1EGlp1pMK96_8Y Message-ID: From: Beeblebrox To: freebsd-fs@freebsd.org X-Gm-Message-State: ALoCoQnrDf/AzX8I8aSqswS/IyXZFxVli4IRrSRTFtB7vtzeTGVHJbDNk/oGwagYjroPjB6oRSn6 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Diskless client mount NFS-root error 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: Mon, 02 Apr 2012 09:28:07 -0000 Client boots fine and gets to mounting root from NFS, but then stops with: "Mounting root filesystem rw failed, startup aborted" and drops to single-user mode. *loader.conf* for the client is below, Some optioons caused more trouble than solutions, so were commented out. 1. boot.nfsroot.server="192.168.2.1" 2. boot.nfsroot.path="/data/amd64" 3 .vfs.root.mountfrom="nfs:192.168.2.1:/data/amd64" 4. #vfs.root.mountfrom="nfs" 5. #boot.nfsroot.options="nolockd" 6 .#vfs.root.mountfrom.options="ro" Now the fun part is, with a dirty-little hack I was able to get diskless to work and NOT break boot: I commented out [stop_boot true] in diskless/etc/rc.d/root. Although at the time this was satisfactory, I would noow like to solve this the "propper way" if possible. */etc/exports*: /data/amd64 -ro -maproot=0 -network 192.168.2.0/24 Thanks for your input From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 11:00:31 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 886711065672 for ; Mon, 2 Apr 2012 11:00:31 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8945D8FC15 for ; Mon, 2 Apr 2012 11:00:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q32B0T7W037400 for ; Mon, 2 Apr 2012 11:00:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q32B0TXW037398; Mon, 2 Apr 2012 11:00:29 GMT (envelope-from gnats) Date: Mon, 2 Apr 2012 11:00:29 GMT Message-Id: <201204021100.q32B0TXW037398@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Steven Chamberlain Cc: Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steven Chamberlain List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:00:31 -0000 The following reply was made to PR kern/155411; it has been noted by GNATS. From: Steven Chamberlain To: bug-followup@FreeBSD.org, pgollucci@FreeBSD.org Cc: Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device Date: Mon, 02 Apr 2012 11:59:15 +0100 Hi, A Debian GNU/kFreeBSD (9.0-RELEASE) user also experienced this issue, has tried the patch from with r227802, and believes it fixed the problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666747#59 The original FreeBSD PR claims the issue was found in 8-STABLE, since 8.2. Will this fix be committed to 8-STABLE sometime? Thanks, Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 11:07:07 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18C2B10656D7 for ; Mon, 2 Apr 2012 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 021E48FC19 for ; Mon, 2 Apr 2012 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q32B76K9046770 for ; Mon, 2 Apr 2012 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q32B76Cn046768 for freebsd-fs@FreeBSD.org; Mon, 2 Apr 2012 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Apr 2012 11:07:06 GMT Message-Id: <201204021107.q32B76Cn046768@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org 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: Mon, 02 Apr 2012 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/166566 fs [zfs] zfs split renders 2 disk (MBR based) mirror unbo o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161511 fs [unionfs] Filesystem deadlocks when using multiple uni o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159663 fs [socket] [nullfs] sockets don't work though nullfs mou o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 264 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 11:37:53 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D3EB106566C for ; Mon, 2 Apr 2012 11:37:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C66AC8FC14 for ; Mon, 2 Apr 2012 11:37:51 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC43A0F.dip.t-dialin.net [79.196.58.15]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9F8978446D3; Mon, 2 Apr 2012 13:37:28 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id DBF0D2037; Mon, 2 Apr 2012 13:37:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1333366646; bh=7fVgs0A7jrnrReuenQjvICE3RJYGzLt8vGS1Qe4nUuc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=tzGrFqqcaN+wtUy+hqKv5k1jkdeEx703KGXBKVzYnuAGGw7P7UihUXBREUDuZi9jn nDN1baa4F80BbgIkUAx6rLYazasi76oV2ChxvX+a/+wJs0DEIPTTdK1i3DpkbrvPQU HqRMur6hLDSMkZdmBDheyfzTmzQKXQU6tWgcninDg0e2RI1exNkehqSowcEBIFYUZt khhji4xh+mfa9G40xON/j5mw69BTq6PvTdvNHHwXaWHFj5rnFOpyK5jdwc8lHmwfHD SjZusZAeJ5vwjpcIukKIaIr+1co2ayVFwLPz0CVo6hbgIcuJrM5Y7RlfMrt4F/BH5j vJTu4NekTR5Yw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q32BbN5H005065; Mon, 2 Apr 2012 13:37:23 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 195.46.238.197 ([195.46.238.197]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 02 Apr 2012 13:37:23 +0200 Date: Mon, 02 Apr 2012 13:37:21 +0200 Message-ID: <20120402133721.Horde.KOqoS5jmRSRPeY9xDWLhHWA@webmail.leidinger.net> From: Alexander Leidinger To: Taylor References: <45654FDD-A20A-47C8-B3B5-F9B0B71CC38B@enone.net> <20120324174218.00005f63@unknown> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9F8978446D3.A29CC X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.686, required 6, autolearn=disabled, AWL -0.65, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZF 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1333971451.06643@kjO8yMQ1Bd3xzrpTpqV1rQ X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: ZFS extra space overhead for ashift=12 vs ashift=9 raidz2 pool? 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: Mon, 02 Apr 2012 11:37:53 -0000 Quoting Taylor (from Sat, 24 Mar 2012 11:41:20 -0700): > Alex, > > Thank you for your response. I'm not particularly concerned about > the overhead of file fragmentation, > as most of the space will be take by fairly large files (10's of GiB). > > My original question concerned the amount of space reported > available by zfs for a > freshly-created *empty* raidz2 filesystem. > > To re-iterate, I find 2.79TiB more space available with ashift=9 > (49.62 TiB) vs ashift=12 (46.83TiB) > for a new 3.64TiB 16-disk raidz2 pool. I do not know for the actual amount, but at least some overhead is not surprising to me. You have some meta data in ZFS (file permissions, ACLs, checksums, ...). This meta data should be more often much less than 4k in size, but you need to allocate at least one block for this meta data. If we assume (worst case) that most of the time the meta data would fit into 512 byte but you always use a 4k sector, it should be clear that you use 8 times more space on the disk for each meta data unit, than necessary. Bye, Alexander. -- Let me put it this way: today is going to be a learning experience. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 14:31:47 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 E935B1065672; Mon, 2 Apr 2012 14:31:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 92F898FC14; Mon, 2 Apr 2012 14:31:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EE918B960; Mon, 2 Apr 2012 10:31:46 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 2 Apr 2012 08:27:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1184428460.2076443.1333328057090.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1184428460.2076443.1333328057090.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204020827.46722.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Apr 2012 10:31:47 -0400 (EDT) Cc: alc@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Mon, 02 Apr 2012 14:31:48 -0000 On Sunday, April 01, 2012 8:54:17 pm Rick Macklem wrote: > First, a little background w.r.t. an offlist discussion of > PR# 165923. A critical part of the problem reported is the > credentials used to to the Write RPCs in the NFS client's > VOP_PUTPAGES(). Currently the code simply uses the credentials > of the thread that called VOP_PUTPAGES(), which is often incorrect, > especially when the caller is "root" and the NFS server is doing > "root squashing" (ie mapping root->nobody or similar). Can this in theory affect READ RPCs sent by VOP_GETPAGES() as well in the case of root squashing? Or are VOP_GETPAGES() synchronous with respect to faults such that in practice you always have a valid credential in curthread->td_ucred? > Although there is no correct answer w.r.t. what credentials should > be used, there seemed to be rough consensus that the credentials of > the process that did the mmap() call would be best. (If there are > multiple writers, you could use either the 1st or most recent mmap(), > but since all writers had write permissions at open(), I don't think > it matters much which you use, but others can comment on this.) The one problem I see with this approach is suppose someone changes the permissions on the file. Now a user that previously had write access might not have it any longer, but we might be sending RPCs as a different user so they will still work. However, I don't think we can solve that, and presumbly we already have that issue now. Hmm, there might be a variant of this though that is new. Suppose user A and user B both mmap the file. At the time, both users have write access to the file. The file is then chown'd or chmod'd such that only user B has write access to the file, but we are using user A's credential as the cached 'write' credential. Then subsequent writes via mmap() by user B will be lost because they will be sent to the server as user A. Previously you couldn't really get into this case if root squashing was off and all writes were sent as root. Not sure if this is easily solvable either. You could perhaps maintain a list of known-valid write credentials and if a write fails with a permission check, toss it that credential and try the next one in the list. > However, there seems to be some disagreement as to how a patch to > use the mmap() credentials should be done. > > putpages-a.patch - This one captures the credentials during the mmap() > call by using the property that only mmap() calls vnode_pager_alloc() > with "prot != 0" and references them in a new field in vm_object_t. > > putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() call, which > is done by mmap(). For all file systems except NFS clients, it is a > null op. For the NFS clients, they reference the credentials in a > new field of the NFS specific part of the vnode. > > - I don't have a patch for the third one, but I believe Joel was proposing > something similar to putpages-a.patch, except that the credentials are > passed as an extra argument to VOP_PUTPAGES(), instead of the NFS client's > VOP_PUTPAGES() looking in the vnode's vm_object_t for the cred. I think what I would prefer for the longterm is option 3) (and possibly doing the same for VOP_GETPAGES(). Also, I would call the new field in vm_object something like 'writecred'. For MFC purposes you could use putpages-a.patch instead and only make the change to the VOPs in HEAD. However, I wonder if you can't manage this all at the vnode layer? If all you need is a credential that is allowed to write, can't you cache the credential used for a successful VOP_ACCESS() check with write support in the nfsnode and just use that for write RPCs? The same thing would work for reads, yes? I know for NFSv4 you already maintain a cache of credentials from open()'s that you use for other RPC's already, so this would seem to be similar to that case. This would also let you do the "list of credentials" idea if needed and even let you add new write-capable credentials to the list via VOP_ACCESS() calls after the file was mmap()'d or open()'d. > I've attached the first 2, in case anyone wants to look at them. > > Here's my take on the advantages/disadvantages of each patch: > Advantages Disadvantages > patch-a simple, doesn't require VOP > changes and, therefore, can > be MFC'd easily saves a largely NFS specific item > in vm_object_t > depends on the fact that only > mmap() calls vnode_pager_alloc() with > prot != 0 Only one more note here, this problem is not necessarily unique to NFS. It is probably just as relevant for any other networked file systems such as smbfs. Or just about any other filesystem with storage that requires authorization. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 15:45:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA52E106566C; Mon, 2 Apr 2012 15:45:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BEE768FC16; Mon, 2 Apr 2012 15:45:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAGXJeU+DaFvO/2dsb2JhbABFhUewRoQKggkBAQQBIwRSBRYOCgICDRkCWQaGJIFzBahckXCBL4llhHCBGASVYZAvgwOBOQc X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="166298203" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Apr 2012 11:45:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3C4AAB4010; Mon, 2 Apr 2012 11:45:10 -0400 (EDT) Date: Mon, 2 Apr 2012 11:45:10 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <1615948459.2113806.1333381510230.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201204020827.46722.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: alc@freebsd.org, freebsd-fs@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Mon, 02 Apr 2012 15:45:33 -0000 John Baldwin wrote: > On Sunday, April 01, 2012 8:54:17 pm Rick Macklem wrote: > > First, a little background w.r.t. an offlist discussion of > > PR# 165923. A critical part of the problem reported is the > > credentials used to to the Write RPCs in the NFS client's > > VOP_PUTPAGES(). Currently the code simply uses the credentials > > of the thread that called VOP_PUTPAGES(), which is often incorrect, > > especially when the caller is "root" and the NFS server is doing > > "root squashing" (ie mapping root->nobody or similar). > > Can this in theory affect READ RPCs sent by VOP_GETPAGES() as well in > the > case of root squashing? Or are VOP_GETPAGES() synchronous with respect > to > faults such that in practice you always have a valid credential in > curthread->td_ucred? > > > Although there is no correct answer w.r.t. what credentials should > > be used, there seemed to be rough consensus that the credentials of > > the process that did the mmap() call would be best. (If there are > > multiple writers, you could use either the 1st or most recent > > mmap(), > > but since all writers had write permissions at open(), I don't think > > it matters much which you use, but others can comment on this.) > > The one problem I see with this approach is suppose someone changes > the > permissions on the file. Now a user that previously had write access > might > not have it any longer, but we might be sending RPCs as a different > user so > they will still work. However, I don't think we can solve that, and > presumbly we already have that issue now. > Yes, the cases where chmod, chown or setuid on the process that mmap'd the file aren't handled and I don't think they can be. See below. > Hmm, there might be a variant of this though that is new. Suppose user > A > and user B both mmap the file. At the time, both users have write > access > to the file. The file is then chown'd or chmod'd such that only user B > has write access to the file, but we are using user A's credential as > the > cached 'write' credential. Then subsequent writes via mmap() by user B > will be lost because they will be sent to the server as user A. > Previously > you couldn't really get into this case if root squashing was off and > all > writes were sent as root. Not sure if this is easily solvable either. > You could perhaps maintain a list of known-valid write credentials and > if > a write fails with a permission check, toss it that credential and try > the > next one in the list. > There is a question w.r.t. how far you take this. You could have a list of all credentials that mmap'd the file and try them in turn. (Personally, I think that's ovekill for a rare case, but could be done. See below w.r.t. the more general case of write credentials.) > > However, there seems to be some disagreement as to how a patch to > > use the mmap() credentials should be done. > > > > putpages-a.patch - This one captures the credentials during the > > mmap() > > call by using the property that only mmap() calls > > vnode_pager_alloc() > > with "prot != 0" and references them in a new field in > > vm_object_t. > > > > putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() call, > > which > > is done by mmap(). For all file systems except NFS clients, it is > > a > > null op. For the NFS clients, they reference the credentials in a > > new field of the NFS specific part of the vnode. > > > > - I don't have a patch for the third one, but I believe Joel was > > proposing > > something similar to putpages-a.patch, except that the > > credentials are > > passed as an extra argument to VOP_PUTPAGES(), instead of the NFS > > client's > > VOP_PUTPAGES() looking in the vnode's vm_object_t for the cred. > > I think what I would prefer for the longterm is option 3) (and > possibly doing > the same for VOP_GETPAGES(). Also, I would call the new field in > vm_object > something like 'writecred'. For MFC purposes you could use > putpages-a.patch > instead and only make the change to the VOPs in HEAD. > > However, I wonder if you can't manage this all at the vnode layer? If > all > you need is a credential that is allowed to write, can't you cache the > credential used for a successful VOP_ACCESS() check with write support > in the > nfsnode and just use that for write RPCs? The same thing would work > for > reads, yes? I know for NFSv4 you already maintain a cache of > credentials > from open()'s that you use for other RPC's already, so this would seem > to be > similar to that case. This would also let you do the "list of > credentials" > idea if needed and even let you add new write-capable credentials to > the list > via VOP_ACCESS() calls after the file was mmap()'d or open()'d. > I think there is a question w.r.t. should you use credentials that weren't ones that mmap'd the file with PROT_WRITE. For example, the extreme case of this would be to just VOP_GETATTR() the file and use credentials with uid == va_uid to do the writes, if there are EACCES failures. This assumes that the client "should always be able to write the file, if it was mmap'd". This trick hasn't been used for non-mmap'd writes, presumably because it was felt that the per-wrire RPC access check was a good thing that the client shouldn't be circumventing. Btw, Joel had a rather long list of alternative fixes. Unfortunately this was done offlist (well actually mostly on re@). Maybe he could re-post those or give me permission to do so? > > I've attached the first 2, in case anyone wants to look at them. > > > > Here's my take on the advantages/disadvantages of each patch: > > Advantages Disadvantages > > patch-a simple, doesn't require VOP > > changes and, therefore, can > > be MFC'd easily saves a largely NFS specific item > > in vm_object_t > > depends on the fact that > > only > > mmap() calls > > vnode_pager_alloc() with > > prot != 0 > > Only one more note here, this problem is not necessarily unique to > NFS. It > is probably just as relevant for any other networked file systems such > as > smbfs. Or just about any other filesystem with storage that requires > authorization. > Joel argued that the credential reference in vm_object_t wasn't NFS specific for the same reason. (ie. He felt it might be useful for other filesystems, such as smbfs. He had at least one other one, but I can't remember which one;-) Thanks for the comments, rick > -- > John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 16:00:14 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F9EA106566C for ; Mon, 2 Apr 2012 16:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 610CB8FC15 for ; Mon, 2 Apr 2012 16:00:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q32G0EhU019683 for ; Mon, 2 Apr 2012 16:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q32G0Eb1019682; Mon, 2 Apr 2012 16:00:14 GMT (envelope-from gnats) Date: Mon, 2 Apr 2012 16:00:14 GMT Message-Id: <201204021600.q32G0Eb1019682@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: George Hartzell Cc: Subject: Re: kern/166566: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: George Hartzell List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:00:14 -0000 The following reply was made to PR kern/166566; it has been noted by GNATS. From: George Hartzell To: Andriy Gapon Cc: bug-followup@FreeBSD.org, hartzell@alerce.com Subject: Re: kern/166566: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable Date: Mon, 2 Apr 2012 08:47:53 -0700 Thanks for following up on this. Andriy Gapon writes: > > A few things missing from your port: > > 1. "Doesn't boot" is quite a poor description in comparison with > other details that you provided. You should give more detailed > information of the boot failure. As the kernel is loading it fails to mount the root partition and presents one with the minimal mountroot dialog. Attempting to boot from zfs:zroot or zfs:zsplitroot fails. I remember that a question mark lists various other devices but don't remember the particulars. > 2. gpart information for ada3 Identical to ada1. Both disks have an MBR with one slice, which has a BSD label with two partitions, a (926GB, type freebsd-zfs) and b (5.5GB, type freebsd-swap). (delicious)[8:45am]~>>gpart show ada1 => 63 1953525105 ada1 MBR (931G) 63 1953525105 1 freebsd [active] (931G) (delicious)[8:45am]~>>gpart show ada1s1 => 0 1953525105 ada1s1 BSD (931G) 0 1941962752 1 freebsd-zfs (926G) 1941962752 11562353 2 freebsd-swap (5.5G) (delicious)[8:46am]~>>gpart show ada3 => 63 1953525105 ada3 MBR (931G) 63 1953525105 1 freebsd [active] (931G) (delicious)[8:46am]~>>gpart show ada3s1 => 0 1953525105 ada3s1 BSD (931G) 0 1941962752 1 freebsd-zfs (926G) 1941962752 11562353 2 freebsd-swap (5.5G) Both have boot bits set up like this: gpart bootcode -b /boot/boot0 adaX dd if=/boot/zfsboot of=/dev/adaXs1 count=1 dd if=/boot/zfsboot of=/dev/adaXs1a skip=1 seek=1024 > 3. You don't say which disk ended up as zroot and as zsplitroot > after the split. zpool status showed only zroot ada3s1a and zpool import showed zsplitroot ada1s1a > 4. You don't say which disk is configured as a boot disk in BIOS. This is a mac pro (tower), so BIOS is kind of a slippery concept. I leave the 'startup disk' set to the (other) OS X disks. On power up I hold down the option key and am presented with a dialog from which I can select any of the bootable devices in the box. When things are working correctly I can boot from either of the disks in the ZFS mirror and things go well. Now that I've upgraded I can even pull one of the disks before powering up and boot from the other (older zfs bootstrapping stuff used to have a problem with broken mirrors). After the zfs split I am unable to boot from either disk. g. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 17:13:11 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E83F10657AE; Mon, 2 Apr 2012 17:13:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 621CD8FC1A; Mon, 2 Apr 2012 17:13:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BABEEB95A; Mon, 2 Apr 2012 13:13:10 -0400 (EDT) From: John Baldwin To: Rick Macklem Date: Mon, 2 Apr 2012 13:10:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1615948459.2113806.1333381510230.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1615948459.2113806.1333381510230.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201204021310.24420.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Apr 2012 13:13:10 -0400 (EDT) Cc: alc@freebsd.org, freebsd-fs@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Mon, 02 Apr 2012 17:13:11 -0000 On Monday, April 02, 2012 11:45:10 am Rick Macklem wrote: > > > However, there seems to be some disagreement as to how a patch to > > > use the mmap() credentials should be done. > > > > > > putpages-a.patch - This one captures the credentials during the > > > mmap() > > > call by using the property that only mmap() calls > > > vnode_pager_alloc() > > > with "prot != 0" and references them in a new field in > > > vm_object_t. > > > > > > putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() call, > > > which > > > is done by mmap(). For all file systems except NFS clients, it is > > > a > > > null op. For the NFS clients, they reference the credentials in a > > > new field of the NFS specific part of the vnode. > > > > > > - I don't have a patch for the third one, but I believe Joel was > > > proposing > > > something similar to putpages-a.patch, except that the > > > credentials are > > > passed as an extra argument to VOP_PUTPAGES(), instead of the NFS > > > client's > > > VOP_PUTPAGES() looking in the vnode's vm_object_t for the cred. > > > > I think what I would prefer for the longterm is option 3) (and > > possibly doing > > the same for VOP_GETPAGES(). Also, I would call the new field in > > vm_object > > something like 'writecred'. For MFC purposes you could use > > putpages-a.patch > > instead and only make the change to the VOPs in HEAD. > > > > However, I wonder if you can't manage this all at the vnode layer? If > > all > > you need is a credential that is allowed to write, can't you cache the > > credential used for a successful VOP_ACCESS() check with write support > > in the > > nfsnode and just use that for write RPCs? The same thing would work > > for > > reads, yes? I know for NFSv4 you already maintain a cache of > > credentials > > from open()'s that you use for other RPC's already, so this would seem > > to be > > similar to that case. This would also let you do the "list of > > credentials" > > idea if needed and even let you add new write-capable credentials to > > the list > > via VOP_ACCESS() calls after the file was mmap()'d or open()'d. > > > I think there is a question w.r.t. should you use credentials that weren't > ones that mmap'd the file with PROT_WRITE. But you already are potentially (in that you might mismatch permissions for a given WRITE since the page might have been dirtied by a different user than the credential we use). You have to open() the file with write permissions before you mmap() it, so all mmap()'s are going to do a VOP_ACCESS() prior, so if you just cache whatever credential last worked for write access to VOP_ACCESS() that would more or less work, and be about as reliable while not requiring any changes outside of the NFS client itself. > For example, the extreme case of this would be to just VOP_GETATTR() the > file and use credentials with uid == va_uid to do the writes, if there are > EACCES failures. This assumes that the client "should always be able to > write the file, if it was mmap'd". This trick hasn't been used for non-mmap'd > writes, presumably because it was felt that the per-wrire RPC access check > was a good thing that the client shouldn't be circumventing. Well, we always have a credential for normal writes, with mmap() we don't. Presumably the open() will have to check for write permissions, so even what you suggest of just using the uid of the file might be fine. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 18:13:53 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78EDB10656F3 for ; Mon, 2 Apr 2012 18:13:53 +0000 (UTC) (envelope-from bsalinux@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3782C8FC16 for ; Mon, 2 Apr 2012 18:13:53 +0000 (UTC) Received: by qao25 with SMTP id 25so2071788qao.13 for ; Mon, 02 Apr 2012 11:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Do2Fz0CMNx+fHPKhruSu6V+o7LSsjvhVKYifM0l1ZRo=; b=q8hZ1G5XpdXXEa3ryVHgS0JDyF4pezkB1uo+r7i6EZgL69Z3U3ujR8GYcjIXYj/cZ9 fEVnZkp5s5oqGDEpZ4ZMh1wFKShh59PiP1pzmelBny2iyKwKPdtwprzbQNET1XusGpud KF2RCyM5AAFcQHMRKqaar1aQN02KYQaVEdDXuhwhAimabRS3jEjXH9Y/ENmoH7fl8/aE Lc4Ek6uGXc4fJrESXEoprIZLc3ZZVaCUyfy6jyc8dQBt52e2CkBiriWkgUCnRdN6sGbG pSMIwR5Vqmmh+VRQN5/RK0zrcwuHP/6Zbzc5pMckxFtjf7QuBOmDX8XbTKUNRmiEUi4Y iORg== MIME-Version: 1.0 Received: by 10.229.135.3 with SMTP id l3mr3744170qct.45.1333390432480; Mon, 02 Apr 2012 11:13:52 -0700 (PDT) Received: by 10.229.71.15 with HTTP; Mon, 2 Apr 2012 11:13:52 -0700 (PDT) Date: Mon, 2 Apr 2012 11:13:52 -0700 Message-ID: From: "bsalinux@gmail.com" To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Swap on ZFS / swap_pager: indefinite wait buffer 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: Mon, 02 Apr 2012 18:13:53 -0000 Hi, I have been running FreeBSD 9.0-RELEASE from a USB stick running ZFS. I have created swap file on zfs volume using the md driver. Swapinfo shows Device 1K-blocks Used Avail Capacity /dev/md0 4194304 0 4194304 0% The system has hung twice and all I can find in the log is Mar 22 03:17:30 server kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 927, size: 4096 Mar 23 09:00:26 server kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 55, size: 4096 Mar 23 22:01:26 server kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 49, size: 4096 Mar 24 04:00:38 server kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 60, size: 4096 As the swap is on zfs, I assume it is not failing. Do I need to move swap off of ZFS? Thanks From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 18:39: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 D17D3106564A for ; Mon, 2 Apr 2012 18:39:17 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1FC8FC15 for ; Mon, 2 Apr 2012 18:39:16 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3288082bkc.13 for ; Mon, 02 Apr 2012 11:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=512xPBAzFpdYM68HMk0/ZeVvPXRhClN7/bnXu+zTh5M=; b=GkX4TjqwtHVfHibYJYendsbOCJW8LfQUpZpblSMARKHJvZuHqOH/KzihJev+VS5sTS V65edd8Z/rirc2s7oPAM6XQ5wgyPIcuJ5nsJgZnDyzKCVUbESlIke3SrNtUXgadKA3E9 MWPgM9wIYuv4BT2Cn3YdAnIv527Of8/fsbtHzqWaRtYTLB5iQG/QnleLLw+RcWzzxyis qMP7RVSp2jgAo9s1BpD8wRWooLRRYFj7fyJPkQUFmxBzGEh1zIEmbAmj1V3NI6SspBr0 JKDajlwpUh2NanQQwrC28E7EMOShuGlg59Wk8XHrG2C3kjaHtqTmPMopWSopqDXgf7BK lbZw== MIME-Version: 1.0 Received: by 10.152.129.69 with SMTP id nu5mr10877751lab.9.1333391955779; Mon, 02 Apr 2012 11:39:15 -0700 (PDT) Received: by 10.152.25.69 with HTTP; Mon, 2 Apr 2012 11:39:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Apr 2012 22:39:15 +0400 Message-ID: From: Sergey Kandaurov To: "bsalinux@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Swap on ZFS / swap_pager: indefinite wait buffer 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: Mon, 02 Apr 2012 18:39:17 -0000 On 2 April 2012 22:13, bsalinux@gmail.com wrote: > Hi, > > I have been running FreeBSD 9.0-RELEASE from a USB stick running ZFS. > I have created swap file on zfs volume using the md driver. > > Swapinfo shows > > Device =A0 =A0 =A0 =A0 =A01K-blocks =A0 =A0 Used =A0 =A0Avail Capacity > /dev/md0 =A0 =A0 =A0 =A0 =A04194304 =A0 =A0 =A0 =A00 =A04194304 =A0 =A0 0= % > > > The system has hung twice and all I can find in the log is > > Mar 22 03:17:30 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 927, size: 4096 > Mar 23 09:00:26 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 55, size: 4096 > Mar 23 22:01:26 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 49, size: 4096 > Mar 24 04:00:38 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 60, size: 4096 > That generally means that your storage is too slow (to handle swap). See also FAQ: http://www.freebsd.org/doc/en/books/faq/troubleshoot.html#INDEFINITE-WAIT-B= UFFER > As the swap is on zfs, I assume it is not failing. > > Do I need to move swap off of ZFS? > IIRC swap on ZFS is generally a bad idea. Search web for bad stories. --=20 wbr, pluknet From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 19:13:28 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 0B2F110656D1; Mon, 2 Apr 2012 19:13:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1C28FC0A; Mon, 2 Apr 2012 19:13:27 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q32JDBAm086044; Mon, 2 Apr 2012 22:13:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q32JDB9o067559; Mon, 2 Apr 2012 22:13:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q32JDBCP067558; Mon, 2 Apr 2012 22:13:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Apr 2012 22:13:10 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120402191310.GX2358@deviant.kiev.zoral.com.ua> References: <1615948459.2113806.1333381510230.JavaMail.root@erie.cs.uoguelph.ca> <201204021310.24420.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wHFODgxldyMzlX03" Content-Disposition: inline In-Reply-To: <201204021310.24420.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: alc@freebsd.org, freebsd-fs@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Mon, 02 Apr 2012 19:13:28 -0000 --wHFODgxldyMzlX03 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 02, 2012 at 01:10:24PM -0400, John Baldwin wrote: > On Monday, April 02, 2012 11:45:10 am Rick Macklem wrote: > > > > However, there seems to be some disagreement as to how a patch to > > > > use the mmap() credentials should be done. > > > > > > > > putpages-a.patch - This one captures the credentials during the > > > > mmap() > > > > call by using the property that only mmap() calls > > > > vnode_pager_alloc() > > > > with "prot !=3D 0" and references them in a new field in > > > > vm_object_t. > > > > > > > > putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() call, > > > > which > > > > is done by mmap(). For all file systems except NFS clients, it is > > > > a > > > > null op. For the NFS clients, they reference the credentials in a > > > > new field of the NFS specific part of the vnode. > > > > > > > > - I don't have a patch for the third one, but I believe Joel was > > > > proposing > > > > something similar to putpages-a.patch, except that the > > > > credentials are > > > > passed as an extra argument to VOP_PUTPAGES(), instead of the NFS > > > > client's > > > > VOP_PUTPAGES() looking in the vnode's vm_object_t for the cred. > > >=20 > > > I think what I would prefer for the longterm is option 3) (and > > > possibly doing > > > the same for VOP_GETPAGES(). Also, I would call the new field in > > > vm_object > > > something like 'writecred'. For MFC purposes you could use > > > putpages-a.patch > > > instead and only make the change to the VOPs in HEAD. > > >=20 > > > However, I wonder if you can't manage this all at the vnode layer? If > > > all > > > you need is a credential that is allowed to write, can't you cache the > > > credential used for a successful VOP_ACCESS() check with write support > > > in the > > > nfsnode and just use that for write RPCs? The same thing would work > > > for > > > reads, yes? I know for NFSv4 you already maintain a cache of > > > credentials > > > from open()'s that you use for other RPC's already, so this would seem > > > to be > > > similar to that case. This would also let you do the "list of > > > credentials" > > > idea if needed and even let you add new write-capable credentials to > > > the list > > > via VOP_ACCESS() calls after the file was mmap()'d or open()'d. > > >=20 > > I think there is a question w.r.t. should you use credentials that were= n't > > ones that mmap'd the file with PROT_WRITE. >=20 > But you already are potentially (in that you might mismatch permissions > for a given WRITE since the page might have been dirtied by a different > user than the credential we use). You have to open() the file with write > permissions before you mmap() it, so all mmap()'s are going to do a > VOP_ACCESS() prior, so if you just cache whatever credential last worked > for write access to VOP_ACCESS() that would more or less work, and be > about as reliable while not requiring any changes outside of the NFS > client itself. >=20 > > For example, the extreme case of this would be to just VOP_GETATTR() the > > file and use credentials with uid =3D=3D va_uid to do the writes, if th= ere are > > EACCES failures. This assumes that the client "should always be able to > > write the file, if it was mmap'd". This trick hasn't been used for non-= mmap'd > > writes, presumably because it was felt that the per-wrire RPC access ch= eck > > was a good thing that the client shouldn't be circumventing. >=20 > Well, we always have a credential for normal writes, with mmap() we don't. > Presumably the open() will have to check for write permissions, so even > what you suggest of just using the uid of the file might be fine. I am highly biased toward fs-specific solution. I do not like an idea to add a credentials reference to the vm_object for the sake of some filesystems. Esp. because the policy of which credential is right might be very much depend on the filesystem. Adding notification VOP at the time of mmap() is fine for me, but it probab= ly indeed use the credentials of the file descriptor and not the current proce= ss. E.g., if file descriptor was passed using unix domain socket, then curthread->td_cred is wrong thing to use. So cached credentials used for open() is probably indeed closest approximation. Fours option is to not change anything at all, e.g. my opinion is that having root uid mapped to non-root is mostly configuration error. --wHFODgxldyMzlX03 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk95+kYACgkQC3+MBN1Mb4jsRQCg9Ub8igJPG0d1AFjcbxLLPWt+ khsAoKBVdaAwhkGIjhIfMUHbhqgpn2DW =zH4q -----END PGP SIGNATURE----- --wHFODgxldyMzlX03-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 20:53:44 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 D48AA106564A; Mon, 2 Apr 2012 20:53:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 96C6C8FC14; Mon, 2 Apr 2012 20:53:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F3BD1B945; Mon, 2 Apr 2012 16:53:43 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Mon, 2 Apr 2012 16:38:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1615948459.2113806.1333381510230.JavaMail.root@erie.cs.uoguelph.ca> <201204021310.24420.jhb@freebsd.org> <20120402191310.GX2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120402191310.GX2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204021638.11817.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Apr 2012 16:53:44 -0400 (EDT) Cc: alc@freebsd.org, freebsd-fs@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Mon, 02 Apr 2012 20:53:44 -0000 On Monday, April 02, 2012 3:13:10 pm Konstantin Belousov wrote: > On Mon, Apr 02, 2012 at 01:10:24PM -0400, John Baldwin wrote: > > On Monday, April 02, 2012 11:45:10 am Rick Macklem wrote: > > > > > However, there seems to be some disagreement as to how a patch to > > > > > use the mmap() credentials should be done. > > > > > > > > > > putpages-a.patch - This one captures the credentials during the > > > > > mmap() > > > > > call by using the property that only mmap() calls > > > > > vnode_pager_alloc() > > > > > with "prot != 0" and references them in a new field in > > > > > vm_object_t. > > > > > > > > > > putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() call, > > > > > which > > > > > is done by mmap(). For all file systems except NFS clients, it is > > > > > a > > > > > null op. For the NFS clients, they reference the credentials in a > > > > > new field of the NFS specific part of the vnode. > > > > > > > > > > - I don't have a patch for the third one, but I believe Joel was > > > > > proposing > > > > > something similar to putpages-a.patch, except that the > > > > > credentials are > > > > > passed as an extra argument to VOP_PUTPAGES(), instead of the NFS > > > > > client's > > > > > VOP_PUTPAGES() looking in the vnode's vm_object_t for the cred. > > > > > > > > I think what I would prefer for the longterm is option 3) (and > > > > possibly doing > > > > the same for VOP_GETPAGES(). Also, I would call the new field in > > > > vm_object > > > > something like 'writecred'. For MFC purposes you could use > > > > putpages-a.patch > > > > instead and only make the change to the VOPs in HEAD. > > > > > > > > However, I wonder if you can't manage this all at the vnode layer? If > > > > all > > > > you need is a credential that is allowed to write, can't you cache the > > > > credential used for a successful VOP_ACCESS() check with write support > > > > in the > > > > nfsnode and just use that for write RPCs? The same thing would work > > > > for > > > > reads, yes? I know for NFSv4 you already maintain a cache of > > > > credentials > > > > from open()'s that you use for other RPC's already, so this would seem > > > > to be > > > > similar to that case. This would also let you do the "list of > > > > credentials" > > > > idea if needed and even let you add new write-capable credentials to > > > > the list > > > > via VOP_ACCESS() calls after the file was mmap()'d or open()'d. > > > > > > > I think there is a question w.r.t. should you use credentials that weren't > > > ones that mmap'd the file with PROT_WRITE. > > > > But you already are potentially (in that you might mismatch permissions > > for a given WRITE since the page might have been dirtied by a different > > user than the credential we use). You have to open() the file with write > > permissions before you mmap() it, so all mmap()'s are going to do a > > VOP_ACCESS() prior, so if you just cache whatever credential last worked > > for write access to VOP_ACCESS() that would more or less work, and be > > about as reliable while not requiring any changes outside of the NFS > > client itself. > > > > > For example, the extreme case of this would be to just VOP_GETATTR() the > > > file and use credentials with uid == va_uid to do the writes, if there are > > > EACCES failures. This assumes that the client "should always be able to > > > write the file, if it was mmap'd". This trick hasn't been used for non-mmap'd > > > writes, presumably because it was felt that the per-wrire RPC access check > > > was a good thing that the client shouldn't be circumventing. > > > > Well, we always have a credential for normal writes, with mmap() we don't. > > Presumably the open() will have to check for write permissions, so even > > what you suggest of just using the uid of the file might be fine. > > I am highly biased toward fs-specific solution. I do not like an idea > to add a credentials reference to the vm_object for the sake of some > filesystems. Esp. because the policy of which credential is right might > be very much depend on the filesystem. > > Adding notification VOP at the time of mmap() is fine for me, but it probably > indeed use the credentials of the file descriptor and not the current process. > E.g., if file descriptor was passed using unix domain socket, then > curthread->td_cred is wrong thing to use. So cached credentials used for > open() is probably indeed closest approximation. Yes, a new VOP would want to use the file's credential, not the current thread. > Fours option is to not change anything at all, e.g. my opinion is that > having root uid mapped to non-root is mostly configuration error. Actually, mapping root to nobody is a very common practice, common enough that we can't ignore it. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 21:29:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 612381065674 for ; Mon, 2 Apr 2012 21:29:44 +0000 (UTC) (envelope-from bsalinux@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC718FC15 for ; Mon, 2 Apr 2012 21:29:43 +0000 (UTC) Received: by qcsg15 with SMTP id g15so2268641qcs.13 for ; Mon, 02 Apr 2012 14:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GhwhmE76Sca3VM8/8zSqTMgOu6TB32WvrGQSlcDJTZM=; b=H6wPfMZAAJN0aEz5/4SREFg//6Slf2UrrUzJUan9qiMa3FgiB2FbYiLRgRneGzCWHK GiMlEWp6kNx/p1Zs/TnvNoExzDcYvRhvWs702q4yAgMJ6l/dmQXMxvwNqbPINLRm4YMD xLeCCMQmSgr2kcGq/l/oRDDFxbCgsWU2H6WrrQzoK+SDj2aKsaVZNuBXwqvJHEhTgTvf 7mTXIJyG/lVyvi5yVaCdwGeXSODAjtjP8w9jHalxKdOT4+ycNUR2Nb4GEgzAmfulaa2n QIRsTzkAyMwmsPxWdBAOUcUJPcCOuTJtgsbyWqj/G7DNXIme3EG5OqiIg+PTPW5oXWZd FPCw== MIME-Version: 1.0 Received: by 10.224.180.206 with SMTP id bv14mr13480708qab.56.1333402183228; Mon, 02 Apr 2012 14:29:43 -0700 (PDT) Received: by 10.229.71.15 with HTTP; Mon, 2 Apr 2012 14:29:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Apr 2012 14:29:43 -0700 Message-ID: From: "bsalinux@gmail.com" To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Swap on ZFS / swap_pager: indefinite wait buffer 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: Mon, 02 Apr 2012 21:29:44 -0000 This is what I found. I should be using zvol as swap not swap files on zfs. https://blogs.oracle.com/jimlaurent/entry/faq_using_zfs_for_swap Thanks for your pointer. > IIRC swap on ZFS is generally a bad idea. > Search web for bad stories. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 21:37:38 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 914F4106566C; Mon, 2 Apr 2012 21:37:38 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8F38FC15; Mon, 2 Apr 2012 21:37:31 +0000 (UTC) Received: from sa-nc-ipg-172-23-0-161.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q32LbO76067348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 14:37:30 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Marcel Moolenaar Date: Mon, 2 Apr 2012 14:37:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: To: Grzegorz Bernacki X-Mailer: Apple Mail (2.1257) Cc: geom@FreeBSD.org, fs@FreeBSD.org Subject: Review of projects/nand branch 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: Mon, 02 Apr 2012 21:37:38 -0000 Grzegorz, I reviewed the changes on the projects/nand branch and in general it's of high quality and any problems, improvements and/or cleanups can be addressed after it gets merged into -current, with the following caveat: 1. Changes to sys/kern, sys/geom and sys/sys should be reviewed and approved by people on fs@freebsd.org and/or geom@freebsd.org. I saw comments from pjd already for example. 2. Please address the following points before merging onto head: o In include/Makefile: fs/fifofs is removed. Deliberate? o In sbin/Makefile: we should have a distinct MK_NANDFS option for use by the file system code. o In sbin/nandfs/nandfs.8: could elaborate for what one could use the snapshots. o In sbin/nandfs/nandfs.h: define NANDFS_H. o In sbin/nandfs/nandfs.c: usage() is wrong. o In sbin/nandfs/Makefile: $FreeBSD$ is missing. o In sbin/mount_nandfs/mount_nandfs.8: copyright notice seems bogusly copied. Also, cleanerd is gone so it needs updating. o In sbin/mount_nandfs/mount_nandfs.c: cleanerd is gone, so this file could do with a some cleanups. o In sbin/mount_nandfs/Makefile: $FreeBSD$ is missing. o In sbin/mount/mntopts.h: cleanerd is gone, so should not be needed anymore. o In sbin/newfs_nandfs/newfs_nandfs.c: we have CRC32 code for re-use. No need to implement again. o In sbin/newfs_nandfs/Makefile: missing DPADD. o In share/mk/bsd.own.mk: Add NANDFS as well. May also want to add NANDSIM separately. o In share/man/man5/Makefile: should be NANDFS. o In usr.sbin/nandtool/Makefile: missing $FreeBSD$ o In usr.sbin/nandsim/Makefile: missing $FreeBSD$ o usr.sbin/Makefile should have nandtool and nandsim when MK_NAND is defined. o In lib/Makefile: should be MK_NANDFS; not MK_NAND. o In lib/libstand/nandfs.c: should use common CRC32 impl. o In lib/libstand/Makefile: should be MK_NANDFS; not MK_NAND. o Please get buy-in for changes to sys/kern/vfs_vnops.c, sys/kern/vfs_bio.c and sys/kern/vfs_subr.c from people on fs@freebsd.org. o In sys/modules/Makefile: always build nandfs module. Make nandsim module dependent on MK_NAND or MK_NANDSIM if added. o Please get buy-in for changes to sys/geom/geom_dev.c, sys/geom/geom_disk.c, sys/geom/geom_disk.h, sys/geom/geom.h and sys/geom/geom_slice.c from people on geom@freebsd.org. o Please get buy-in for changes to sys/sys/disk.h and sys/sys/bio.h from people on either fs@freebsd.org or geom@freebsd.org. I also have a general usability question relating snapshots. Currently snapshots are read-only. A useful feature in the embedded space is to make a snapshot, attempt a software update and revert to the snapshot if and when the update fails or gets aborted. Is it possible to extend the snapshot feature in the future to allow for this use case (i.e. ignore any and all modifications that happened after a snapshot was made and mount the snapshot R/W as representing the current/latest state of the file system)? I'd like to thank Semihalf and the Foundation for bringing this code into FreeBSD. Well done! Thanks, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 22:33:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BB09106564A for ; Mon, 2 Apr 2012 22:33:31 +0000 (UTC) (envelope-from bsalinux@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 312F28FC14 for ; Mon, 2 Apr 2012 22:33:30 +0000 (UTC) Received: by qcsg15 with SMTP id g15so2304250qcs.13 for ; Mon, 02 Apr 2012 15:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=KbeuN04f4tYlDOREr5mBwp7cn7hQ5oEZmFkiSdkSvcc=; b=auGtr5V9Z8rxKxt9DOlwayX3aafBkC7NWyv7oio8ODI2EP4Hm6knnU5Stcd31NcnUr IG9fQpGgAZSf58ejXP01slHzt1Qz5wgn/UMLnCk9SdKG7BwA3aOOY9G0+xYBfSNKA6HR xYoN28z3sgvT/44s/qQXkJiOLM54RUXes4LOt6jKxw63uaxPlEPFTuE7HiMz45gcy8hz k8/0Qmvjo7nFolUGig4tNGmIUhoUj5Rcsj3wqlqwEb1+naaqf5KsHQySBN3qQ6ZF9Vtx +t/h8qmLbwAT348OclvLRKgV2W4wT9lTbqPeGpHctzU56m6avuLuAmgBC7gAjdGNOr42 sn+g== MIME-Version: 1.0 Received: by 10.224.180.201 with SMTP id bv9mr13638270qab.69.1333406009674; Mon, 02 Apr 2012 15:33:29 -0700 (PDT) Received: by 10.229.71.15 with HTTP; Mon, 2 Apr 2012 15:33:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Apr 2012 15:33:29 -0700 Message-ID: From: "bsalinux@gmail.com" To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Swap on ZFS / swap_pager: indefinite wait buffer 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: Mon, 02 Apr 2012 22:33:31 -0000 Thanks for the recommendation Adam. On Mon, Apr 2, 2012 at 2:37 PM, Adam Vande More wro= te: > > No, swap on ZFS on FreeBSD is a bad idea, file-backed or ZVOL backed.=A0 = At > least this has been a problem up until very recently. > > -- > Adam Vande More From owner-freebsd-fs@FreeBSD.ORG Mon Apr 2 23:03:30 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E82C1065674 for ; Mon, 2 Apr 2012 23:03:30 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 062D68FC0C for ; Mon, 2 Apr 2012 23:03:29 +0000 (UTC) Received: (qmail 15823 invoked by uid 99); 2 Apr 2012 23:03:29 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2012 23:03:29 +0000 Received: from localhost (HELO daniel3.local) (127.0.0.1) (smtp-auth username danielsh, mechanism login) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2012 23:03:29 +0000 Date: Tue, 3 Apr 2012 02:03:03 +0300 From: Daniel Shahaf To: Jaakko Heinonen Message-ID: <20120402230303.GJ4711@daniel3.local> References: <201204010740.q317eHiP076471@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204010740.q317eHiP076471@freefall.freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@FreeBSD.org, infrastructure-private@apache.org Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device 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: Mon, 02 Apr 2012 23:03:30 -0000 Jaakko Heinonen wrote on Sun, Apr 01, 2012 at 07:40:17 +0000: > The following reply was made to PR kern/155411; it has been noted by GNATS. > > From: Jaakko Heinonen > To: pgollucci@FreeBSD.org > Cc: bug-followup@FreeBSD.org, delphij@FreeBSD.org > Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : > No space left on device > Date: Sun, 1 Apr 2012 10:37:28 +0300 > > It seems that r227802 hasn't been MFCd to stable/9. Can you test with > the head version or apply r227802 to stable/9? > I've just applied r227802 to one of our 9.0-RELEASE boxes which ran into the issue. If there is any problem I'll report back. FreeBSD aurora.apache.org 9.0-RELEASE+r227802 FreeBSD 9.0-RELEASE+r227802 #1: Mon Apr 2 21:52:02 UTC 2012 root@aurora.apache.org:/usr/obj/usr/src/sys/ASF amd64 > -- > Jaakko > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 02:03:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FBE4106564A; Tue, 3 Apr 2012 02:03:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id BF2D98FC14; Tue, 3 Apr 2012 02:03:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACNaek+DaFvO/2dsb2JhbABDhVivNYQMggkBAQQBI1YFFg4KAgINGQJZBoYkgXMFrTSKLoEvjieBGASVYZAvgwOBQA X-IronPort-AV: E=Sophos;i="4.75,361,1330923600"; d="scan'208";a="163409477" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 02 Apr 2012 22:02:55 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 08DF2B401A; Mon, 2 Apr 2012 22:02:55 -0400 (EDT) Date: Mon, 2 Apr 2012 22:02:55 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <394500062.2166073.1333418575016.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201204021310.24420.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: alc@freebsd.org, freebsd-fs@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Tue, 03 Apr 2012 02:03:07 -0000 John Baldwin wrote: > On Monday, April 02, 2012 11:45:10 am Rick Macklem wrote: > > > > However, there seems to be some disagreement as to how a patch > > > > to > > > > use the mmap() credentials should be done. > > > > > > > > putpages-a.patch - This one captures the credentials during the > > > > mmap() > > > > call by using the property that only mmap() calls > > > > vnode_pager_alloc() > > > > with "prot != 0" and references them in a new field in > > > > vm_object_t. > > > > > > > > putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() > > > > call, > > > > which > > > > is done by mmap(). For all file systems except NFS clients, > > > > it is > > > > a > > > > null op. For the NFS clients, they reference the credentials > > > > in a > > > > new field of the NFS specific part of the vnode. > > > > > > > > - I don't have a patch for the third one, but I believe Joel was > > > > proposing > > > > something similar to putpages-a.patch, except that the > > > > credentials are > > > > passed as an extra argument to VOP_PUTPAGES(), instead of the > > > > NFS > > > > client's > > > > VOP_PUTPAGES() looking in the vnode's vm_object_t for the > > > > cred. > > > > > > I think what I would prefer for the longterm is option 3) (and > > > possibly doing > > > the same for VOP_GETPAGES(). Also, I would call the new field in > > > vm_object > > > something like 'writecred'. For MFC purposes you could use > > > putpages-a.patch > > > instead and only make the change to the VOPs in HEAD. > > > > > > However, I wonder if you can't manage this all at the vnode layer? > > > If > > > all > > > you need is a credential that is allowed to write, can't you cache > > > the > > > credential used for a successful VOP_ACCESS() check with write > > > support > > > in the > > > nfsnode and just use that for write RPCs? The same thing would > > > work > > > for > > > reads, yes? I know for NFSv4 you already maintain a cache of > > > credentials > > > from open()'s that you use for other RPC's already, so this would > > > seem > > > to be > > > similar to that case. This would also let you do the "list of > > > credentials" > > > idea if needed and even let you add new write-capable credentials > > > to > > > the list > > > via VOP_ACCESS() calls after the file was mmap()'d or open()'d. > > > > > I think there is a question w.r.t. should you use credentials that > > weren't > > ones that mmap'd the file with PROT_WRITE. > > But you already are potentially (in that you might mismatch > permissions > for a given WRITE since the page might have been dirtied by a > different > user than the credential we use). You have to open() the file with > write > permissions before you mmap() it, so all mmap()'s are going to do a > VOP_ACCESS() prior, so if you just cache whatever credential last > worked > for write access to VOP_ACCESS() that would more or less work, and be > about as reliable while not requiring any changes outside of the NFS > client itself. > Taking a reference to the cred passed to the most recent VOP_OPEN() with FWRITE for the vnode and keeping that in the nfs specific vnode sounds ok to me. The only issue is that the NFS client will do this for many vnodes that never get mmap'd, but that just means more credentials may be allocated for longer. (As I understand it, the crfree() can't be done until the NFS VOP_INACTIVE()/VOP_RECLAIM(), since writing to mmap'd files can happen after the file descriptor is closed.) This would avoid any new/modified VOPs and any changes to vm_object_t. Thanks for the comments. Please keep them coming, rick > > For example, the extreme case of this would be to just VOP_GETATTR() > > the > > file and use credentials with uid == va_uid to do the writes, if > > there are > > EACCES failures. This assumes that the client "should always be able > > to > > write the file, if it was mmap'd". This trick hasn't been used for > > non-mmap'd > > writes, presumably because it was felt that the per-wrire RPC access > > check > > was a good thing that the client shouldn't be circumventing. > > Well, we always have a credential for normal writes, with mmap() we > don't. > Presumably the open() will have to check for write permissions, so > even > what you suggest of just using the uid of the file might be fine. > > -- > John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 03:10:17 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0380106564A; Tue, 3 Apr 2012 03:10:16 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 686278FC08; Tue, 3 Apr 2012 03:10:16 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 0413AC4B60; Tue, 3 Apr 2012 05:10:02 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 3VSuFgcJfFBz; Tue, 3 Apr 2012 05:10:01 +0200 (CEST) Received: from [172.17.136.194] (adsl-66-120-169-242.dsl.sntc01.pacbell.net [66.120.169.242]) by smtp.semihalf.com (Postfix) with ESMTPSA id 8D9C6C4B48; Tue, 3 Apr 2012 05:09:59 +0200 (CEST) Message-ID: <4F7A6A0B.5000308@semihalf.com> Date: Tue, 03 Apr 2012 05:10:03 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: geom@FreeBSD.org, fs@FreeBSD.org Subject: Re: Review of projects/nand branch 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: Tue, 03 Apr 2012 03:10:17 -0000 W dniu 2012-04-02 23:37, Marcel Moolenaar pisze: > Grzegorz, > > I reviewed the changes on the projects/nand branch and in general > it's of high quality and any problems, improvements and/or cleanups > can be addressed after it gets merged into -current, with the > following caveat: > 1. Changes to sys/kern, sys/geom and sys/sys should be reviewed and > approved by people on fs@freebsd.org and/or geom@freebsd.org. I > saw comments from pjd already for example. > 2. Please address the following points before merging onto head: > > o In include/Makefile: fs/fifofs is removed. Deliberate? > o In sbin/Makefile: we should have a distinct MK_NANDFS option > for use by the file system code. > o In sbin/nandfs/nandfs.8: could elaborate for what one could > use the snapshots. > o In sbin/nandfs/nandfs.h: define NANDFS_H. > o In sbin/nandfs/nandfs.c: usage() is wrong. > o In sbin/nandfs/Makefile: $FreeBSD$ is missing. > o In sbin/mount_nandfs/mount_nandfs.8: copyright notice seems > bogusly copied. Also, cleanerd is gone so it needs updating. > o In sbin/mount_nandfs/mount_nandfs.c: cleanerd is gone, so > this file could do with a some cleanups. > o In sbin/mount_nandfs/Makefile: $FreeBSD$ is missing. > o In sbin/mount/mntopts.h: cleanerd is gone, so should not be > needed anymore. > o In sbin/newfs_nandfs/newfs_nandfs.c: we have CRC32 code for > re-use. No need to implement again. > o In sbin/newfs_nandfs/Makefile: missing DPADD. > o In share/mk/bsd.own.mk: Add NANDFS as well. May also want to > add NANDSIM separately. > o In share/man/man5/Makefile: should be NANDFS. > o In usr.sbin/nandtool/Makefile: missing $FreeBSD$ > o In usr.sbin/nandsim/Makefile: missing $FreeBSD$ > o usr.sbin/Makefile should have nandtool and nandsim when > MK_NAND is defined. > o In lib/Makefile: should be MK_NANDFS; not MK_NAND. > o In lib/libstand/nandfs.c: should use common CRC32 impl. > o In lib/libstand/Makefile: should be MK_NANDFS; not MK_NAND. > o Please get buy-in for changes to sys/kern/vfs_vnops.c, > sys/kern/vfs_bio.c and sys/kern/vfs_subr.c from people > on fs@freebsd.org. > o In sys/modules/Makefile: always build nandfs module. Make > nandsim module dependent on MK_NAND or MK_NANDSIM if added. > o Please get buy-in for changes to sys/geom/geom_dev.c, > sys/geom/geom_disk.c, sys/geom/geom_disk.h, sys/geom/geom.h > and sys/geom/geom_slice.c from people on geom@freebsd.org. > o Please get buy-in for changes to sys/sys/disk.h and > sys/sys/bio.h from people on either fs@freebsd.org or > geom@freebsd.org. > > I also have a general usability question relating snapshots. > Currently snapshots are read-only. A useful feature in the > embedded space is to make a snapshot, attempt a software > update and revert to the snapshot if and when the update fails > or gets aborted. Is it possible to extend the snapshot feature > in the future to allow for this use case (i.e. ignore any and > all modifications that happened after a snapshot was made and > mount the snapshot R/W as representing the current/latest state > of the file system)? > > I'd like to thank Semihalf and the Foundation for bringing > this code into FreeBSD. Well done! > Thanks for the comments. We are going to get rid of all the changes in files from sys/geom, sys/sys, and sys/kern directories. Soon those changes will be merged into nand project branch. For the rest of your changes, let us go through them and then we will response to them. thanks, grzesiek From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 08:11:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E0D21065670 for ; Tue, 3 Apr 2012 08:11:08 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.freebsd.org (Postfix) with ESMTP id CAE388FC0C for ; Tue, 3 Apr 2012 08:11:07 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail27.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q338AobN031642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 18:10:56 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q338Amm2026016; Tue, 3 Apr 2012 18:10:48 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q338Amhg026015; Tue, 3 Apr 2012 18:10:48 +1000 (EST) (envelope-from peter) Date: Tue, 3 Apr 2012 18:10:48 +1000 From: Peter Jeremy To: Beeblebrox Message-ID: <20120403081048.GB25776@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Diskless client mount NFS-root error 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: Tue, 03 Apr 2012 08:11:08 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Apr-02 12:28:05 +0300, Beeblebrox wrote: >Client boots fine and gets to mounting root from NFS, but then stops with: >"Mounting root filesystem rw failed, startup aborted" and drops to >single-user mode. =2E... >*/etc/exports*: /data/amd64 -ro -maproot=3D0 -network 192.168.2.0/24 You're exporting the root read-only so it's unlikely the client will be able to write. --=20 Peter Jeremy --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEUEARECAAYFAk96sIgACgkQ/opHv/APuIeRyACfbJ/JKXiajYA5vhnFFIfCpUsI /6gAlArt+ai0E8qB0TwIDCYLrMMa1Vo= =nFGK -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 08:44:14 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51999106564A for ; Tue, 3 Apr 2012 08:44:14 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C1E608FC15 for ; Tue, 3 Apr 2012 08:44:13 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3905285bkc.13 for ; Tue, 03 Apr 2012 01:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HRSsINOSxrWigkYoqRARwhJuNwgWBhxhndfx1qDvPHM=; b=FwyoxGqxazFaOBqLCQsZ1QKokLeYz23rVjtk0Xdxkn5v6epq4nVB9xnSJaF7yBkDS6 tR4y8eOxz+h/nSrmLI5sxwaoMje9SrpYxEcNVl/96xSACf8KknxtPhQ+LSusvdi4iiq6 ld87Xwo9c9ZNuRiID35QYm4EpkrcB4YYBb+Oop62rDSkWbyXyEs2LSz4td48sq2fjoMC 0Ww0WK3/zbBwbaELHhC9ha2Jd9Ifw1xo4QWPBUW91dRJIDtqYCWWVpdh56KapiO9PSK9 TSoT0p2LmvU3JAzjViTKDCt/d3CPBbJPTCd9Un3plfRmIJ593zknAlKR5RadFnc3tnsI y10w== Received: by 10.204.143.138 with SMTP id v10mr4907285bku.99.1333442652768; Tue, 03 Apr 2012 01:44:12 -0700 (PDT) Received: from green.tandem.local (62-113-132-95.pool.ukrtel.net. [95.132.113.62]) by mx.google.com with ESMTPS id z14sm41107605bky.15.2012.04.03.01.44.10 (version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 01:44:11 -0700 (PDT) Message-ID: <4F7AB858.3030709@gmail.com> Date: Tue, 03 Apr 2012 11:44:08 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Peter Maloney References: <4F75C7EC.30606@gmail.com> <4F75E05D.2060206@brockmann-consult.de> In-Reply-To: <4F75E05D.2060206@brockmann-consult.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS v28 and free space leakage 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: Tue, 03 Apr 2012 08:44:14 -0000 Peter Maloney wrote: > I think you ran zpool list... Does zfs list show the same? > zfs list -rt all kohrah1 NAME USED AVAIL REFER MOUNTPOINT kohrah1 22,5M 134G 31K /kohrah1 > Do you have any snapshots or clones? None. > What sort of vdevs do you have? pool: kohrah1 state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Fri Mar 30 17:25:16 2012 config: NAME STATE READ WRITE CKSUM kohrah1 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da3 ONLINE 0 0 0 da0 ONLINE 0 0 0 errors: No known data errors > Does creating an empty pool show 0 used? What about after adding more > datasets? As I have mirrored pool I'll split it for now and make some tests on other disk. # zpool split kohrah1 kohrah1new # zpool import kohrah1new # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - kohrah1new 136G 21,7M 136G 0% 1.00x ONLINE - # zpool status pool: kohrah1 state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Fri Mar 30 17:25:16 2012 config: NAME STATE READ WRITE CKSUM kohrah1 ONLINE 0 0 0 da3 ONLINE 0 0 0 errors: No known data errors pool: kohrah1new state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Fri Mar 30 17:25:16 2012 config: NAME STATE READ WRITE CKSUM kohrah1new ONLINE 0 0 0 da0 ONLINE 0 0 0 errors: No known data errors # zpool destroy kohrah1new # zpool create -O compression=on -O atime=off kohrah1new da0 # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - kohrah1new 136G 110K 136G 0% 1.00x ONLINE - Fine for me now, 110K seems reasonable. > Do you have datasets? They might use some for metadata. None of them as shown above. > Here begins the guessing and/or babbling... > > And I haven't tried this with zfs, but I know with ext on Linux, if you > fill up a directory, and delete all the files in it, the directory takes > more space than before it was filled (du will include this space when > run). So be very thorough with how you calculate it. Maybe zfs did the > same thing with metadata structures, and just left them allocated empty > (just a guess). > > To prove there is a leak, you would need to fill up the disk, delete > everything, and then fill it again to see if it fit less. If I did such > a test and it was the same, I would just forget about the problem. kk, throwing junk in: # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - kohrah1new 136G 2,29G 134G 1% 1.00x ONLINE - # find /kohrah1new/ | wc -l 150590 # rm -rf /kohrah1new/* # find /kohrah1new/ /kohrah1new/ # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - kohrah1new 136G 436K 136G 0% 1.00x ONLINE - Not a same test you ask but it seems that ZFS leaks on metadata. Or peruses them. Repeating the same tasks results in: # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - kohrah1new 136G 336K 136G 0% 1.00x ONLINE - So this feels like some leftover. > Perhaps another interesting experiment would be to zfs send the pool to > see if the destination pool ends up in the same state. This one is interesting: # zfs snapshot kohrah1@test # zfs send kohrah1@test | zfs receive -F kohrah1new # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - kohrah1new 136G 248K 136G 0% 1.00x ONLINE - So it frees up some space. If I do this on the clean pool: # zpool destroy kohrah1new # zpool create -O compression=on -O atime=off kohrah1new da0 # zfs send kohrah1@test | zfs receive -F kohrah1new # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - kohrah1new 136G 92,5K 136G 0% 1.00x ONLINE - So dump doesn't contain any leftover. However pool counts this leftover as data and replicates it: # zpool destroy kohrah1new # zpool attach kohrah1 da3 da0 # zpool status pool: kohrah1 state: ONLINE scan: resilvered 22,4M in 0h0m with 0 errors on Tue Apr 3 11:34:31 2012 config: NAME STATE READ WRITE CKSUM kohrah1 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da3 ONLINE 0 0 0 da0 ONLINE 0 0 0 errors: No known data errors -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 09:11:57 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 DC3F8106566C for ; Tue, 3 Apr 2012 09:11:56 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 172728FC18 for ; Tue, 3 Apr 2012 09:11:55 +0000 (UTC) Received: by lagv3 with SMTP id v3so6111862lag.13 for ; Tue, 03 Apr 2012 02:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/kX0J5C5bZJOOKgKtO/LJr11qO9UOxsx6XOQC9XaiSE=; b=eHorSbRQJ84X2hYN03nVfdykyqVJMNhhBz1veUhpczQgAkyUUphpCtz9eCnhrI76TN 5T8RuS1f/eP+RfNUn9nbcSJ2Qjqvy8mn7jZS84mCQGyrNbFm3T9Cnoy/5vvldT1eLVAt cBpYAugTtFj+xARDWkk4Cky7etJ16MUf6zjWE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=/kX0J5C5bZJOOKgKtO/LJr11qO9UOxsx6XOQC9XaiSE=; b=g/UFE6636oLnBuuO06JNjWicMmGRD8pFAQUXpCatPIVEdUoqAD3fqGbCeXHIaWOAXI L9j9S8OfB5ZiL5J4dkzbucHsh2nT6bm4lXfIM2hylcBSs/SrzIjAhMlhH7RAPbT4T7YG q2Plhc3TI8DqUwe66qI46Iiua34e9614pOiePG8uINcVov83gkwWNeSMr7n58EKSzL9P nZ4eu3OeTkemmf4J8VKBDEg1h0r1aXdl8tTrvqZz+klT8KfwLGfPF+Hns/+N3JU/Hn3T CPIw4DszET0sD6KpfMPorvnCJiIXP0wvrGE9NeblLCUQoNIho2oH9xJVAVZSSzUxKmt/ 3+nA== MIME-Version: 1.0 Received: by 10.152.110.170 with SMTP id ib10mr13767095lab.7.1333444315050; Tue, 03 Apr 2012 02:11:55 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Tue, 3 Apr 2012 02:11:55 -0700 (PDT) X-Originating-IP: [85.110.29.196] In-Reply-To: <20120403081048.GB25776@server.vk2pj.dyndns.org> References: <20120403081048.GB25776@server.vk2pj.dyndns.org> Date: Tue, 3 Apr 2012 12:11:55 +0300 X-Google-Sender-Auth: IFLkJLzt6fppND_Neu4vE9MkewI Message-ID: From: Beeblebrox To: freebsd-fs@freebsd.org X-Gm-Message-State: ALoCoQm2VGLzIDPEUJz2CHSUOkq+X9kd9OCvqbZTg6WtjSnUHPQ68bcJT4gnkEdQq9BOBQuo5P3z Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Diskless client mount NFS-root error 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: Tue, 03 Apr 2012 09:11:57 -0000 Hi Peter, thanks for holding my hand :)) folder /data/amd64/conf/ has etc & var which are mounted r/w as md0, md1 onto client for its write needs. Other than that, why would a DC need write privilege for root? Also /home is separate export. Thanks. On Tue, Apr 3, 2012 at 11:10 AM, Peter Jeremy wrote: > On 2012-Apr-02 12:28:05 +0300, Beeblebrox wrote: > >Client boots fine and gets to mounting root from NFS, but then stops with: > >"Mounting root filesystem rw failed, startup aborted" and drops to > >single-user mode. > .... > >*/etc/exports*: /data/amd64 -ro -maproot=0 -network 192.168.2.0/24 > > You're exporting the root read-only so it's unlikely the client > will be able to write. > > -- > Peter Jeremy > From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 09:29:18 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 A1A63106566B; Tue, 3 Apr 2012 09:29:18 +0000 (UTC) (envelope-from joelh@juniper.net) Received: from thor.piquan.org (unknown [IPv6:2001:470:1f05:1741:201:2ff:fe8b:103e]) by mx1.freebsd.org (Postfix) with ESMTP id 7833E8FC0C; Tue, 3 Apr 2012 09:29:18 +0000 (UTC) Received: from frigg.pvt.piquan.org (frigg.pvt.piquan.org [192.168.13.48]) (authenticated bits=0) by thor.piquan.org (8.14.5/8.14.5) with ESMTP id q339T35v069799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Apr 2012 02:29:03 -0700 (PDT) (envelope-from joelh@juniper.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joel Ray Holveck In-Reply-To: <1615948459.2113806.1333381510230.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 3 Apr 2012 02:29:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <06CD28BD-97DE-4E36-A5E3-831386E3F523@juniper.net> References: <1615948459.2113806.1333381510230.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1257) Cc: alc@freebsd.org, freebsd-fs@freebsd.org, David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Tue, 03 Apr 2012 09:29:18 -0000 On 02 Apr 2012, at 8:45, Rick Macklem wrote: > Joel argued that the credential reference in vm_object_t wasn't NFS = specific > for the same reason. (ie. He felt it might be useful for other = filesystems, > such as smbfs. He had at least one other one, but I can't remember = which one;-) NFS, smbfs, and nwfs (NetWare) were the three that I identified in = 8.3-RC1 (based on a brief grep for curthread). They looked like they = had copied it from NFS (down to "/* XXX */" next to where they set the = creds from curthread), and they did pass that cred down, but I didn't = look closely at where it was ultimately used. I didn't look at anything in ports. joelh= From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 11:24:09 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 E61281065670 for ; Tue, 3 Apr 2012 11:24:09 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABF78FC15 for ; Tue, 3 Apr 2012 11:24:08 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id q33BO4Wf044948; Tue, 3 Apr 2012 12:24:04 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id q33BO4J3022007; Tue, 3 Apr 2012 12:24:04 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id q33BO4NM022004; Tue, 3 Apr 2012 12:24:04 +0100 Date: Tue, 3 Apr 2012 12:24:04 +0100 Message-Id: <201204031124.q33BO4NM022004@higson.cam.lispworks.com> From: Martin Simmons To: Beeblebrox In-reply-to: (message from Beeblebrox on Tue, 3 Apr 2012 12:11:55 +0300) References: <20120403081048.GB25776@server.vk2pj.dyndns.org> Cc: freebsd-fs@freebsd.org Subject: Re: Diskless client mount NFS-root error 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: Tue, 03 Apr 2012 11:24:10 -0000 >>>>> On Tue, 3 Apr 2012 12:11:55 +0300, Beeblebrox said: On Tue, Apr 3, 2012 at 11:10 AM, Peter Jeremy wrote: > > folder /data/amd64/conf/ has etc & var which are mounted r/w as md0, > md1 onto client for its write needs. Other than that, why would a DC need > write privilege for root? Also /home is separate export. See /etc/rc.d/root and adjust your /etc/rc.conf accordingly. __Martin From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 11:46:34 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A0E2106566C for ; Tue, 3 Apr 2012 11:46:34 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBF818FC08 for ; Tue, 3 Apr 2012 11:46:33 +0000 (UTC) Received: by lagv3 with SMTP id v3so6335599lag.13 for ; Tue, 03 Apr 2012 04:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5HL0vKW0n4gH3iCJVC4bCv/ang/+8oSHQ9yyNpcnRtM=; b=N9PGXzoOSMQRNAY7JzanKRkKHhdO5ljJnUj+ZyxFbMtzm6CycX2t/WIVCrkeOvsq+3 e+A4osAJrMvvIcXYJUm+x9c+r+x2JH5jOFrLMrAJ+Oou6xVHnYYwa02WRYEPeB0dZjGP DSvMiZFK2WwO8QqbVLKOANnvQ28+pZ40u3hmM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=5HL0vKW0n4gH3iCJVC4bCv/ang/+8oSHQ9yyNpcnRtM=; b=mMazM1JKi6plnoW7r+HWbgfoGgtMAIAahi3AiiMBhVJ5wYaY/OyRD0cYV77C0pIOB/ qw1TpKvTB7H3FiZdmykCWaCZykcySrHPZtguZz34roOMhEXRpnrJoEr0NDR7Ar/tOB/V xhOscDbDkKFwOqjJqq3li2SC7Da9kXQ0GC2gBBR8Ody6/JdVr4BMEd8mHvkrnNii/HIT rg94Wk2mzW53JrYQ7K7ZZfcHIJuieYGRaVFbp3bTMur/qlcrScm4wZCh8737Pu5AJgX3 0S4Luv8T+tFVwoyuStaci5gOjf71W5/egQBeWudqS3dALzTILqSgKU9bNdjk3/aAJGL/ I/hw== MIME-Version: 1.0 Received: by 10.152.105.241 with SMTP id gp17mr14242511lab.21.1333453592663; Tue, 03 Apr 2012 04:46:32 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Tue, 3 Apr 2012 04:46:32 -0700 (PDT) X-Originating-IP: [85.110.29.196] In-Reply-To: References: <20120403081048.GB25776@server.vk2pj.dyndns.org> <201204031124.q33BO4NM022004@higson.cam.lispworks.com> Date: Tue, 3 Apr 2012 14:46:32 +0300 X-Google-Sender-Auth: 4rj6IEy_fo8tVYPNJehtExLlM2A Message-ID: From: Beeblebrox To: freebsd-fs@freebsd.org X-Gm-Message-State: ALoCoQmfGYkoTsdg+9JzUb2Im7EH1c99XqlIgVA0+wDxUEHy+MpYrRGVtZLxcaUr0s3aIx1wJVWx Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Diskless client mount NFS-root error 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: Tue, 03 Apr 2012 11:46:34 -0000 ---------- Forwarded message ---------- From: Beeblebrox Date: Tue, Apr 3, 2012 at 2:44 PM Subject: Re: Diskless client mount NFS-root error To: Martin Simmons On Tue, Apr 3, 2012 at 2:24 PM, Martin Simmons wrote: > >>>>> On Tue, 3 Apr 2012 12:11:55 +0300, Beeblebrox said: > On Tue, Apr 3, 2012 at 11:10 AM, Peter Jeremy wrote: > > > > folder /data/amd64/conf/ has etc & var which are mounted r/w as md0, > > md1 onto client for its write needs. Other than that, why would a DC need > > write privilege for root? Also /home is separate export. > > See /etc/rc.d/root and adjust your /etc/rc.conf accordingly. > > __Martin > As I had noted in my fist post: > I commented out [stop_boot true] in diskless/etc/rc.d/root. Is there a flag in rc.conf to which can be passed to rc.d/root? From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 12:03:25 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 BE823106566C for ; Tue, 3 Apr 2012 12:03:25 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC8B8FC22 for ; Tue, 3 Apr 2012 12:03:25 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id q33C3L1h046648; Tue, 3 Apr 2012 13:03:21 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id q33C3LYQ022451; Tue, 3 Apr 2012 13:03:21 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id q33C3L7i022447; Tue, 3 Apr 2012 13:03:21 +0100 Date: Tue, 3 Apr 2012 13:03:21 +0100 Message-Id: <201204031203.q33C3L7i022447@higson.cam.lispworks.com> From: Martin Simmons To: Beeblebrox In-reply-to: (message from Beeblebrox on Tue, 3 Apr 2012 14:46:32 +0300) References: <20120403081048.GB25776@server.vk2pj.dyndns.org> <201204031124.q33BO4NM022004@higson.cam.lispworks.com> Cc: freebsd-fs@freebsd.org Subject: Re: Diskless client mount NFS-root error 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: Tue, 03 Apr 2012 12:03:25 -0000 >>>>> On Tue, 3 Apr 2012 14:46:32 +0300, Beeblebrox said: > > On Tue, Apr 3, 2012 at 2:24 PM, Martin Simmons wrote: > > > >>>>> On Tue, 3 Apr 2012 12:11:55 +0300, Beeblebrox said: > > On Tue, Apr 3, 2012 at 11:10 AM, Peter Jeremy wrote: > > > > > > folder /data/amd64/conf/ has etc & var which are mounted r/w as md0, > > > md1 onto client for its write needs. Other than that, why would a DC need > > > write privilege for root? Also /home is separate export. > > > > See /etc/rc.d/root and adjust your /etc/rc.conf accordingly. > > > > __Martin > > > > As I had noted in my fist post: > > I commented out [stop_boot true] in diskless/etc/rc.d/root. > Is there a flag in rc.conf to which can be passed to rc.d/root? I was hoping you would find root_rw_mount by reading rc.d/root again. __Martin From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 12:55:45 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1A101065674; Tue, 3 Apr 2012 12:55:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5CFAA8FC08; Tue, 3 Apr 2012 12:55:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C1627B960; Tue, 3 Apr 2012 08:55:44 -0400 (EDT) From: John Baldwin To: Rick Macklem Date: Tue, 3 Apr 2012 08:53:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <394500062.2166073.1333418575016.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <394500062.2166073.1333418575016.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201204030853.34267.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Apr 2012 08:55:44 -0400 (EDT) Cc: alc@freebsd.org, freebsd-fs@freebsd.org, Joel Ray Holveck , David Wolfskill Subject: Re: RFC: which patch is preferred for fix to PR#165923 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: Tue, 03 Apr 2012 12:55:45 -0000 On Monday, April 02, 2012 10:02:55 pm Rick Macklem wrote: > John Baldwin wrote: > > On Monday, April 02, 2012 11:45:10 am Rick Macklem wrote: > > > > > However, there seems to be some disagreement as to how a patch > > > > > to > > > > > use the mmap() credentials should be done. > > > > > > > > > > putpages-a.patch - This one captures the credentials during the > > > > > mmap() > > > > > call by using the property that only mmap() calls > > > > > vnode_pager_alloc() > > > > > with "prot != 0" and references them in a new field in > > > > > vm_object_t. > > > > > > > > > > putpages-b.patch - This one adds a new VOP_PUTPAGES_NOTIFY() > > > > > call, > > > > > which > > > > > is done by mmap(). For all file systems except NFS clients, > > > > > it is > > > > > a > > > > > null op. For the NFS clients, they reference the credentials > > > > > in a > > > > > new field of the NFS specific part of the vnode. > > > > > > > > > > - I don't have a patch for the third one, but I believe Joel was > > > > > proposing > > > > > something similar to putpages-a.patch, except that the > > > > > credentials are > > > > > passed as an extra argument to VOP_PUTPAGES(), instead of the > > > > > NFS > > > > > client's > > > > > VOP_PUTPAGES() looking in the vnode's vm_object_t for the > > > > > cred. > > > > > > > > I think what I would prefer for the longterm is option 3) (and > > > > possibly doing > > > > the same for VOP_GETPAGES(). Also, I would call the new field in > > > > vm_object > > > > something like 'writecred'. For MFC purposes you could use > > > > putpages-a.patch > > > > instead and only make the change to the VOPs in HEAD. > > > > > > > > However, I wonder if you can't manage this all at the vnode layer? > > > > If > > > > all > > > > you need is a credential that is allowed to write, can't you cache > > > > the > > > > credential used for a successful VOP_ACCESS() check with write > > > > support > > > > in the > > > > nfsnode and just use that for write RPCs? The same thing would > > > > work > > > > for > > > > reads, yes? I know for NFSv4 you already maintain a cache of > > > > credentials > > > > from open()'s that you use for other RPC's already, so this would > > > > seem > > > > to be > > > > similar to that case. This would also let you do the "list of > > > > credentials" > > > > idea if needed and even let you add new write-capable credentials > > > > to > > > > the list > > > > via VOP_ACCESS() calls after the file was mmap()'d or open()'d. > > > > > > > I think there is a question w.r.t. should you use credentials that > > > weren't > > > ones that mmap'd the file with PROT_WRITE. > > > > But you already are potentially (in that you might mismatch > > permissions > > for a given WRITE since the page might have been dirtied by a > > different > > user than the credential we use). You have to open() the file with > > write > > permissions before you mmap() it, so all mmap()'s are going to do a > > VOP_ACCESS() prior, so if you just cache whatever credential last > > worked > > for write access to VOP_ACCESS() that would more or less work, and be > > about as reliable while not requiring any changes outside of the NFS > > client itself. > > > Taking a reference to the cred passed to the most recent VOP_OPEN() with > FWRITE for the vnode and keeping that in the nfs specific vnode sounds ok > to me. Ok. > The only issue is that the NFS client will do this for many vnodes that > never get mmap'd, but that just means more credentials may be allocated > for longer. (As I understand it, the crfree() can't be done until the > NFS VOP_INACTIVE()/VOP_RECLAIM(), since writing to mmap'd files can happen > after the file descriptor is closed.) In practice the credential is already referenced by the open file handle most of the time anyway, plus many processes and files may all share the same credential, so I think this would be fine in practice. > This would avoid any new/modified VOPs and any changes to vm_object_t. Yes. If others are ok with this approach I think it is the simplest fix. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 12:56:41 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 853C61065672 for ; Tue, 3 Apr 2012 12:56:41 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E21C18FC1B for ; Tue, 3 Apr 2012 12:56:40 +0000 (UTC) Received: by lagv3 with SMTP id v3so6441556lag.13 for ; Tue, 03 Apr 2012 05:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=JZ3h6jNvRUhj2b0qv/tBlzqv+hKVCLDP6VE7HH1PTwI=; b=PLVUordY98+UMxPwTPu7SHNi7LduG+A/0Xq9z44iem5qcPtSYudBm4Mc82W3secduo NP4ivxeEIpviAnVvAQDoaDR7cVMPPaFCnkS9DD+tbc02RKwtOUV7H93ixGpt4jarr5hb NZvqqu1iLHrcwS/EbTMMCQDyOpJ2VHhvqH8Ms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=JZ3h6jNvRUhj2b0qv/tBlzqv+hKVCLDP6VE7HH1PTwI=; b=l6tRSA454PtNC6QO7+LIBjxAvC/khSGiiHLrWG5gkAfRNNcSPY1hvWCvXqSQDP+L/m AaMYveXJzkIgqalrrW8mSjJUqEUvzSkShvNR/NvNxlzm9MxI0t6wYcPghEb3pMCeyREN iYiPtYQNtIbGQFN3cDHS31v6lNmQsg8/kmFdGLK15tVSVLkL8LwYJ2+zqAf5SqetIkqg Cyobmyf5/sxHbvqLI1to9j8devn3HOd+x3SVU2IwvPgRFPOwtgegzHIlLhEGWA1n0l8Y A9giI9nTP1a6Vm2Q7IHuHGQtV3a6qAwvAblW1Eb/UFH2kbgPx++4Zxtzc/DWq2CFjz0i h+wg== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr5121374lab.35.1333457799415; Tue, 03 Apr 2012 05:56:39 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Tue, 3 Apr 2012 05:56:39 -0700 (PDT) X-Originating-IP: [85.110.92.106] In-Reply-To: <201204031203.q33C3L7i022447@higson.cam.lispworks.com> References: <20120403081048.GB25776@server.vk2pj.dyndns.org> <201204031124.q33BO4NM022004@higson.cam.lispworks.com> <201204031203.q33C3L7i022447@higson.cam.lispworks.com> Date: Tue, 3 Apr 2012 15:56:39 +0300 X-Google-Sender-Auth: OhEnqW-2bqaExgqLAvS_hSdIFf4 Message-ID: From: Beeblebrox To: freebsd-fs@freebsd.org X-Gm-Message-State: ALoCoQmOWcoDAZGvGcX4g10Om5qHSZGUv/QDGVbu9MNXyXDt0f76sRftVBpb41FlXyzFe50COGDw Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Diskless client mount NFS-root error 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: Tue, 03 Apr 2012 12:56:41 -0000 On Tue, Apr 3, 2012 at 3:03 PM, Martin Simmons wrote: > >>>>> On Tue, 3 Apr 2012 14:46:32 +0300, Beeblebrox said: > > > > On Tue, Apr 3, 2012 at 2:24 PM, Martin Simmons > wrote: > > > > > >>>>> On Tue, 3 Apr 2012 12:11:55 +0300, Beeblebrox said: > > > On Tue, Apr 3, 2012 at 11:10 AM, Peter Jeremy > wrote: > > > > > > > > folder /data/amd64/conf/ has etc & var which are mounted r/w as > md0, > > > > md1 onto client for its write needs. Other than that, why would a DC > need > > > > write privilege for root? Also /home is separate export. > > > > > > See /etc/rc.d/root and adjust your /etc/rc.conf accordingly. > > > > > > __Martin > > > > > > > As I had noted in my fist post: > > > I commented out [stop_boot true] in diskless/etc/rc.d/root. > > Is there a flag in rc.conf to which can be passed to rc.d/root? > > I was hoping you would find root_rw_mount by reading rc.d/root again. > > __Martin > I did not realize that root_rw_mount="NO" was declarable in rc.conf. Thank you for your help - SOLVED From owner-freebsd-fs@FreeBSD.ORG Tue Apr 3 13:22:13 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41B1D106566C for ; Tue, 3 Apr 2012 13:22:13 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id B79CC8FC12 for ; Tue, 3 Apr 2012 13:22:12 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lg6qx-1SYNzK2KQl-00onFQ; Tue, 03 Apr 2012 15:22:05 +0200 Message-ID: <4F7AF97D.7060307@brockmann-consult.de> Date: Tue, 03 Apr 2012 15:22:05 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Volodymyr Kostyrko References: <4F75C7EC.30606@gmail.com> <4F75E05D.2060206@brockmann-consult.de> <4F7AB858.3030709@gmail.com> In-Reply-To: <4F7AB858.3030709@gmail.com> X-Enigmail-Version: 1.4 Content-Type: multipart/mixed; boundary="------------020307070107060600020708" X-Provags-ID: V02:K0:yLmL5phZvgyI1qq35vC6Cd2o/jbVeJhP3Bf83LM3hpk AmXTuoV6GZ0oqELZiWNe6VXm2MEW8xOdYuW0tmMFC9V45UIHk9 6o6lNWGOxuXMBU7CGotiwlsH7yXbJ5nJKfQvR6Nj/Vsg8s/Ve/ BxWmymSM+0xVwY1P0yXiRBDd13AK/gdaEGtESqR+XMqA42Mzq7 G57z+M+GWhsp0CQmS8O+5vJPI9kgyrsw2yVBnpv9emf78Krf// 8DaMIeSZfRyKdrPc4XpvrKaFSDtlFfoYoh/8BqsDYs1iBH70Hj 8fJ5m181icIUu2+5G8YaL/MtV+Tf6rZC4WXncm7ikx8kUV+aiE KcTmq5uc+OSsjzbQnsokwIqCIOfw0c7ifYmo5mvJl Cc: freebsd-fs@freebsd.org Subject: Re: ZFS v28 and free space leakage 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: Tue, 03 Apr 2012 13:22:13 -0000 This is a multi-part message in MIME format. --------------020307070107060600020708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/03/2012 10:44 AM, Volodymyr Kostyrko wrote: > Peter Maloney wrote: >> To prove there is a leak, you would need to fill up the disk, delete >> everything, and then fill it again to see if it fit less. If I did such >> a test and it was the same, I would just forget about the problem. > > kk, throwing junk in: > > # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - > kohrah1new 136G 2,29G 134G 1% 1.00x ONLINE - > # find /kohrah1new/ | wc -l > 150590 > # rm -rf /kohrah1new/* > # find /kohrah1new/ > /kohrah1new/ > # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - > kohrah1new 136G 436K 136G 0% 1.00x ONLINE - > > Not a same test you ask but it seems that ZFS leaks on metadata. Or > peruses them. Repeating the same tasks results in: Yes, my test was suggested so you would really fill it to the limit, and then delete and refill. It was expected that when removing, the "ALLOC" is high still, but the hypothesis was that it is just blank allocated space for data that doesn't exist, and will be reused when it is filled again. So to test what I wanted, you really need to fill it to the max twice. I thought you would do this since your pool is only 136 GB. So I decided to try it in a virtual machine, with a very small disk (700 MB slice). The result is attached. The conclusion is that the space is not really missing... if anything is missing it is probably less than a kilobyte after filling and removing all more than 11 times, probably 40 or 50 times. > > # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > kohrah1 136G 22,4M 136G 0% 1.00x ONLINE - > kohrah1new 136G 336K 136G 0% 1.00x ONLINE - > > So this feels like some leftover. --------------020307070107060600020708 Content-Type: text/plain; charset=UTF-8; name="zfsSpaceLeakExperiment.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="zfsSpaceLeakExperiment.txt" PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KemZzIHNwYWNlIGxlYWsgZXhwZXJp bWVudAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKUHJlcGFyZToKCltyb290 QGJjemZzdm0xdGVzdCAvdGVzdF0jIHVuYW1lIC1hCkZyZWVCU0QgYmN6ZnN2bTF0ZXN0LmJj LmxvY2FsIDguMi1TVEFCTEUtMjAxMjAyMDQgRnJlZUJTRCA4LjItU1RBQkxFLTIwMTIwMjA0 ICMwOiBNb24gRmViICA2IDEyOjEwOjMyIFVUQyAyMDEyICAgICByb290QGJjemZzdm0xLmJj LmxvY2FsOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgIGFtZDY0Cgpbcm9vdEBiY3pm c3ZtMXRlc3Qgfl0jIHpwb29sIGNyZWF0ZSB0ZXN0IGRhMiAgICAgICAgICAgIAoKW3Jvb3RA YmN6ZnN2bTF0ZXN0IH5dIyB6cG9vbCBsaXN0IHRlc3QgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIApOQU1FICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENB UCAgREVEVVAgIEhFQUxUSCAgQUxUUk9PVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCnRl c3QgIDE5LjlHICA3OC41SyAgMTkuOUcgICAgIDAlICAxLjAweCAgT05MSU5FICAtICAgICAg ICAgICAgCgpbcm9vdEBiY3pmc3ZtMXRlc3Qgfl0jIHpmcyBsaXN0IHRlc3QKTkFNRSAgIFVT RUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgIDkxSyAgMTkuNkcgICAgMzFL ICAvdGVzdAoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IH5dIyBjZCAvdGVzdApbcm9vdEBiY3pmc3Zt MXRlc3Qgfl0jIGNobW9kIHVnbz1yd3ggLgoKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09CnRlc3QxYQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCltyb290QGJjemZz dm0xdGVzdCAvdGVzdF0jIGNwIH4vRnJlZUJTRC04LjItU1RBQkxFLTIwMTIwMjA0LmlzbyAx CmNwOiAxOiBObyBzcGFjZSBsZWZ0IG9uIGRldmljZQoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90 ZXN0XSMgbHMgLWwgCnRvdGFsIDY3NTE3Ngotcnctci0tci0tICAxIHJvb3QgIHdoZWVsICA2 OTA4ODA1MTIgRmViIDIyIDE3OjUxIDEKCltyb290QGJjemZzdm0xdGVzdCAvdGVzdF0jIHpm cyBsaXN0IHRlc3QKTkFNRSAgICBVU0VEICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVz dCAgIDY2ME0gICAgICAwICAgNjU5TSAgL3Rlc3QKCltyb290QGJjemZzdm0xdGVzdCAvdGVz dF0jIHJtIDEKCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp0ZXN0MWIKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Cgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyBj cCAvdGVzdC9GcmVlQlNELTguMi1TVEFCTEUtMjAxMjAyMDQuaXNvIDIKY3A6IDI6IE5vIHNw YWNlIGxlZnQgb24gZGV2aWNlCgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyBscyAtbAp0 b3RhbCA2NzUxNzcKLXJ3LXItLXItLSAgMSByb290ICB3aGVlbCAgNjkwODgwNTEyIEZlYiAy MiAxNzo1MiAyCgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyB6ZnMgbGlzdCB0ZXN0Ck5B TUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA2NjBNICAgICAg MCAgIDY1OU0gIC90ZXN0Cgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyBybSAyCgo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KdGVzdDJhCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90ZXN0XSMgZm9yIGEgaW4gezEuLjEw fTsgZG8gbWtkaXIgJGE7IGRvbmUKCltyb290QGJjemZzdm0xdGVzdCAvdGVzdF0jIGZvciBh IGluIHsxLi4xMH07IGRvIG1rZGlyICRhOyBmb3IgYiBpbiB7MS4uNTAwMH07IGRvIGRkIGlm PS9kZXYvcmFuZG9tIG9mPSRhLyRiIGJzPTEyOGsgY291bnQ9MTA7IGRvbmU7IGRvbmUKCi4u LihydW5zIGxvbmcpCmRkOiAxLzEyMjc6IE5vIHNwYWNlIGxlZnQgb24gZGV2aWNlCgpbcm9v dEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyBkdSAtc3hjICoKNjc1MzkyICAxCjIgICAgICAgMTAK MiAgICAgICAyCjIgICAgICAgMwoyICAgICAgIDQKMiAgICAgICA1CjIgICAgICAgNgoyICAg ICAgIDcKMiAgICAgICA4CjIgICAgICAgOQo2NzU0MDUgIHRvdGFsCgpbcm9vdEBiY3pmc3Zt MXRlc3QgL3Rlc3RdIyB6ZnMgbGlzdCB0ZXN0Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVS ICBNT1VOVFBPSU5UCnRlc3QgICA2NjBNICAgMTg4SyAgIDY1OU0gIC90ZXN0Cgpbcm9vdEBi Y3pmc3ZtMXRlc3QgL3Rlc3RdIyB6cG9vbCBsaXN0IHRlc3QKTkFNRSAgICBTSVpFICBBTExP QyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2OTJNICAg NjYwTSAgMzIuMU0gICAgOTUlICAxLjAweCAgT05MSU5FICAtCgpbcm9vdEBiY3pmc3ZtMXRl c3QgL3Rlc3RdIyBybSAtcmYgKgoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90ZXN0XSMgemZzIGxp c3QgdGVzdApOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAg NDI0SyAgIDY2ME0gICAgMzFLICAvdGVzdAoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90ZXN0XSMg enBvb2wgbGlzdCB0ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENBUCAgREVE VVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDQ2MEsgICA2OTJNICAgICAwJSAg MS4wMHggIE9OTElORSAgLQoKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CnRlc3Qy Ygo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCltyb290QGJjemZzdm0xdGVzdCAv dGVzdF0jIGZvciBhIGluIHsxLi4xMH07IGRvIG1rZGlyICRhOyBmb3IgYiBpbiB7MS4uNTAw MH07IGRvIGRkIGlmPS9kZXYvcmFuZG9tIG9mPSRhLyRiIGJzPTEyOGsgY291bnQ9MTA7IGRv bmU7IGRvbmUKCi4uLihydW5zIGxvbmcpCmRkOiAxLzk3NzogTm8gc3BhY2UgbGVmdCBvbiBk ZXZpY2UKCltyb290QGJjemZzdm0xdGVzdCAvdGVzdF0jIGR1IC1zeGMgKgo2NzUzOTEgIDEK Njc1MzkxICB0b3RhbAoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90ZXN0XSMgemZzIGxpc3QgdGVz dApOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgNjYwTSAg ICAgIDAgICA2NTlNICAvdGVzdAoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90ZXN0XSMgenBvb2wg bGlzdCB0ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENBUCAgREVEVVAgIEhF QUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDY2ME0gIDMxLjhNICAgIDk1JSAgMS4wMHgg IE9OTElORSAgLQoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90ZXN0XSMgcm0gLXJmICoKCltyb290 QGJjemZzdm0xdGVzdCAvdGVzdF0jIHpmcyBsaXN0IHRlc3QKTkFNRSAgICBVU0VEICBBVkFJ TCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDQyMEsgICA2NjBNICAgIDMxSyAgL3Rlc3QK Cltyb290QGJjemZzdm0xdGVzdCAvdGVzdF0jIHpwb29sIGxpc3QgdGVzdApOQU1FICAgIFNJ WkUgIEFMTE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAg IDY5Mk0gICA0NTZLICAgNjkyTSAgICAgMCUgIDEuMDB4ICBPTkxJTkUgIC0KCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQp0ZXN0MmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Cgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyBmb3IgYSBpbiB7MS4uMTB9OyBk byBta2RpciAkYTsgZm9yIGIgaW4gezEuLjUwMDB9OyBkbyBkZCBpZj0vZGV2L3JhbmRvbSBv Zj0kYS8kYiBicz0xMjhrIGNvdW50PTEwOyBkb25lOyBkb25lCgouLi4ocnVucyBsb25nKQpk ZDogMS8xMTkyOiBObyBzcGFjZSBsZWZ0IG9uIGRldmljZQoKW3Jvb3RAYmN6ZnN2bTF0ZXN0 IC90ZXN0XSMgZHUgLXN4YyAqCjY3NTM4MCAgMQo2NzUzODAgIHRvdGFsCgpbcm9vdEBiY3pm c3ZtMXRlc3QgL3Rlc3RdIyB4PTE7IHdoaWxlIHRydWU7IGRvIHRvdWNoIGJsYWhfJHg7IGxl dCB4Kys7IGRvbmUKCltyb290QGJjemZzdm0xdGVzdCAvdGVzdF0jIGR1IC1zeGMgKgo2NzUz ODAgIDEKNjc1MzgwICB0b3RhbAoKW3Jvb3RAYmN6ZnN2bTF0ZXN0IC90ZXN0XSMgcm0gLXJm IC90ZXN0LyoKCihzbyBmYXIsIGl0IGxvb2tzIGxpa2UgYSB2ZXJ5IHNtYWxsIGFtb3VudCBi ZXR3ZWVuIDExIGtCIGFuZCAxNCBrQiBpcyBsb3N0IGV2ZXJ5IHRpbWUpCgo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KdGVzdDMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09CgpydW49MQpybSAtcmYgL3Rlc3QvKgp3aGlsZSB0cnVlOyBkbwogICAgZWNobyAiPT09 PT09PT09PT09PSIKICAgIGVjaG8gIlJ1biAjJHJ1biIKCiAgICBmdWxsPTAKICAgIGZvciBh IGluIHsxLi4xMH07IGRvIAogICAgICAgIG1rZGlyICRhCiAgICAgICAgZm9yIGIgaW4gezEu LjUwMH07IGRvIAogICAgICAgICAgICBkZCBpZj0vZGV2L3JhbmRvbSBvZj0kYS8kYiBicz0x MjhrIGNvdW50PTEwID4vZGV2L251bGwgMj4mMQogICAgICAgICAgICBpZiBbICIkPyIgIT0g MCBdOyB0aGVuCiAgICAgICAgICAgICAgICBmdWxsPTEKICAgICAgICAgICAgZmkKICAgICAg ICBkb25lCiAgICAgICAgaWYgWyAiJGZ1bGwiID0gMSBdOyB0aGVuCiAgICAgICAgICAgIGJy ZWFrCiAgICAgICAgZmkKICAgIGRvbmUKCiAgICBlY2hvICJGdWxsOiIKICAgIGR1IC1zeCAv dGVzdAogICAgemZzIGxpc3QgdGVzdAogICAgenBvb2wgbGlzdCB0ZXN0CgogICAgcm0gLXJm IC90ZXN0LyoKICAgIHNsZWVwIDMwCgogICAgZWNobyAiQ2xlYXI6IgogICAgemZzIGxpc3Qg dGVzdAogICAgenBvb2wgbGlzdCB0ZXN0CiAgICAKICAgIGxldCBydW4rKwpkb25lCgpvbGQg cnVuIHdpdGggdmVyc2lvbiAxIG9mIHRoZSBzY3JpcHQgKG9ubHkgZHUgb3V0cHV0KToKCjY3 NTI4MyAgMQo2NzUyODMgIHRvdGFsCjY3NTM4NyAgMQo2NzUzODcgIHRvdGFsCjY3NTI2NiAg MQo2NzUyNjYgIHRvdGFsCjY3NTUyMCAgMQo2NzU1MjAgIHRvdGFsCjY3NTM5OSAgMQo2NzUz OTkgIHRvdGFsCjY3NTI3MiAgMQo2NzUyNzIgIHRvdGFsCjY3NTM5MiAgMQo2NzUzOTIgIHRv dGFsCjY3NTUyNyAgMQo2NzU1MjcgIHRvdGFsCjY3NTI2OCAgMQo2NzUyNjggIHRvdGFsCjY3 NTM5OCAgMQo2NzUzOTggIHRvdGFsCgpydW4gd2l0aCB2ZXJzaW9uIDIgKHpmcyBsaXN0LCBl dGMuIGFkZGVkKToKCj09PT09PT09PT09PT0KUnVuICMxCkZ1bGw6CjY3NTI4MCAgL3Rlc3QK TkFNRSAgICBVU0VEICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY2ME0gICAg ICAwICAgNjU5TSAgL3Rlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBE RURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2OTJNICAgNjYwTSAgMzEuOE0gICAgOTUl ICAxLjAweCAgT05MSU5FICAtCkNsZWFyOgpOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAg TU9VTlRQT0lOVAp0ZXN0ICA4MC44TSAgIDU3OU0gIDgwLjJNICAvdGVzdApOQU1FICAgIFNJ WkUgIEFMTE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAg IDY5Mk0gIDgxLjBNICAgNjExTSAgICAxMSUgIDEuMDB4ICBPTkxJTkUgIC0KPT09PT09PT09 PT09PQpSdW4gIzIKRnVsbDoKNjc1NTQ3ICAvdGVzdApOQU1FICAgIFVTRUQgIEFWQUlMICBS RUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgNjYwTSAgICAgIDAgICA2NjBNICAvdGVzdApOQU1F ICAgIFNJWkUgIEFMTE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QK dGVzdCAgIDY5Mk0gICA2NjFNICAzMS41TSAgICA5NSUgIDEuMDB4ICBPTkxJTkUgIC0KQ2xl YXI6Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICAxMzJN ICAgNTI4TSAgIDEzMk0gIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENB UCAgREVEVVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDEzMk0gICA1NjBNICAg IDE5JSAgMS4wMHggIE9OTElORSAgLQo9PT09PT09PT09PT09ClJ1biAjMwpGdWxsOgo2NzUz OTggIC90ZXN0Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3Qg ICA2NjBNICAgICAgMCAgIDY1OU0gIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVF ICAgIENBUCAgREVEVVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDY2ME0gIDMx LjdNICAgIDk1JSAgMS4wMHggIE9OTElORSAgLQpDbGVhcjoKTkFNRSAgICBVU0VEICBBVkFJ TCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgNTkuNk0gICA2MDBNICA1OC45TSAgL3Rlc3QK TkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRS T09UCnRlc3QgICA2OTJNICA1OS44TSAgIDYzMk0gICAgIDglICAxLjAweCAgT05MSU5FICAt Cj09PT09PT09PT09PT0KUnVuICM0CkZ1bGw6CjY3NTI3NyAgL3Rlc3QKTkFNRSAgICBVU0VE ICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY2ME0gICAgICAwICAgNjU5TSAg L3Rlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRI ICBBTFRST09UCnRlc3QgICA2OTJNICAgNjYwTSAgMzEuOE0gICAgOTUlICAxLjAweCAgT05M SU5FICAtCkNsZWFyOgpOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0 ZXN0ICAzNC41TSAgIDYyNU0gIDMzLjlNICAvdGVzdApOQU1FICAgIFNJWkUgIEFMTE9DICAg RlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0gIDM0LjdN ICAgNjU3TSAgICAgNSUgIDEuMDB4ICBPTkxJTkUgIC0KPT09PT09PT09PT09PQpSdW4gIzUK RnVsbDoKNjc1MzkxICAvdGVzdApOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQ T0lOVAp0ZXN0ICAgNjYwTSAgICAgIDAgICA2NTlNICAvdGVzdApOQU1FICAgIFNJWkUgIEFM TE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0g ICA2NjBNICAzMS43TSAgICA5NSUgIDEuMDB4ICBPTkxJTkUgIC0KQ2xlYXI6Ck5BTUUgICAg VVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA1MDJNICAgMTU4TSAgIDUw Mk0gIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENBUCAgREVEVVAgIEhF QUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDUwMk0gICAxOTBNICAgIDcyJSAgMS4wMHgg IE9OTElORSAgLQo9PT09PT09PT09PT09ClJ1biAjNgpGdWxsOgo2NzUzODYgIC90ZXN0Ck5B TUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA2NjBNICAgICAg MCAgIDY1OU0gIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENBUCAgREVE VVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDY2ME0gIDMxLjlNICAgIDk1JSAg MS4wMHggIE9OTElORSAgLQpDbGVhcjoKTkFNRSAgICBVU0VEICBBVkFJTCAgUkVGRVIgIE1P VU5UUE9JTlQKdGVzdCAgODIuMU0gICA1NzhNICA4MS41TSAgL3Rlc3QKTkFNRSAgICBTSVpF ICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2 OTJNICA4Mi4yTSAgIDYxME0gICAgMTElICAxLjAweCAgT05MSU5FICAtCj09PT09PT09PT09 PT0KUnVuICM3CkZ1bGw6CjY3NTM5NSAgL3Rlc3QKTkFNRSAgICBVU0VEICBBVkFJTCAgUkVG RVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY2ME0gICAgICAwICAgNjU5TSAgL3Rlc3QKTkFNRSAg ICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRl c3QgICA2OTJNICAgNjYwTSAgMzEuNk0gICAgOTUlICAxLjAweCAgT05MSU5FICAtCkNsZWFy OgpOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgMTE2TSAg IDU0NE0gICAxMTVNICAvdGVzdApOQU1FICAgIFNJWkUgIEFMTE9DICAgRlJFRSAgICBDQVAg IERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0gICAxMTZNICAgNTc2TSAgICAx NiUgIDEuMDB4ICBPTkxJTkUgIC0KPT09PT09PT09PT09PQpSdW4gIzgKRnVsbDoKNjc1NDA5 ICAvdGVzdApOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAg NjYwTSAgICAgIDAgICA2NTlNICAvdGVzdApOQU1FICAgIFNJWkUgIEFMTE9DICAgRlJFRSAg ICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0gICA2NjBNICAzMS43 TSAgICA5NSUgIDEuMDB4ICBPTkxJTkUgIC0KQ2xlYXI6Ck5BTUUgICAgVVNFRCAgQVZBSUwg IFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgIDgyLjFNICAgNTc4TSAgODEuNU0gIC90ZXN0Ck5B TUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENBUCAgREVEVVAgIEhFQUxUSCAgQUxUUk9P VAp0ZXN0ICAgNjkyTSAgODIuM00gICA2MTBNICAgIDExJSAgMS4wMHggIE9OTElORSAgLQo9 PT09PT09PT09PT09CgoKUmVzdWx0cyBsb29rIHdlaXJkLCBidXQgaWYgSSBkbyBpdCBtYW51 YWxseSwgSSBjYW4gc2VlIHRoYXQgdGhlIHNwYWNlIGlzIGNsZWFyZWQgYSB3aGlsZSBhZnRl ciB0aGUgInJtIiBjb21tYW5kIGlzIGRvbmUuCgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3Rd IyB6ZnMgbGlzdCB0ZXN0Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5U CnRlc3QgICA2MjBNICA0MC40TSAgIDYxOU0gIC90ZXN0Cgpbcm9vdEBiY3pmc3ZtMXRlc3Qg L3Rlc3RdIyB6cG9vbCBsaXN0IHRlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAg Q0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2OTJNICAgNjIwTSAgNzIuMk0g ICAgODklICAxLjAweCAgT05MSU5FICAtCltyb290QGJjemZzdm0xdGVzdCAvdGVzdF0jIHJt IC1yZiAqCgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyB6ZnMgbGlzdCB0ZXN0Ck5BTUUg ICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA0NjRNICAgMTk2TSAg IDQ2NE0gIC90ZXN0Cgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyB6ZnMgbGlzdCB0ZXN0 Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA0NjRNICAg MTk2TSAgIDQ2NE0gIC90ZXN0Cgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyB6ZnMgbGlz dCB0ZXN0Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA2 NjRLICAgNjU5TSAgICAzMUsgIC90ZXN0Cgpbcm9vdEBiY3pmc3ZtMXRlc3QgL3Rlc3RdIyB6 ZnMgbGlzdCB0ZXN0Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRl c3QgICA2NjRLICAgNjU5TSAgICAzMUsgIC90ZXN0CgoKCnJ1biB3aXRoIHZlcnNpb24gMyAo YiBmcm9tIDEuLjUwMCwgYW5kIHNsZWVwIDMwIGFkZGVkKToKCgpSdW4gIzIgKHN0YXJ0cyBv biAyIGJlY2F1c2UgYWNjaWRlbnRseSAiYyIgd2FzIGluc2VydGVkIGJlZm9yZSAicnVuPTEi KQpGdWxsOgo2NzUzOTQgIC90ZXN0Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VO VFBPSU5UCnRlc3QgICA2NjBNICAgICAgMCAgIDY1OU0gIC90ZXN0Ck5BTUUgICAgU0laRSAg QUxMT0MgICBGUkVFICAgIENBUCAgREVEVVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjky TSAgIDY2ME0gIDMxLjhNICAgIDk1JSAgMS4wMHggIE9OTElORSAgLQpDbGVhcjoKTkFNRSAg ICBVU0VEICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDcwMksgICA2NTlNICAg IDMxSyAgL3Rlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAg SEVBTFRIICBBTFRST09UCnRlc3QgICA2OTJNICAgNzg4SyAgIDY5MU0gICAgIDAlICAxLjAw eCAgT05MSU5FICAtCj09PT09PT09PT09PT0KUnVuICMzCkZ1bGw6CjY3NTQwNSAgL3Rlc3QK TkFNRSAgICBVU0VEICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY2ME0gICAg ICAwICAgNjU5TSAgL3Rlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBE RURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2OTJNICAgNjYwTSAgMzEuOE0gICAgOTUl ICAxLjAweCAgT05MSU5FICAtCkNsZWFyOgpOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAg TU9VTlRQT0lOVAp0ZXN0ICAgNzEwSyAgIDY1OU0gICAgMzFLICAvdGVzdApOQU1FICAgIFNJ WkUgIEFMTE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAg IDY5Mk0gICA3OTZLICAgNjkxTSAgICAgMCUgIDEuMDB4ICBPTkxJTkUgIC0KPT09PT09PT09 PT09PQpSdW4gIzQKRnVsbDoKNjc1Mzk1ICAvdGVzdApOQU1FICAgIFVTRUQgIEFWQUlMICBS RUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgNjYwTSAgICAgIDAgICA2NTlNICAvdGVzdApOQU1F ICAgIFNJWkUgIEFMTE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QK dGVzdCAgIDY5Mk0gICA2NjBNICAzMS44TSAgICA5NSUgIDEuMDB4ICBPTkxJTkUgIC0KQ2xl YXI6Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA3MDhL ICAgNjU5TSAgICAzMUsgIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENB UCAgREVEVVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDc5M0sgICA2OTFNICAg ICAwJSAgMS4wMHggIE9OTElORSAgLQo9PT09PT09PT09PT09ClJ1biAjNQpGdWxsOgo2NzU0 MTAgIC90ZXN0Ck5BTUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3Qg ICA2NjBNICAgICAgMCAgIDY1OU0gIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVF ICAgIENBUCAgREVEVVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDY2ME0gIDMx LjhNICAgIDk1JSAgMS4wMHggIE9OTElORSAgLQpDbGVhcjoKTkFNRSAgICBVU0VEICBBVkFJ TCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY5NksgICA2NTlNICAgIDMxSyAgL3Rlc3QK TkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRS T09UCnRlc3QgICA2OTJNICAgNzk4SyAgIDY5MU0gICAgIDAlICAxLjAweCAgT05MSU5FICAt Cj09PT09PT09PT09PT0KUnVuICM2CkZ1bGw6CjY3NTI3NyAgL3Rlc3QKTkFNRSAgICBVU0VE ICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY2ME0gICAgICAwICAgNjU5TSAg L3Rlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRI ICBBTFRST09UCnRlc3QgICA2OTJNICAgNjYwTSAgMzEuOU0gICAgOTUlICAxLjAweCAgT05M SU5FICAtCkNsZWFyOgpOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0 ZXN0ICAgNjQ4SyAgIDY1OU0gICAgMzFLICAvdGVzdApOQU1FICAgIFNJWkUgIEFMTE9DICAg RlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0gICA3MTVL ICAgNjkxTSAgICAgMCUgIDEuMDB4ICBPTkxJTkUgIC0KPT09PT09PT09PT09PQpSdW4gIzcK RnVsbDoKNjc1MzkxICAvdGVzdApOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQ T0lOVAp0ZXN0ICAgNjYwTSAgICAgIDAgICA2NTlNICAvdGVzdApOQU1FICAgIFNJWkUgIEFM TE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0g ICA2NjBNICAzMS44TSAgICA5NSUgIDEuMDB4ICBPTkxJTkUgIC0KQ2xlYXI6Ck5BTUUgICAg VVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA3MDZLICAgNjU5TSAgICAz MUsgIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENBUCAgREVEVVAgIEhF QUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDc5NEsgICA2OTFNICAgICAwJSAgMS4wMHgg IE9OTElORSAgLQo9PT09PT09PT09PT09ClJ1biAjOApGdWxsOgo2NzUyNjcgIC90ZXN0Ck5B TUUgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UCnRlc3QgICA2NjBNICAgICAg MCAgIDY1OU0gIC90ZXN0Ck5BTUUgICAgU0laRSAgQUxMT0MgICBGUkVFICAgIENBUCAgREVE VVAgIEhFQUxUSCAgQUxUUk9PVAp0ZXN0ICAgNjkyTSAgIDY2ME0gIDMxLjlNICAgIDk1JSAg MS4wMHggIE9OTElORSAgLQpDbGVhcjoKTkFNRSAgICBVU0VEICBBVkFJTCAgUkVGRVIgIE1P VU5UUE9JTlQKdGVzdCAgIDcxNEsgICA2NTlNICAgIDMxSyAgL3Rlc3QKTkFNRSAgICBTSVpF ICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2 OTJNICAgNzk4SyAgIDY5MU0gICAgIDAlICAxLjAweCAgT05MSU5FICAtCj09PT09PT09PT09 PT0KUnVuICM5CkZ1bGw6CjY3NTM5MiAgL3Rlc3QKTkFNRSAgICBVU0VEICBBVkFJTCAgUkVG RVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY2ME0gICAgICAwICAgNjU5TSAgL3Rlc3QKTkFNRSAg ICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRl c3QgICA2OTJNICAgNjYwTSAgMzEuOE0gICAgOTUlICAxLjAweCAgT05MSU5FICAtCkNsZWFy OgpOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgNzAwSyAg IDY1OU0gICAgMzFLICAvdGVzdApOQU1FICAgIFNJWkUgIEFMTE9DICAgRlJFRSAgICBDQVAg IERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0gICA3ODZLICAgNjkxTSAgICAg MCUgIDEuMDB4ICBPTkxJTkUgIC0KPT09PT09PT09PT09PQpSdW4gIzEwCkZ1bGw6CjY3NTM5 NCAgL3Rlc3QKTkFNRSAgICBVU0VEICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAg IDY2ME0gICAgICAwICAgNjU5TSAgL3Rlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUg ICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2OTJNICAgNjYwTSAgMzEu OE0gICAgOTUlICAxLjAweCAgT05MSU5FICAtCkNsZWFyOgpOQU1FICAgIFVTRUQgIEFWQUlM ICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgNDIySyAgIDY2ME0gICAgMzFLICAvdGVzdApO QU1FICAgIFNJWkUgIEFMTE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJP T1QKdGVzdCAgIDY5Mk0gICA0NThLICAgNjkyTSAgICAgMCUgIDEuMDB4ICBPTkxJTkUgIC0K PT09PT09PT09PT09PQpSdW4gIzExCkZ1bGw6CjY3NTM5OCAgL3Rlc3QKTkFNRSAgICBVU0VE ICBBVkFJTCAgUkVGRVIgIE1PVU5UUE9JTlQKdGVzdCAgIDY2ME0gICAgICAwICAgNjU5TSAg L3Rlc3QKTkFNRSAgICBTSVpFICBBTExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRI ICBBTFRST09UCnRlc3QgICA2OTJNICAgNjYwTSAgMzEuOE0gICAgOTUlICAxLjAweCAgT05M SU5FICAtCkNsZWFyOgpOQU1FICAgIFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0 ZXN0ICAgNDA2SyAgIDY2ME0gICAgMzFLICAvdGVzdApOQU1FICAgIFNJWkUgIEFMTE9DICAg RlJFRSAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0gICA0NDJL ICAgNjkyTSAgICAgMCUgIDEuMDB4ICBPTkxJTkUgIC0KPT09PT09PT09PT09PQpSdW4gIzEy CkZ1bGw6CjY3NTQxOCAgL3Rlc3QKTkFNRSAgICBVU0VEICBBVkFJTCAgUkVGRVIgIE1PVU5U UE9JTlQKdGVzdCAgIDY2ME0gICAgICAwICAgNjU5TSAgL3Rlc3QKTkFNRSAgICBTSVpFICBB TExPQyAgIEZSRUUgICAgQ0FQICBERURVUCAgSEVBTFRIICBBTFRST09UCnRlc3QgICA2OTJN ICAgNjYwTSAgMzEuOE0gICAgOTUlICAxLjAweCAgT05MSU5FICAtCkNsZWFyOgpOQU1FICAg IFVTRUQgIEFWQUlMICBSRUZFUiAgTU9VTlRQT0lOVAp0ZXN0ICAgNDM2SyAgIDY2ME0gICAg MzFLICAvdGVzdApOQU1FICAgIFNJWkUgIEFMTE9DICAgRlJFRSAgICBDQVAgIERFRFVQICBI RUFMVEggIEFMVFJPT1QKdGVzdCAgIDY5Mk0gICA0NzJLICAgNjkyTSAgICAgMCUgIDEuMDB4 ICBPTkxJTkUgIC0KPT09PT09PT09PT09PQoKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09CkNvbmNsdXNpb24KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgpJdCBzZWVt cyB0aGF0IHRoZSBtYXhpbXVtIHNwYWNlIHZhcmllcyBieSBhIHNtYWxsIGFtb3VudCwgYW5k IHNvIGRvZXMgdGhlICJVU0VEIiBhbmQgIkFMTE9DIiB3aGVuIGNsZWFyaW5nIHRoZSBwb29s LCBidXQgdGhlIGZyZWUgc3BhY2UgaXMgbm90IGNsZWFybHkgZ29pbmcgZG93biB3aXRoIGVh Y2ggaXRlcmF0aW9uIG9mIHJlbW92aW5nIGFuZCBmaWxsaW5nLgoKSWYgYW55dGhpbmcgaXMg bWlzc2luZyBpdCBpcyBwcm9iYWJseSBsZXNzIHRoYW4gYSBraWxvYnl0ZSBhZnRlciBmaWxs aW5nIGFuZCByZW1vdmluZyBhbGwgMTEgdGltZXMuIChub3RlIHRoYXQgcG9vbCB3YXMgbmV2 ZXIgZGVzdHJveWVkLCBhbmQgbG90cyBvZiB0ZXN0IHJ1bnMgdG9vayBwbGFjZSB0aGF0IGFy ZSBub3QgcmVjb3JkZWQgaGVyZSwgc28gdGhlcmUgYXJlIG1hbnkgbW9yZSB0aGFuIDExIHJ1 bnMsIHByb2JhYmx5IDQwLTUwKQoKQSByZXBlYXQgdGVzdCBvbiBhIGxhcmdlciBkaXNrLCBv ciB3aXRoIEZyZWVCU0QgOS4wIG1heSBiZSBhcHByb3ByaWF0ZS4= --------------020307070107060600020708-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 01:18:07 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D27D21065686; Wed, 4 Apr 2012 01:18:07 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A3DC58FC15; Wed, 4 Apr 2012 01:18:07 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q341I5q0000619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 18:18:06 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F7BA173.6050903@freebsd.org> Date: Tue, 03 Apr 2012 18:18:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: fs@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: "trim/discard" success story 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: Wed, 04 Apr 2012 01:18:07 -0000 Today I had reason to try the UFS "trim" support on the FreeBSD version of the Fusion-IO driver, and I'm pleased to say that it appears to work just fine.. on a 1.3TB flash card.. the numbers of 'sectors' that the drive considers to hold valid data is reduced after the contents of the drive is erased..: After newfs -E: hw.fusion.fio.fio0.data.stats: [...] 861327 [...] After writing a few GB to the filesystem but BEFORE"rm -r *" pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 3628354 [...] After"rm -r *" pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 919690 [...] so from 861,327 packets valid to 3,628,354 packets valid, back to 919,690 packets valid. (since bitmaps etc are allocated as needed the growth is expected but will not grow forever). (yeah I know it never actually reached 1% full but it was a test, ok?) for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 01:50:39 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B25E8106566B; Wed, 4 Apr 2012 01:50:39 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 75BEB8FC15; Wed, 4 Apr 2012 01:50:39 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id q341oX6V022632; Tue, 3 Apr 2012 20:50:33 -0500 (CDT) Date: Tue, 3 Apr 2012 20:50:33 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Julian Elischer In-Reply-To: <4F7BA173.6050903@freebsd.org> Message-ID: References: <4F7BA173.6050903@freebsd.org> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Tue, 03 Apr 2012 20:50:33 -0500 (CDT) Cc: FreeBSD Current , fs@freebsd.org Subject: Re: "trim/discard" success story 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: Wed, 04 Apr 2012 01:50:39 -0000 On Tue, 3 Apr 2012, Julian Elischer wrote: > > for flash drives this is great news.. > Now if ZFS would get trim support, that too would be great. The major unknown issue with trim is how well the drives schedules/defers the trim operation so that it does not interfer with other I/Os. Also, it would be really bad if the drive applied trim after the block had been re-allocated for a write. It would also be really bad if the drive loses unrelated data if there is a power fail during trim. If writes get blocked by a pending trim, then trim would not help very much. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 05:18:37 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C97106567B; Wed, 4 Apr 2012 05:18:37 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2FC528FC16; Wed, 4 Apr 2012 05:18:37 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q345IY6l001342 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 22:18:35 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F7BD9D1.80504@freebsd.org> Date: Tue, 03 Apr 2012 22:19:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Bob Friesenhahn References: <4F7BA173.6050903@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , fs@freebsd.org Subject: Re: "trim/discard" success story 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: Wed, 04 Apr 2012 05:18:37 -0000 On 4/3/12 6:50 PM, Bob Friesenhahn wrote: > On Tue, 3 Apr 2012, Julian Elischer wrote: >> >> for flash drives this is great news.. >> Now if ZFS would get trim support, that too would be great. > > The major unknown issue with trim is how well the drives > schedules/defers the trim operation so that it does not interfer > with other I/Os. Also, it would be really bad if the drive applied > trim after the block had been re-allocated for a write. It would > also be really bad if the drive loses unrelated data if there is a > power fail during trim. > > If writes get blocked by a pending trim, then trim would not help > very much. well since I work for the "drive manufacturer" I can say that in this case it really is worth it. :-) But I'm glad that it is getting out there that trim aint as easy as it seems. The hard part about trim is making it so that if you get a power failure, the trimmed data says trimmed. In some cases, it is not important. For example when a filesystem is used, trimmed data will never be accessed again without first writing new data to that address. but for any application that assumes that trimmed data will return zero's it is a critical feature. > > Bob From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 07:53:05 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 8AE82106564A for ; Wed, 4 Apr 2012 07:53:05 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 142078FC0A for ; Wed, 4 Apr 2012 07:53:04 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 54AAECA40B3; Wed, 4 Apr 2012 09:52:57 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 12.6474] X-CRM114-CacheID: sfid-20120404_09525_9F1F6089 X-CRM114-Status: Good ( pR: 12.6474 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 4 09:52:57 2012 X-DSPAM-Confidence: 0.7621 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4f7bfdd971781311117049 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, FreeBSD, 0.00048, FreeBSD, 0.00048, To*FreeBSD.org, 0.00065, I+get, 0.00551, Received*FreeBSD.org>, 0.00632, documented, 0.00710, python, 0.00811, 14+23, 0.00811, User-Agent*i686, 0.00896, file+or, 0.00945, use+a, 0.00945, User-Agent*Linux+i686, 0.01000, Received*4+Apr, 0.99000, Date*04+Apr, 0.99000, errno, 0.01000, errno, 0.01000, such+file, 0.01000, bit+the, 0.01000, a+version, 0.01000, No+such, 0.01000, is+6, 0.01000, is+6, 0.01000, or+directory, 0.01000, the+C, 0.01132, doesn't+work, 0.01132, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 15C58CA40A7 for ; Wed, 4 Apr 2012 09:52:56 +0200 (CEST) Message-ID: <4F7BFDD4.6080703@fsn.hu> Date: Wed, 04 Apr 2012 09:52:52 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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: Wed, 04 Apr 2012 07:53:05 -0000 Hi, I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that works on Solaris doesn't work on FreeBSD. Python itself couldn't cause this, because it correctly issues the lseek, but taking the C test program from here: https://lkml.org/lkml/2011/4/22/79 gives the same result (failure). On a Solaris 10 box I get (the correct result): creating file Error 0 fpathconf gives 512, ENXIO is 6 testing at start CUR at offset 0, errno 0 HOLE gives offset 131072, errno 0 CUR at offset 131072, errno 0 DATA gives offset 0, errno 0 CUR at offset 0, errno 0 HOLE gives offset 131072, errno 0 CUR at offset 131072, errno 0 testing at end end at offset 1048578, errno 0 HOLE gives offset -1, errno 6 CUR at offset 1048578, errno 0 DATA gives offset -1, errno 6 CUR at offset 1048578, errno 0 HOLE gives offset 1048578, errno 0 CUR at offset 1048578, errno 0 DATA gives offset 1048577, errno 0 CUR at offset 1048577, errno 0 testing at offset 1 HOLE gives offset 131072, errno 0 CUR at offset 131072, errno 0 DATA gives offset 1, errno 0 CUR at offset 1, errno 0 testing at offset 200000 HOLE gives offset 200000, errno 0 CUR at offset 200000, errno 0 DATA gives offset 1048576, errno 0 CUR at offset 1048576, errno 0 On FreeBSD 9-STABLE/amd64 (all HOLE or DATA seeks fail): creating file No error: 0 fpathconf gives 512, ENXIO is 6 testing at start CUR at offset 0, errno 0 HOLE gives offset -1, errno 6 CUR at offset 0, errno 0 DATA gives offset -1, errno 6 CUR at offset 0, errno 0 HOLE gives offset -1, errno 6 CUR at offset 0, errno 0 testing at end end at offset 1048578, errno 0 HOLE gives offset -1, errno 6 CUR at offset 1048578, errno 0 DATA gives offset -1, errno 6 CUR at offset 1048578, errno 0 HOLE gives offset -1, errno 6 CUR at offset 1048578, errno 0 DATA gives offset -1, errno 6 CUR at offset 1048578, errno 0 testing at offset 1 HOLE gives offset -1, errno 6 CUR at offset 1048578, errno 0 DATA gives offset -1, errno 6 CUR at offset 1048578, errno 0 testing at offset 200000 HOLE gives offset -1, errno 6 CUR at offset 1048578, errno 0 DATA gives offset -1, errno 6 CUR at offset 1048578, errno 0 Interestingly on an older 8.2-PRELEASE (Dec 14 23:12:05 CET 2010 and i386) box it works: creating file No such file or directory fpathconf gives 512, ENXIO is 6 testing at start CUR at offset 0, errno 0 HOLE gives offset 131072, errno 0 CUR at offset 131072, errno 0 DATA gives offset 0, errno 0 CUR at offset 0, errno 0 HOLE gives offset 131072, errno 0 CUR at offset 131072, errno 0 testing at end end at offset 1048578, errno 0 HOLE gives offset -1, errno 6 CUR at offset 1048578, errno 0 DATA gives offset -1, errno 6 CUR at offset 1048578, errno 0 HOLE gives offset 1048578, errno 0 CUR at offset 1048578, errno 0 DATA gives offset 1048577, errno 0 CUR at offset 1048577, errno 0 testing at offset 1 HOLE gives offset 131072, errno 0 CUR at offset 131072, errno 0 DATA gives offset 1, errno 0 CUR at offset 1, errno 0 testing at offset 200000 HOLE gives offset 200000, errno 0 CUR at offset 200000, errno 0 DATA gives offset 1048576, errno 0 CUR at offset 1048576, errno 0 I don't know whether 32 bit, the OS or the pool version (the only working FreeBSD case use a version 13 zpool) cause the malfunction, but this is a major issue for anybody who wants to use this documented feature. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 08:38:50 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 1F642106564A for ; Wed, 4 Apr 2012 08:38:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCC88FC0C for ; Wed, 4 Apr 2012 08:38:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA22514; Wed, 04 Apr 2012 11:38:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SFLjk-000Mvh-4c; Wed, 04 Apr 2012 11:38:40 +0300 Message-ID: <4F7C088D.4070803@FreeBSD.org> Date: Wed, 04 Apr 2012 11:38:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Attila Nagy References: <4F7BFDD4.6080703@fsn.hu> In-Reply-To: <4F7BFDD4.6080703@fsn.hu> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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: Wed, 04 Apr 2012 08:38:50 -0000 on 04/04/2012 10:52 Attila Nagy said the following: > Hi, > > I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent > FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that > works on Solaris doesn't work on FreeBSD. > Python itself couldn't cause this, because it correctly issues the lseek, but > taking the C test program from here: > https://lkml.org/lkml/2011/4/22/79 > gives the same result (failure). Please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164445 If you can't figure out a patch from its contents, then I'll try to provide it some time later today. > On a Solaris 10 box I get (the correct result): > creating file > Error 0 > fpathconf gives 512, ENXIO is 6 > > testing at start > CUR at offset 0, errno 0 > HOLE gives offset 131072, errno 0 > CUR at offset 131072, errno 0 > DATA gives offset 0, errno 0 > CUR at offset 0, errno 0 > HOLE gives offset 131072, errno 0 > CUR at offset 131072, errno 0 > > testing at end > end at offset 1048578, errno 0 > HOLE gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > DATA gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > HOLE gives offset 1048578, errno 0 > CUR at offset 1048578, errno 0 > DATA gives offset 1048577, errno 0 > CUR at offset 1048577, errno 0 > > testing at offset 1 > HOLE gives offset 131072, errno 0 > CUR at offset 131072, errno 0 > DATA gives offset 1, errno 0 > CUR at offset 1, errno 0 > > testing at offset 200000 > HOLE gives offset 200000, errno 0 > CUR at offset 200000, errno 0 > DATA gives offset 1048576, errno 0 > CUR at offset 1048576, errno 0 > > On FreeBSD 9-STABLE/amd64 (all HOLE or DATA seeks fail): > creating file > No error: 0 > fpathconf gives 512, ENXIO is 6 > > testing at start > CUR at offset 0, errno 0 > HOLE gives offset -1, errno 6 > CUR at offset 0, errno 0 > DATA gives offset -1, errno 6 > CUR at offset 0, errno 0 > HOLE gives offset -1, errno 6 > CUR at offset 0, errno 0 > > testing at end > end at offset 1048578, errno 0 > HOLE gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > DATA gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > HOLE gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > DATA gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > > testing at offset 1 > HOLE gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > DATA gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > > testing at offset 200000 > HOLE gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > DATA gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > > Interestingly on an older 8.2-PRELEASE (Dec 14 23:12:05 CET 2010 and i386) box > it works: > creating file > No such file or directory > fpathconf gives 512, ENXIO is 6 > > testing at start > CUR at offset 0, errno 0 > HOLE gives offset 131072, errno 0 > CUR at offset 131072, errno 0 > DATA gives offset 0, errno 0 > CUR at offset 0, errno 0 > HOLE gives offset 131072, errno 0 > CUR at offset 131072, errno 0 > > testing at end > end at offset 1048578, errno 0 > HOLE gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > DATA gives offset -1, errno 6 > CUR at offset 1048578, errno 0 > HOLE gives offset 1048578, errno 0 > CUR at offset 1048578, errno 0 > DATA gives offset 1048577, errno 0 > CUR at offset 1048577, errno 0 > > testing at offset 1 > HOLE gives offset 131072, errno 0 > CUR at offset 131072, errno 0 > DATA gives offset 1, errno 0 > CUR at offset 1, errno 0 > > testing at offset 200000 > HOLE gives offset 200000, errno 0 > CUR at offset 200000, errno 0 > DATA gives offset 1048576, errno 0 > CUR at offset 1048576, errno 0 > > I don't know whether 32 bit, the OS or the pool version (the only working > FreeBSD case use a version 13 zpool) cause the malfunction, but this is a major > issue for anybody who wants to use this documented feature. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 08:50:11 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 950541065670; Wed, 4 Apr 2012 08:50:11 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 19DCE8FC0C; Wed, 4 Apr 2012 08:50:10 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 02A81CA44EA; Wed, 4 Apr 2012 10:50:09 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 13.7105] X-CRM114-CacheID: sfid-20120404_10500_DCC94B49 X-CRM114-Status: Good ( pR: 13.7105 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 4 10:50:09 2012 X-DSPAM-Confidence: 0.7629 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4f7c0b41346402043610175 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, FreeBSD, 0.00048, FreeBSD, 0.00048, wrote+>, 0.00179, it+>, 0.00220, >+I, 0.00228, Url*pr, 0.00438, Url*org/cgi/query, 0.00438, >>+>>, 0.00450, >+If, 0.00475, the+patch, 0.00475, wrote, 0.00508, References*fsn.hu>, 0.00518, 10+38, 0.00710, >>+Hi, 0.00710, a+patch, 0.00710, python, 0.00811, >+on, 0.00811, User-Agent*i686, 0.00896, above+the, 0.00945, 10+52, 0.00945, User-Agent*Linux+i686, 0.01000, Received*4+Apr, 0.99000, Date*04+Apr, 0.99000, that+>>, 0.01000, Hi+>>, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 81686CA44DE; Wed, 4 Apr 2012 10:50:09 +0200 (CEST) Message-ID: <4F7C0B41.20702@fsn.hu> Date: Wed, 04 Apr 2012 10:50:09 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Andriy Gapon References: <4F7BFDD4.6080703@fsn.hu> <4F7C088D.4070803@FreeBSD.org> In-Reply-To: <4F7C088D.4070803@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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: Wed, 04 Apr 2012 08:50:11 -0000 On 04/04/12 10:38, Andriy Gapon wrote: > on 04/04/2012 10:52 Attila Nagy said the following: >> Hi, >> >> I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent >> FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that >> works on Solaris doesn't work on FreeBSD. >> Python itself couldn't cause this, because it correctly issues the lseek, but >> taking the C test program from here: >> https://lkml.org/lkml/2011/4/22/79 >> gives the same result (failure). > Please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164445 > If you can't figure out a patch from its contents, then I'll try to provide it > some time later today. > I will try it, but the e-mail above the patch is somewhat scary... From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 08:57:12 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 8F7CA106566B for ; Wed, 4 Apr 2012 08:57:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DA3678FC12 for ; Wed, 4 Apr 2012 08:57:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA22799; Wed, 04 Apr 2012 11:57:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SFM1d-000Mxk-F4; Wed, 04 Apr 2012 11:57:09 +0300 Message-ID: <4F7C0CE4.2030408@FreeBSD.org> Date: Wed, 04 Apr 2012 11:57:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Attila Nagy References: <4F7BFDD4.6080703@fsn.hu> <4F7C088D.4070803@FreeBSD.org> <4F7C0B41.20702@fsn.hu> In-Reply-To: <4F7C0B41.20702@fsn.hu> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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: Wed, 04 Apr 2012 08:57:12 -0000 on 04/04/2012 11:50 Attila Nagy said the following: > On 04/04/12 10:38, Andriy Gapon wrote: >> on 04/04/2012 10:52 Attila Nagy said the following: >>> Hi, >>> >>> I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent >>> FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that >>> works on Solaris doesn't work on FreeBSD. >>> Python itself couldn't cause this, because it correctly issues the lseek, but >>> taking the C test program from here: >>> https://lkml.org/lkml/2011/4/22/79 >>> gives the same result (failure). >> Please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164445 >> If you can't figure out a patch from its contents, then I'll try to provide it >> some time later today. >> > I will try it, but the e-mail above the patch is somewhat scary... Sorry, I could not understand what you mean. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 09:21:34 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C2CE106566C; Wed, 4 Apr 2012 09:21:34 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id F25948FC08; Wed, 4 Apr 2012 09:21:33 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 9C5B7CA4692; Wed, 4 Apr 2012 11:21:32 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 15.8594] X-CRM114-CacheID: sfid-20120404_11213_4C4F3E40 X-CRM114-Status: Good ( pR: 15.8594 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 4 11:21:32 2012 X-DSPAM-Confidence: 0.9940 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4f7c129c495062056410288 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, FreeBSD, 0.00048, FreeBSD, 0.00048, wrote+>, 0.00179, Url*pr, 0.00438, Url*org/cgi/query, 0.00438, the+patch, 0.00475, wrote, 0.00508, wrote, 0.00508, >>+On, 0.00518, References*fsn.hu>, 0.00518, References*fsn.hu>, 0.00518, >>+I, 0.00518, wrote+>>>, 0.00632, you+mean, 0.00632, 10+38, 0.00710, a+patch, 0.00710, Sorry, 0.00767, python, 0.00811, >+on, 0.00811, User-Agent*i686, 0.00896, above+the, 0.00945, 10+52, 0.00945, ZFS, 0.00945, >>>+>>, 0.00945, 11+50, 0.00945, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 07207CA4686; Wed, 4 Apr 2012 11:21:32 +0200 (CEST) Message-ID: <4F7C129B.9010206@fsn.hu> Date: Wed, 04 Apr 2012 11:21:31 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Andriy Gapon References: <4F7BFDD4.6080703@fsn.hu> <4F7C088D.4070803@FreeBSD.org> <4F7C0B41.20702@fsn.hu> <4F7C0CE4.2030408@FreeBSD.org> In-Reply-To: <4F7C0CE4.2030408@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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: Wed, 04 Apr 2012 09:21:34 -0000 On 04/04/12 10:57, Andriy Gapon wrote: > on 04/04/2012 11:50 Attila Nagy said the following: >> On 04/04/12 10:38, Andriy Gapon wrote: >>> on 04/04/2012 10:52 Attila Nagy said the following: >>>> Hi, >>>> >>>> I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent >>>> FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that >>>> works on Solaris doesn't work on FreeBSD. >>>> Python itself couldn't cause this, because it correctly issues the lseek, but >>>> taking the C test program from here: >>>> https://lkml.org/lkml/2011/4/22/79 >>>> gives the same result (failure). >>> Please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164445 >>> If you can't figure out a patch from its contents, then I'll try to provide it >>> some time later today. >>> >> I will try it, but the e-mail above the patch is somewhat scary... > Sorry, I could not understand what you mean. > "The patch does the copy of the offset passed from the application correctly, and allows lseek(2) with SEEK_DATA/SEEK_HOLE to be used on ZFS, but it is not a solution. I couldn't see a problem in the assembler of the copyin and copyout functions in sys/amd64/amd64/support.S, but I might be wrong, I'm no assembler expert." This is scary. :) From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 09:30:31 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 5E5E51065675 for ; Wed, 4 Apr 2012 09:30:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A4A5B8FC18 for ; Wed, 4 Apr 2012 09:30:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA23295; Wed, 04 Apr 2012 12:30:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SFMXs-000Mzk-9B; Wed, 04 Apr 2012 12:30:28 +0300 Message-ID: <4F7C14B3.3040705@FreeBSD.org> Date: Wed, 04 Apr 2012 12:30:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Attila Nagy References: <4F7BFDD4.6080703@fsn.hu> <4F7C088D.4070803@FreeBSD.org> <4F7C0B41.20702@fsn.hu> <4F7C0CE4.2030408@FreeBSD.org> <4F7C129B.9010206@fsn.hu> In-Reply-To: <4F7C129B.9010206@fsn.hu> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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: Wed, 04 Apr 2012 09:30:31 -0000 on 04/04/2012 12:21 Attila Nagy said the following: > On 04/04/12 10:57, Andriy Gapon wrote: >> on 04/04/2012 11:50 Attila Nagy said the following: >>> On 04/04/12 10:38, Andriy Gapon wrote: >>>> on 04/04/2012 10:52 Attila Nagy said the following: >>>>> Hi, >>>>> >>>>> I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent >>>>> FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that >>>>> works on Solaris doesn't work on FreeBSD. >>>>> Python itself couldn't cause this, because it correctly issues the lseek, but >>>>> taking the C test program from here: >>>>> https://lkml.org/lkml/2011/4/22/79 >>>>> gives the same result (failure). >>>> Please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164445 >>>> If you can't figure out a patch from its contents, then I'll try to provide it >>>> some time later today. >>>> >>> I will try it, but the e-mail above the patch is somewhat scary... >> Sorry, I could not understand what you mean. >> > "The patch does the copy of the offset passed from the application > correctly, and allows lseek(2) with SEEK_DATA/SEEK_HOLE to be used on > ZFS, but it is not a solution. I couldn't see a problem in the > assembler of the copyin and copyout functions in > sys/amd64/amd64/support.S, but I might be wrong, I'm no assembler > expert." > > This is scary. :) Did you see my comment in the PR trail? It explains why that approach is not scary but entirely correct. Due to some mailing issues it is re-ordered with the patch. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 12:42:04 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99A741065672; Wed, 4 Apr 2012 12:42:04 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1B58FC0C; Wed, 4 Apr 2012 12:42:03 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 1405FCA5879; Wed, 4 Apr 2012 14:42:03 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 18.6707] X-CRM114-CacheID: sfid-20120404_14420_9458915E X-CRM114-Status: Good ( pR: 18.6707 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 4 14:42:03 2012 X-DSPAM-Confidence: 0.9949 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4f7c419b451723344715381 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, FreeBSD, 0.00048, FreeBSD, 0.00048, wrote+>, 0.00179, )+>, 0.00248, not+>, 0.00356, Url*pr, 0.00438, Url*org/cgi/query, 0.00438, >>+>>, 0.00450, the+patch, 0.00475, the+patch, 0.00475, wrote, 0.00508, wrote, 0.00508, >>+On, 0.00518, References*fsn.hu>, 0.00518, References*fsn.hu>, 0.00518, this?, 0.00569, wrote+>>>, 0.00632, you+mean, 0.00632, 10+38, 0.00710, a+patch, 0.00710, Sorry, 0.00767, python, 0.00811, >+on, 0.00811, User-Agent*i686, 0.00896, above+the, 0.00945, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 9ADEBCA5869; Wed, 4 Apr 2012 14:42:02 +0200 (CEST) Message-ID: <4F7C419A.4050607@fsn.hu> Date: Wed, 04 Apr 2012 14:42:02 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Andriy Gapon References: <4F7BFDD4.6080703@fsn.hu> <4F7C088D.4070803@FreeBSD.org> <4F7C0B41.20702@fsn.hu> <4F7C0CE4.2030408@FreeBSD.org> <4F7C129B.9010206@fsn.hu> <4F7C14B3.3040705@FreeBSD.org> In-Reply-To: <4F7C14B3.3040705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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: Wed, 04 Apr 2012 12:42:04 -0000 On 04/04/12 11:30, Andriy Gapon wrote: > on 04/04/2012 12:21 Attila Nagy said the following: >> On 04/04/12 10:57, Andriy Gapon wrote: >>> on 04/04/2012 11:50 Attila Nagy said the following: >>>> On 04/04/12 10:38, Andriy Gapon wrote: >>>>> on 04/04/2012 10:52 Attila Nagy said the following: >>>>>> Hi, >>>>>> >>>>>> I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent >>>>>> FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that >>>>>> works on Solaris doesn't work on FreeBSD. >>>>>> Python itself couldn't cause this, because it correctly issues the lseek, but >>>>>> taking the C test program from here: >>>>>> https://lkml.org/lkml/2011/4/22/79 >>>>>> gives the same result (failure). >>>>> Please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164445 >>>>> If you can't figure out a patch from its contents, then I'll try to provide it >>>>> some time later today. >>>>> >>>> I will try it, but the e-mail above the patch is somewhat scary... >>> Sorry, I could not understand what you mean. >>> >> "The patch does the copy of the offset passed from the application >> correctly, and allows lseek(2) with SEEK_DATA/SEEK_HOLE to be used on >> ZFS, but it is not a solution. I couldn't see a problem in the >> assembler of the copyin and copyout functions in >> sys/amd64/amd64/support.S, but I might be wrong, I'm no assembler >> expert." >> >> This is scary. :) > Did you see my comment in the PR trail? It explains why that approach is not > scary but entirely correct. > Due to some mailing issues it is re-ordered with the patch. > No, thanks for the clarification. I've tried that patch and the C test program runs fine. Will you commit this? And I think a regression test case would also be good. :) Thanks, From owner-freebsd-fs@FreeBSD.ORG Wed Apr 4 13:31:09 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B8D31065675 for ; Wed, 4 Apr 2012 13:31:09 +0000 (UTC) (envelope-from peter@pean.org) Received: from velox.its.uu.se (velox.its.uu.se [130.238.7.74]) by mx1.freebsd.org (Postfix) with ESMTP id BBEF18FC18 for ; Wed, 4 Apr 2012 13:31:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at uu.se Received: from nyx.uppmax.uu.se (nyx.uppmax.uu.se [130.238.137.40]) by velox.its.uu.se (Postfix) with ESMTP id 65A47355B5 for ; Wed, 4 Apr 2012 15:23:18 +0200 (CEST) Message-ID: <4F7C4B46.7030305@pean.org> Date: Wed, 04 Apr 2012 15:23:18 +0200 From: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Swap on ZFS / swap_pager: indefinite wait buffer 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: Wed, 04 Apr 2012 13:31:09 -0000 On 04/02/2012 08:13 PM, bsalinux@gmail.com wrote: > Hi, > > I have been running FreeBSD 9.0-RELEASE from a USB stick running ZFS. > I have created swap file on zfs volume using the md driver. > > Swapinfo shows > > Device 1K-blocks Used Avail Capacity > /dev/md0 4194304 0 4194304 0% > > > The system has hung twice and all I can find in the log is > > Mar 22 03:17:30 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 927, size: 4096 > Mar 23 09:00:26 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 55, size: 4096 > Mar 23 22:01:26 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 49, size: 4096 > Mar 24 04:00:38 server kernel: swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 60, size: 4096 > > As the swap is on zfs, I assume it is not failing. > > Do I need to move swap off of ZFS? > > Thanks > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > I had alot of this when I had swap on zfs. Everything went away when I moved the swap off zfs. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 5 03:52:30 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52A27106566C for ; Thu, 5 Apr 2012 03:52:30 +0000 (UTC) (envelope-from j.freebsd-zfs@enone.net) Received: from flabnapple.net (flabnapple.net [216.129.104.99]) by mx1.freebsd.org (Postfix) with ESMTP id 387988FC0A for ; Thu, 5 Apr 2012 03:52:30 +0000 (UTC) Received: from [10.0.1.6] (c-98-207-6-192.hsd1.ca.comcast.net [98.207.6.192]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by flabnapple.net (Postfix) with ESMTPSA id 6226D1CC079; Wed, 4 Apr 2012 20:42:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Taylor In-Reply-To: <20120402133721.Horde.KOqoS5jmRSRPeY9xDWLhHWA@webmail.leidinger.net> Date: Wed, 4 Apr 2012 20:42:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88EC48E8-6E77-417B-9CC1-1812617A57D1@enone.net> References: <45654FDD-A20A-47C8-B3B5-F9B0B71CC38B@enone.net> <20120324174218.00005f63@unknown> <20120402133721.Horde.KOqoS5jmRSRPeY9xDWLhHWA@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS extra space overhead for ashift=12 vs ashift=9 raidz2 pool? 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, 05 Apr 2012 03:52:30 -0000 Alex, I think you are correct. It occurred to me some time after reading your = original email that the sector size problem could also be applied to the metadata for the filesystem as well as the = data. As I previously stated, the overhead of the filesystem goes from 2.59% to 8.06% when increasing sector size = from 512B to 4KiB , which is an increase of 3.11x, well in line with your 8x observation. Likewise this thread also seems = to confirm that lots of the metadata takes up < 512B and there is no real attempts to optimize this for 4K sector = size: = http://mail.opensolaris.org/pipermail/zfs-discuss/2011-October/049959.html= I ended up using 512B sector size for the array since I valued the extra = space more than the extra bandwidth. :)=20 Thanks again for your response, -Taylor On Apr 2, 2012, at 4:37 AM, Alexander Leidinger wrote: > Quoting Taylor (from Sat, 24 Mar 2012 = 11:41:20 -0700): >=20 >> Alex, >>=20 >> Thank you for your response. I'm not particularly concerned about the = overhead of file fragmentation, >> as most of the space will be take by fairly large files (10's of = GiB). >>=20 >> My original question concerned the amount of space reported available = by zfs for a >> freshly-created *empty* raidz2 filesystem. >>=20 >> To re-iterate, I find 2.79TiB more space available with ashift=3D9 = (49.62 TiB) vs ashift=3D12 (46.83TiB) >> for a new 3.64TiB 16-disk raidz2 pool. >=20 > I do not know for the actual amount, but at least some overhead is not = surprising to me. >=20 > You have some meta data in ZFS (file permissions, ACLs, checksums, = ...). This meta data should be more often much less than 4k in size, but = you need to allocate at least one block for this meta data. If we assume = (worst case) that most of the time the meta data would fit into 512 byte = but you always use a 4k sector, it should be clear that you use 8 times = more space on the disk for each meta data unit, than necessary. >=20 > Bye, > Alexander. >=20 > --=20 > Let me put it this way: today is going to be a learning experience. >=20 > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D = 72077137 >=20 From owner-freebsd-fs@FreeBSD.ORG Thu Apr 5 08:02:52 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 350C6106566B for ; Thu, 5 Apr 2012 08:02:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF378FC15 for ; Thu, 5 Apr 2012 08:02:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA08643; Thu, 05 Apr 2012 11:02:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SFheb-0000LJ-6N; Thu, 05 Apr 2012 11:02:49 +0300 Message-ID: <4F7D51A7.9080405@FreeBSD.org> Date: Thu, 05 Apr 2012 11:02:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Attila Nagy References: <4F7BFDD4.6080703@fsn.hu> <4F7C088D.4070803@FreeBSD.org> <4F7C0B41.20702@fsn.hu> <4F7C0CE4.2030408@FreeBSD.org> <4F7C129B.9010206@fsn.hu> <4F7C14B3.3040705@FreeBSD.org> <4F7C419A.4050607@fsn.hu> In-Reply-To: <4F7C419A.4050607@fsn.hu> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case) 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, 05 Apr 2012 08:02:52 -0000 on 04/04/2012 15:42 Attila Nagy said the following: > No, thanks for the clarification. I've tried that patch and the C test program > runs fine. > Will you commit this? Thank you for testing! I've just committed the patch. > And I think a regression test case would also be good. :) I agree. Could you submit it? :) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 5 08:20:08 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F4E7106564A for ; Thu, 5 Apr 2012 08:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 22A568FC14 for ; Thu, 5 Apr 2012 08:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q358K7Fc096519 for ; Thu, 5 Apr 2012 08:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q358K7bS096514; Thu, 5 Apr 2012 08:20:07 GMT (envelope-from gnats) Date: Thu, 5 Apr 2012 08:20:07 GMT Message-Id: <201204050820.q358K7bS096514@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/166566: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:20:08 -0000 The following reply was made to PR kern/166566; it has been noted by GNATS. From: Andriy Gapon To: hartzell@alerce.com Cc: bug-followup@FreeBSD.org Subject: Re: kern/166566: [zfs] zfs split renders 2 disk (MBR based) mirror unbootable Date: Thu, 05 Apr 2012 11:10:32 +0300 on 02/04/2012 18:47 George Hartzell said the following: > > Thanks for following up on this. > > Andriy Gapon writes: > > > > A few things missing from your port: > > > > 1. "Doesn't boot" is quite a poor description in comparison with > > other details that you provided. You should give more detailed > > information of the boot failure. > > As the kernel is loading it fails to mount the root partition and > presents one with the minimal mountroot dialog. Attempting to boot > from zfs:zroot or zfs:zsplitroot fails. I remember that a question > mark lists various other devices but don't remember the particulars. Thank you for additional detailed information. Could you please set vfs.zfs.debug=1 in your loader.conf and reproduce the problem and then report messages that appear just before and during mount attempt? Pictures of your screen would do just fine if you are unable to capture the messages as text. If you are unsure what to report please report more rather than less. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Apr 6 10:01:47 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E17EC106564A; Fri, 6 Apr 2012 10:01:47 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by mx1.freebsd.org (Postfix) with ESMTP id C6AD08FC1C; Fri, 6 Apr 2012 10:01:46 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKT36/CRKAmz+3PM+PosHmsjEzR9zVa8lL@postini.com; Fri, 06 Apr 2012 03:01:47 PDT Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 6 Apr 2012 06:06:57 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 6 Apr 2012 06:01:43 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Fri, 6 Apr 2012 15:31:41 +0530 From: "Desai, Kashyap" To: "freebsd-scsi@freebsd.org" , "freebsd-fs@freebsd.org" Date: Fri, 6 Apr 2012 15:31:39 +0530 Thread-Topic: Kernel crash at "softdep_deallocate_dependencies" Thread-Index: Ac0T3EKQWAnorhNWQtCpeQSByo4SAg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Kenneth D.Merry" , "McConnell, Stephen" Subject: Kernel crash at "softdep_deallocate_dependencies" 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: Fri, 06 Apr 2012 10:01:48 -0000 Hi, Thanks in advance for looking this query and hoping for some help from = File system experts. We have a RAID 0 volume which has partition (created using sysinstall fdisk= option). While IOs are in progress removing one of the volume member kernel panic is= hit with the following messages g_vfs_done():(da0:da0s1d[WRITE(offset=3D6358872064, length=3D2048)]mpslsi0:= 0:error =3D 6 0:/home: got error 6 while accessing filesystem 0): panic: softdep_deallocate_dependencies: unrecovered I/O error lost device Note: 1. The issue is also seen on a RAID 0 volume which does not have a partitio= n on it. 2. Issue was observed on both SAS and SATA drives. 3. When we send IOs to the driver without FS (using "dd" command), kernel p= anic never seen. I have searched on this topic and looks like something wrong with FS. _but_= I don't have any trigger to support that this is not Driver issue. When we tried below options: (disable Journal on FS) Things does not change= . We still see kernel panic. umount tunefs -j disable mount cd rm .sujournal Any thoughts ? ` Kashyap From owner-freebsd-fs@FreeBSD.ORG Fri Apr 6 13:01:45 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3A0D106566B; Fri, 6 Apr 2012 13:01:45 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5D33A8FC0A; Fri, 6 Apr 2012 13:01:45 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id E5045CA1; Fri, 6 Apr 2012 15:01:37 +0200 (CEST) Date: Fri, 6 Apr 2012 15:00:06 +0200 From: Pawel Jakub Dawidek To: "Desai, Kashyap" Message-ID: <20120406130006.GC1336@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-fs@freebsd.org" , "freebsd-scsi@freebsd.org" , "Kenneth D.Merry" , "McConnell, Stephen" Subject: Re: Kernel crash at "softdep_deallocate_dependencies" 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: Fri, 06 Apr 2012 13:01:45 -0000 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2012 at 03:31:39PM +0530, Desai, Kashyap wrote: > Hi, Thanks in advance for looking this query and hoping for some help fro= m File system experts. >=20 > We have a RAID 0 volume which has partition (created using sysinstall fdi= sk option). > While IOs are in progress removing one of the volume member kernel panic = is hit with the following messages >=20 > g_vfs_done():(da0:da0s1d[WRITE(offset=3D6358872064, length=3D2048)]mpslsi= 0:0:error =3D 6 > 0:/home: got error 6 while accessing filesystem > 0): panic: softdep_deallocate_dependencies: unrecovered I/O error > lost device >=20 > Note: > 1. The issue is also seen on a RAID 0 volume which does not have a partit= ion on it. > 2. Issue was observed on both SAS and SATA drives. > 3. When we send IOs to the driver without FS (using "dd" command), kernel= panic never seen. >=20 >=20 > I have searched on this topic and looks like something wrong with FS. _bu= t_ I don't have any trigger to support that this is not Driver issue. This might be lame error handling on the FS side, but FS is not here to blame. You get I/O error from device below. In case of RAID0 you have no redundancy, so you cannot expect anything good by removing one of its components. Using "dd" doesn't trigger kernel panic, because I/O error is handled by userland process (it exits). > When we tried below options: (disable Journal on FS) Things does not chan= ge. We still see kernel panic. >=20 > umount > tunefs -j disable > mount > cd > rm .sujournal >=20 > Any thoughts ? What behaviour would you expect when your RAID0 volume dies? The best thing to do here would be to either stop all I/Os until the component is back or forcibly unmount the file system, but both options are probably hard to get right. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9+6NYACgkQForvXbEpPzTujQCg3rzzLyyVrVc/UtdrmFbb9PHA nxsAoOo1fZRtJoYUw+lIM2nKWqT9Xm0p =E9dp -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 6 13:08:34 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 442B7106564A; Fri, 6 Apr 2012 13:08:34 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id EB1838FC0C; Fri, 6 Apr 2012 13:08:33 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id E772BCA6; Fri, 6 Apr 2012 15:08:32 +0200 (CEST) Date: Fri, 6 Apr 2012 15:07:03 +0200 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20120406130702.GD1336@garage.freebsd.pl> References: <4F7BA173.6050903@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JwB53PgKC5A7+0Ej" Content-Disposition: inline In-Reply-To: <4F7BA173.6050903@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , fs@freebsd.org Subject: Re: "trim/discard" success story 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: Fri, 06 Apr 2012 13:08:34 -0000 --JwB53PgKC5A7+0Ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 03, 2012 at 06:18:43PM -0700, Julian Elischer wrote: > for flash drives this is great news.. > Now if ZFS would get trim support, that too would be great. I'm working on it. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --JwB53PgKC5A7+0Ej Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9+6nYACgkQForvXbEpPzSFlgCghBeQsZX9+3Z4lQ1FwkO8oM1Y 9bcAoM++OZVrTOivTp5q7DO0rv1zE50U =E+BJ -----END PGP SIGNATURE----- --JwB53PgKC5A7+0Ej-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 6 17:21:34 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 842991065670; Fri, 6 Apr 2012 17:21:34 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4D48FC18; Fri, 6 Apr 2012 17:21:34 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q36HLTj6030692; Fri, 6 Apr 2012 10:21:29 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201204061721.q36HLTj6030692@chez.mckusick.com> To: "Desai, Kashyap" In-reply-to: <20120406130006.GC1336@garage.freebsd.pl> Date: Fri, 06 Apr 2012 10:21:29 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: "freebsd-fs@freebsd.org" , "Kenneth D.Merry" , Pawel Jakub Dawidek , "McConnell, Stephen" Subject: Re: Kernel crash at "softdep_deallocate_dependencies" 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: Fri, 06 Apr 2012 17:21:34 -0000 Following through on Pawel Jakub Dawidek's comments, there is no way that the filesystem can recover when a large piece of its has disappeared. The panic that you are getting is because the soft updates system realizes that allowing writes to continue on the filesystem will cause it to be corrupted in an unrepairable way. As it has no way to cleanly downgrade it to read-only or unmount it, its only choice is to panic. If you do not like this panic, you can disable soft updates using: tunefs -n disable Absent the soft updates integrity checking, the filesystem will carry on a good bit longer (though after a reboot it will likely be unrecoverable even if you have put the disk back into it). Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Fri Apr 6 19:40:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D5961065670; Fri, 6 Apr 2012 19:40:55 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 8937B8FC0C; Fri, 6 Apr 2012 19:40:54 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so651919wib.13 for ; Fri, 06 Apr 2012 12:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=5ajjgz2Hqd6JkZ/fsSlqKw2CJQvOI4mBUCHOXlwew+U=; b=GxbQ7K6ek5sewEuQnSXNtulT2LKhWApYuWd5KRmp9EEjB86831NCrcP9a0ZZXOKxXy 2F0/w4Zxk+yqC9VStC8W5mCdNpL49dZfmnP9QXjyQx1cYizxVrieYLpYY3/5iDPuBeLQ e+sbjElKW4medSCRnaRbRaq1gmCfRKX62GZcrcQqGAi6i6YlbNvxOSklnTw4J95MNy7x F5y1Vg+PdqjomPpF+EkZgAvJcXqf1ULUa1TrIwRx9DLG04c7q7EamNb8Gmwup03o/r4q H3qhAOdxTLF/IDDFos13BGQlHsBAx8CCouSASe5mM01MWYmszmVa1j7jET+uId314p+P guzQ== Received: by 10.180.103.134 with SMTP id fw6mr25377897wib.0.1333741253313; Fri, 06 Apr 2012 12:40:53 -0700 (PDT) Received: from strashydlo.local (gate19.robnet.pl. [194.105.132.219]) by mx.google.com with ESMTPS id e6sm9093710wix.8.2012.04.06.12.40.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Apr 2012 12:40:52 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 6 Apr 2012 21:40:48 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Kirk McKusick Message-ID: <20120406194047.GA1673@strashydlo.local> Mail-Followup-To: Kirk McKusick , "Desai, Kashyap" , "freebsd-fs@freebsd.org" , "Kenneth D.Merry" , Pawel Jakub Dawidek , "McConnell, Stephen" References: <20120406130006.GC1336@garage.freebsd.pl> <201204061721.q36HLTj6030692@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204061721.q36HLTj6030692@chez.mckusick.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-fs@freebsd.org" , Pawel Jakub Dawidek , "Kenneth D.Merry" , "Desai, Kashyap" , "McConnell, Stephen" Subject: Re: Kernel crash at "softdep_deallocate_dependencies" 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: Fri, 06 Apr 2012 19:40:55 -0000 On Fri, Apr 06, 2012 at 10:21:29AM -0700, Kirk McKusick wrote: > Following through on Pawel Jakub Dawidek's comments, there is no > way that the filesystem can recover when a large piece of its has > disappeared. The panic that you are getting is because the soft > updates system realizes that allowing writes to continue on the > filesystem will cause it to be corrupted in an unrepairable way. > As it has no way to cleanly downgrade it to read-only or unmount > it, its only choice is to panic. Actually, there is a third way, which is what UFS mounted without softupdates does: do nothing. This works, because when ENXIO gets returned, the device is already gone. > If you do not like this panic, you can disable soft updates using: > > tunefs -n disable > > Absent the soft updates integrity checking, the filesystem will > carry on a good bit longer (though after a reboot it will likely > be unrecoverable even if you have put the disk back into it). Apart of a situation where ENXIO would be returned, but the device would stay accessible, which doesn't happen, afaik, what will actually happen is that all the operations on a filesystem will return ENXIO, except for reads for which the data is still in cache. Nothing will get written, so no further damage will be done, and it will be possible to forcibly unmount the filesystem without panicing.