From owner-freebsd-fs@FreeBSD.ORG Sun May 10 21:00:25 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85FC0A24 for ; Sun, 10 May 2015 21:00:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DA1B1AA9 for ; Sun, 10 May 2015 21:00:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4AL0PkK078640 for ; Sun, 10 May 2015 21:00:25 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201505102100.t4AL0PkK078640@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 10 May 2015 21:00:25 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 21:00:25 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 3 problems total for which you should take action. From owner-freebsd-fs@FreeBSD.ORG Mon May 11 16:56:17 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C748C457 for ; Mon, 11 May 2015 16:56:17 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51F741C82 for ; Mon, 11 May 2015 16:56:17 +0000 (UTC) Received: by lbcga7 with SMTP id ga7so98583797lbc.1 for ; Mon, 11 May 2015 09:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=JUtTr0ipwiBvw86o9s9vnE0P9b4vdFzRu/YwPt1vKVc=; b=mvdSJzIgHS3wazZORTmFv4XpzJUmCrHp4PnV8Y2KIV13nv+sJoPZrERaTdcApOH7fa DWOm3L13IGS5dPYDYpQCgrwxcujFVrmRP1fLGysXV/ea8Y2GvFYUCdpQdJwSXq0PuGIv 9LZdL3rVjg1RgUHJIHiO+2KFiNJt4HJtjFWwOxS0mkhUShLu/zAOLYn6e/5ABrwF5jCb N5dZ5DwEN9l7F1hvaJImpqFBjQoEpXZZHi6BN7EzYJvXhqoQ/204HoEE7B3s8L+Beozj zVYSo6DkLwLmbsop3giOFcKQGujE4FnwAfL/uM1NGhAhxYj0Slk7zLnK8Ex5JGuKDBeC d/AQ== MIME-Version: 1.0 X-Received: by 10.112.77.234 with SMTP id v10mr8610883lbw.119.1431363375262; Mon, 11 May 2015 09:56:15 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.112.247.73 with HTTP; Mon, 11 May 2015 09:56:15 -0700 (PDT) Date: Mon, 11 May 2015 18:56:15 +0200 X-Google-Sender-Auth: guO-FC9AKbupoIzPVsOWnmDVV30 Message-ID: Subject: mksnap_ffs: Cannot create snapshot: File too large From: Gabor Pali To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:56:17 -0000 [Please, cc me in your replies as I am not subscribed to this list. Thanks!] Folks, Recently, I started to use the snapshot feature of UFS, but I have been experiencing some oddities with it that puzzles me. I have a FreeBSD/amd64 10.1-RELEASE system (on a Hyper-V-managed VM), and I have a relatively small, about 8 GB of size, partition with UFS2, SU enabled where I want to take snapshots. It is mounted fine and works fine, but sometimes (quite at random), when the mksnap_ffs(8) utility is invoked, it gives the following error message (and creates an empty snapshot file, without the "snapshot" system flag set). # mount | fgrep /mnt/foo /dev/da2a on /mnt/foo (ufs, local, noatime, soft-updates) /mnt/foo on /some/other/directory (nullfs, local) /mnt/foo on /yet/another/directory (nullfs, local, read-only) # cd /mnt/foo # /sbin/mksnap_ffs .snapshot mksnap_ffs: Cannot create snapshot .snapshot: File too large In the meantime, I see the following messages in dmesg(8): bad block 3327649050063220270, ino 263776 pid 60313 (mksnap_ffs), uid 0 inumber 263776 on /mnt/foo: bad block While sometimes, the very same command on the very same file system works as expected. Could this be due to the additional nullfs(5) mounts? What does the "bad block" refer to? By the way, I also observed that once the snapshot is created successfully, its date still keeps changing. What does that mean? I did not find any information about that neither in the respective man page nor in the Handbook. It may be also related that I remove the snapshot file (via rm(1)) and recreate it under the same name (with mksnap_ffs(8)) in 30-minute intervals (from a cron(8)), that is when I use the updated snapshots to do a backup from the file system. Comments, hints, and ideas are welcome. From owner-freebsd-fs@FreeBSD.ORG Tue May 12 02:17:58 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DC177AF for ; Tue, 12 May 2015 02:17:58 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 68EC51D93 for ; Tue, 12 May 2015 02:17:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CkBAA4CE9V/95baINchEeDGMkqgVoRAQEBAQEBAYEKhEqBCwINGQJfiD+kDY9XknoBCgEBAR6BIY5SF4MjgUUFqWKKFSNhgzIigXaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,411,1427774400"; d="scan'208";a="210324574" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 11 May 2015 22:17:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B4CC8B3F4F for ; Mon, 11 May 2015 22:17:50 -0400 (EDT) Date: Mon, 11 May 2015 22:17:50 -0400 (EDT) From: Rick Macklem To: FreeBSD Filesystems Message-ID: <402295202.36197924.1431397070727.JavaMail.root@uoguelph.ca> Subject: RFC: should automounted file systems be exportable? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 02:17:58 -0000 A recent bug was reported related to mountd and the "automounted" flag. Loosely related to this is the question... Should automounted file systems be exportable? I haven't tested it, but I suspect that it would be broken and the NFS server will reply NFSERR_STALE after the file system has been dismounted. So, should I patch mountd so that it won't export automounted file systems? Thanks for any comments, rick From owner-freebsd-fs@FreeBSD.ORG Tue May 12 03:58:59 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AF267B2 for ; Tue, 12 May 2015 03:58:59 +0000 (UTC) Received: from paris.jfzb.net (paris.jfzb.net [107.179.25.55]) by mx1.freebsd.org (Postfix) with ESMTP id E91531D5B for ; Tue, 12 May 2015 03:58:58 +0000 (UTC) To: freebsd-fs@freebsd.org Subject: photos retouching Message-ID: <7558f17fc80fe07a66022d46df3b8644@tripadvisor.com> Date: Tue, 12 May 2015 06:00:51 +0200 From: "Joe" Reply-To: kansouedit@sina.com MIME-Version: 1.0 X-Mailer-LID: 5 X-Mailer-RecptId: 6480514 X-Mailer-SID: 346 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 03:58:59 -0000 Hope you are doing well! We provide photo editing: Such as ecommerce photos editing, jewelry photos retouching, beauty and skin image retouching, and wedding photo editing, image cut out and clipping path, masking. Our advantages: Quality is good Turnaround time fast 7/24/365 available Our service is best and price is affordable. You may send us a test photo to judge our quality. Have a good day! Best regards, Joe Email: songedit@tom.com From owner-freebsd-fs@FreeBSD.ORG Tue May 12 07:46:07 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 134724EA for ; Tue, 12 May 2015 07:46:07 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B56715A8 for ; Tue, 12 May 2015 07:46:06 +0000 (UTC) Received: by wizk4 with SMTP id k4so139858545wiz.1 for ; Tue, 12 May 2015 00:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=OMWEBC6ReIiFV5Vu6Tewud31Sx0rBQrh4cNxmToJDRk=; b=mKbGSox+EIAgoofw/rW/il+bEZGGdTaHv4D3klo8JshOqM1jf5VBdP6vhaePpvElsM +1uRqK2V91KCVvaBGZscu5Co7qtL9Rrwgjb6rWb+SsSdMgmAybYTYSCS3/VSUfIXEexA wj3Ix2DO1RxGYIVNpvmHDryMLqFAVShErRTN4DYXcYHJkGR50ReY+BmGiLZjcesQ+52X Az3INJg5VXIbHbV5D9OgBM0Y62LZHnT5met2QvdYAb2yBGjf2SP5YGzLG04EqnoGvBkJ Kk7tqLAd7Xadj1Wx5EsnshfXx/sxNpcYFdhP8gzMSFJ8VoouMbLqfCr66Cug1sOC2bU2 p6KQ== X-Received: by 10.180.104.225 with SMTP id gh1mr27032119wib.65.1431416764855; Tue, 12 May 2015 00:46:04 -0700 (PDT) Received: from brick.home (etm123.neoplus.adsl.tpnet.pl. [83.20.158.123]) by mx.google.com with ESMTPSA id fv7sm1505638wic.1.2015.05.12.00.46.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 00:46:03 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 12 May 2015 09:46:02 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Rick Macklem Cc: FreeBSD Filesystems Subject: Re: RFC: should automounted file systems be exportable? Message-ID: <20150512074602.GA93864@brick.home> Mail-Followup-To: Rick Macklem , FreeBSD Filesystems References: <402295202.36197924.1431397070727.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402295202.36197924.1431397070727.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 07:46:07 -0000 On 0511T2217, Rick Macklem wrote: > A recent bug was reported related to mountd and the > "automounted" flag. > > Loosely related to this is the question... > Should automounted file systems be exportable? > > I haven't tested it, but I suspect that it would be > broken and the NFS server will reply NFSERR_STALE > after the file system has been dismounted. > > So, should I patch mountd so that it won't export > automounted file systems? Exporting an automounted filesystem doesn't seem to make much sense, I agree, but I'm not sure if adding code to prevent it is such a good idea. If the user asks for it, by putting it into exports(5), it's his fault; the only thing this code could add would be a more friendly error message. From owner-freebsd-fs@FreeBSD.ORG Tue May 12 11:50:32 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07266C6C; Tue, 12 May 2015 11:50:32 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B3E541108; Tue, 12 May 2015 11:50:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DDBAA4CE9V/95baINcg2NeAQWDGMFNgViGBQKBVhMBAQEBAQEBgQqEIQEBBCNWGxgCAg0ZAlkGiD8Ns1eSegEBAQEBAQQBAQEBAQEBARqBIYoYhDoXNAeCaIFFBZZbgkaFIz6NLodHI2GBKByBbiIxAQEBAYFBgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,414,1427774400"; d="scan'208";a="210356782" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 May 2015 07:50:31 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C59D2B3F45; Tue, 12 May 2015 07:50:29 -0400 (EDT) Date: Tue, 12 May 2015 07:50:29 -0400 (EDT) From: Rick Macklem To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= Cc: FreeBSD Filesystems Message-ID: <599930852.36285001.1431431429794.JavaMail.root@uoguelph.ca> In-Reply-To: <20150512074602.GA93864@brick.home> Subject: Re: RFC: should automounted file systems be exportable? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 11:50:32 -0000 Edward Napierala wrote: > On 0511T2217, Rick Macklem wrote: > > A recent bug was reported related to mountd and the > > "automounted" flag. > > > > Loosely related to this is the question... > > Should automounted file systems be exportable? > > > > I haven't tested it, but I suspect that it would be > > broken and the NFS server will reply NFSERR_STALE > > after the file system has been dismounted. > > > > So, should I patch mountd so that it won't export > > automounted file systems? > > Exporting an automounted filesystem doesn't seem to make much sense, > I agree, but I'm not sure if adding code to prevent it is such > a good idea. If the user asks for it, by putting it into exports(5), > it's his fault; the only thing this code could add would be a more > friendly error message. > > Well, my thinking is that the recent patch to mountd that avoids doing mount update for non-exported file systems + one that doesn't allow automounted volumes to be exported fixes this bug: http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel That way, there is no rush w.r.t. how to update the high order bits of flags. (As noted in the comment w.r.t. the review of D2506, I'm not sure if an updated syscall is allowed to be MFC'd.) Since MNT_AUTOMOUNTED is the only high order bit at this time, once it is fixed, no MFC of the more generic fix is needed. Make sense? rick From owner-freebsd-fs@FreeBSD.ORG Tue May 12 12:51:14 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B53C75EF for ; Tue, 12 May 2015 12:51:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97F8F1969 for ; Tue, 12 May 2015 12:51:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4CCpEIl019357 for ; Tue, 12 May 2015 12:51:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199775] ZFS hangs while removing large file Date: Tue, 12 May 2015 12:51:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: danmer@danmer.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:51:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199775 --- Comment #4 from Yuriy Tabolin --- gstat hangs with a whole system. Last freezing data gstat -d -p:before hang: dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da4 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da5 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da6 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da7 0 553 553 510 0.3 0 0 0.0 0 0 0.0 17.0| da8 0 563 563 518 0.3 0 0 0.0 0 0 0.0 16.5| da9 0 564 564 520 0.4 0 0 0.0 0 0 0.0 19.9| da10 0 562 562 516 0.3 0 0 0.0 0 0 0.0 17.3| da11 0 548 548 500 0.3 0 0 0.0 0 0 0.0 16.4| da12 0 544 544 497 0.3 0 0 0.0 0 0 0.0 18.0| da13 0 549 549 503 0.3 0 0 0.0 0 0 0.0 19.0| da14 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da15 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da16 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da17 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da18 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da19 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da20 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da21 0 561 561 511 0.6 0 0 0.0 0 0 0.0 31.7| da22 0 1 0 0 0.0 1 4 0.2 0 0 0.0 0.0| ada0 0 1 0 0 0.0 1 4 0.2 0 0 0.0 0.0| ada1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0 da8-da14,da22 are disks in the pool where I delete big file. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue May 12 14:05:36 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7CAA61E for ; Tue, 12 May 2015 14:05:36 +0000 (UTC) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 155A411D0 for ; Tue, 12 May 2015 14:05:35 +0000 (UTC) Received: (qmail 18859 invoked from network); 12 May 2015 15:58:51 +0200 Received: from smtp.free.de (HELO [192.168.178.21]) (k@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 12 May 2015 15:58:51 +0200 Message-ID: <5552071A.40709@free.de> Date: Tue, 12 May 2015 15:58:50 +0200 From: Kai Gallasch Organization: FREE! User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: ZFS RAID 10 capacity expansion and uneven data distribution Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qtCRT52dH8X4w17M3JFjea7R0G8MGTsqd" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 14:05:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qtCRT52dH8X4w17M3JFjea7R0G8MGTsqd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello list. What is the preferred way to expand a mirrored or RAID 10 zpool with additional mirror pairs? On one server I am currently using a four disk RAID 10 zpool: zpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/zpool-da2 ONLINE 0 0 0 gpt/zpool-da3 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/zpool-da4 ONLINE 0 0 0 gpt/zpool-da5 ONLINE 0 0 0 Originally the pool consisted of only one mirror (zpool-da2 and zpool-da3= ) I then used "zpool add" to add mirror-1 to the pool Directly afer adding the new mirror I had all old data physically sitting on the old mirror and no data on the new disks. So there is much imbalance in the data distribution across the RAID 10. The effect is now, that the IOPS are not evently distributed about all devs of the pool and e.g. "gstat -p" when the server is very busy showed, that the old mirror pair can max out at 100% I/O usage while the other one is almost idle. Also: I also noted that the old mirror-pair had a FRAG about 50%, while the new one only has 3%. So is it generally not a good idea to expand a mirrored pool or RAID 10 pool with new mirror pairs? Or by which procedure can the existing data in the pool be evenly distributed about all devices inside the pool? Any hint appreciated. Regards, Kai. --=20 PGP-KeyID =3D 0x70654D7C4FB1F588 Der Techniker ist informiert. --qtCRT52dH8X4w17M3JFjea7R0G8MGTsqd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJVUgcaAAoJEHBlTXxPsfWIiMUP/0r48VZDm39vSPQ5l8EtYKqA eJ+M7qc4Qg7Y/Y3kz378/8TOgJr1TPExQmywVmsFdsS3wBE8N53YRj9NW6ux7tOt 97yOtTUXF8uCGZJvDkTgxh4IVFXHYVut7YrBhD25Z237fJj9QAlauDL5ky1b3Ch7 T/iEMiNbzEs6JA016wePXWQjmwf21XDiCS++KOmeK9lGO7Xr7D/M2fuRQwLo8KzF T2YRL+DVEAwd5rItTaPBkkp3gbnkCu0uGLr1DEiSGyh28CvuMXS5f/DuIe4b0QtH 7gRnpn36+jIE2CNjMA5C3ET7JtmW8e/ZLgHVRHw92u5nzrsXA/YEsjObxbRxArmZ m/QsIxpm+cosasLUa9SjpKn5vyW7z1hEezF5SHlckmnkBYT/xKO0t2kAFVh8Xo+Q 7DaGSiLLMQpcZbGwRotwJQI1V9No9fTZNoPGqdnBsx3MCJDpPVH4cNz5iGuNSVJo IsEiDNiTkSmHNpcQ9euku7+sqRpzqQc3KzGFOrKapYAgXFo/9oFH8AP1Ha9RS6Xb zvDNIxH9AEOQ9O2ECBUHHWom5UhioHEol42GVWmLT1BAsB3DMh4BUG8gqNoXIcqj GrOE7scq7hrKpznY0tb7aJrvP3Mv4g9FKhyGRYUIU8z+NxgDg+BKziKLBHKxRZwi bTu6BXUvCKvwFOatOSJ5 =mb50 -----END PGP SIGNATURE----- --qtCRT52dH8X4w17M3JFjea7R0G8MGTsqd-- From owner-freebsd-fs@FreeBSD.ORG Tue May 12 14:19:26 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 692DB7CC for ; Tue, 12 May 2015 14:19:26 +0000 (UTC) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) by mx1.freebsd.org (Postfix) with ESMTP id 27C2B1318 for ; Tue, 12 May 2015 14:19:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id 0F7BF147200B for ; Tue, 12 May 2015 16:09:23 +0200 (CEST) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2keXclwAkhz for ; Tue, 12 May 2015 16:09:21 +0200 (CEST) Received: from [192.168.100.26] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id 01FDD1472009 for ; Tue, 12 May 2015 16:09:20 +0200 (CEST) Message-ID: <555209AA.9010606@internetx.com> Date: Tue, 12 May 2015 16:09:46 +0200 From: InterNetX - Juergen Gotteswinter Reply-To: jg@internetx.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS RAID 10 capacity expansion and uneven data distribution References: <5552071A.40709@free.de> In-Reply-To: <5552071A.40709@free.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 14:19:26 -0000 Am 12.05.2015 um 15:58 schrieb Kai Gallasch: > Hello list. > > What is the preferred way to expand a mirrored or RAID 10 zpool with > additional mirror pairs? > > On one server I am currently using a four disk RAID 10 zpool: > > zpool ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/zpool-da2 ONLINE 0 0 0 > gpt/zpool-da3 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/zpool-da4 ONLINE 0 0 0 > gpt/zpool-da5 ONLINE 0 0 0 > > Originally the pool consisted of only one mirror (zpool-da2 and zpool-da3) > > I then used "zpool add" to add mirror-1 to the pool > > Directly afer adding the new mirror I had all old data physically > sitting on the old mirror and no data on the new disks. yep, this is the expected result > > So there is much imbalance in the data distribution across the RAID 10. > The effect is now, that the IOPS are not evently distributed about all > devs of the pool and e.g. "gstat -p" when the server is very busy > showed, that the old mirror pair can max out at 100% I/O usage while the > other one is almost idle. right, works as designed > > Also: I also noted that the old mirror-pair had a FRAG about 50%, while > the new one only has 3%. > same here > So is it generally not a good idea to expand a mirrored pool or RAID 10 > pool with new mirror pairs? > depends > Or by which procedure can the existing data in the pool be evenly > distributed about all devices inside the pool? > destroy / recreate > Any hint appreciated. > > Regards, > Kai. > From owner-freebsd-fs@FreeBSD.ORG Tue May 12 14:31:43 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1239CA0E for ; Tue, 12 May 2015 14:31:43 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F168F154E for ; Tue, 12 May 2015 14:31:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4CEVgQ7091830 for ; Tue, 12 May 2015 14:31:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199775] ZFS hangs while removing large file Date: Tue, 12 May 2015 14:31:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 14:31:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199775 --- Comment #5 from Andriy Gapon --- (In reply to Yuriy Tabolin from comment #4) Yuriy, if you want to try your development skills you might want to try to adapt a patch from here https://reviews.csiden.org/r/218/ to your source code tree and test if the patch helps in your situation. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed May 13 11:00:48 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE079510 for ; Wed, 13 May 2015 11:00:48 +0000 (UTC) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B422115BE for ; Wed, 13 May 2015 11:00:48 +0000 (UTC) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 1A19EAC72 for ; Wed, 13 May 2015 13:00:37 +0200 (CEST) Message-ID: <55532ED4.5060401@rlwinm.de> Date: Wed, 13 May 2015 13:00:36 +0200 From: Jan Bramkamp User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS RAID 10 capacity expansion and uneven data distribution References: <5552071A.40709@free.de> In-Reply-To: <5552071A.40709@free.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 11:00:49 -0000 On 12/05/15 15:58, Kai Gallasch wrote: > Hello list. > > What is the preferred way to expand a mirrored or RAID 10 zpool with > additional mirror pairs? > > On one server I am currently using a four disk RAID 10 zpool: > > zpool ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/zpool-da2 ONLINE 0 0 0 > gpt/zpool-da3 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/zpool-da4 ONLINE 0 0 0 > gpt/zpool-da5 ONLINE 0 0 0 > > Originally the pool consisted of only one mirror (zpool-da2 and zpool-da3) > > I then used "zpool add" to add mirror-1 to the pool > > Directly afer adding the new mirror I had all old data physically > sitting on the old mirror and no data on the new disks. > > So there is much imbalance in the data distribution across the RAID 10. > The effect is now, that the IOPS are not evently distributed about all > devs of the pool and e.g. "gstat -p" when the server is very busy > showed, that the old mirror pair can max out at 100% I/O usage while the > other one is almost idle. > > Also: I also noted that the old mirror-pair had a FRAG about 50%, while > the new one only has 3%. > > So is it generally not a good idea to expand a mirrored pool or RAID 10 > pool with new mirror pairs? > > Or by which procedure can the existing data in the pool be evenly > distributed about all devices inside the pool? ZFS will prefer the new VDEV for writes and they will slowly balance in due time. If you don't want to wait recreate the pool from a snapshot. Rebalancing between VDEVs requires moving a lot of data. ZFS as a COW filesystem requires the user to write data to move data (between VDEVS). Hiding this fact from the userspace would require the magical block pointer rewrites. Don't hold your breath. Nobody in OpenZFS the community wants to implement full block pointer rewriting because it would introduce a lot of new dependencies between ZFS internal layers. It would probably be the last major feature ever implemented in ZFS because it would complicate working with the code base a lot from what I gathered following the OpenZFS office hours. You are stuck with either an unbalanced pool or the task of recreating your pool from a snapshot stream. From owner-freebsd-fs@FreeBSD.ORG Wed May 13 12:35:18 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 172FB877; Wed, 13 May 2015 12:35:18 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96B4A1191; Wed, 13 May 2015 12:35:17 +0000 (UTC) Received: by labbd9 with SMTP id bd9so28192600lab.2; Wed, 13 May 2015 05:35:15 -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=5FqOL9yKXEPJNW2cw8C2kkJFZ26nRdjED1kHvIRgGyY=; b=CCScIGgHPc4/1t5so4oDkRzTTjsUsMN+FzH8s6h5sfPqQuVFcgkkoDrukbjOh1LMGb OaOL3Y5NX3PU8Z1Ij2amH4/qQXJDV5NIEz4XBbTkAHjs5/lwGZf9veoCzFEjoL5NDSoa njKHerSZRFsackHDtZWCFbvQkNuG0YtabTOLfGqHOaUTe3qD6rINq7HrjCPD6ch0c7Qb K6Y+Ji7G+WMpAOxT76LAMfILHtLLTYqicEaqt5+B4azQ6An0So+R0PS1oZP2B1hdrUQv 6JkskGsz1D8iCShYPuo5MT+xViIJYtHPOyIcYvmD2aHWOdi5fDu/PhHCICHxXqufhbrE LTjA== MIME-Version: 1.0 X-Received: by 10.112.25.69 with SMTP id a5mr15725954lbg.16.1431520515584; Wed, 13 May 2015 05:35:15 -0700 (PDT) Received: by 10.152.127.34 with HTTP; Wed, 13 May 2015 05:35:15 -0700 (PDT) Date: Wed, 13 May 2015 14:35:15 +0200 Message-ID: Subject: exfatfsck UTF-8 From: Tomek CEDRO To: FreeBSD Filesystems , freebsd-bugs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 12:35:18 -0000 I found an issue with UTF-8 conversion in exfatfsck.. Any idea if this is OS related or upstream issue? I use exfatfsck for the first time.. :-) Best regards, Tomek root@hexagon:~ # exfatfsck /dev/da0s1 exfatfsck 1.0.1 WARN: volume was not unmounted cleanly. Checking file system on /dev/da0s1. File system version 1.0 Sector size 512 bytes Cluster size 128 KB Volume size 1863 GB Used space 1822 GB Available space 42 GB ERROR: `0.indexGroups' real size does not equal to size (237568 != 419431). ERROR: failed to open directory `/.Spotlight-V100/Store-V2/7FAF0041-B011-4200-ACD2-8EB7654E2B06'. ERROR: name is too long. BUG: failed to convert name to UTF-8. Abort (core dumped) root@hexagon:~ # uname -a FreeBSD hexagon 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr 7 01:09:46 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@hexagon:~ # gdb exfatfsck GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run /dev/da0s1 Starting program: /usr/local/sbin/exfatfsck /dev/da0s1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...exfatfsck 1.0.1 WARN: volume was not unmounted cleanly. Checking file system on /dev/da0s1. File system version 1.0 Sector size 512 bytes Cluster size 128 KB Volume size 1863 GB Used space 1822 GB Available space 42 GB ERROR: `0.indexGroups' real size does not equal to size (237568 != 419431). ERROR: failed to open directory `/.Spotlight-V100/Store-V2/7FAF0041-B011-4200-ACD2-8EB7654E2B06'. ERROR: name is too long. BUG: failed to convert name to UTF-8. Program received signal SIGABRT, Aborted. 0x0000000800b6da1a in kill () from /lib/libc.so.7 (gdb) bt #0 0x0000000800b6da1a in kill () from /lib/libc.so.7 #1 0x0000000800b6c149 in abort () from /lib/libc.so.7 #2 0x0000000000402f8c in ?? () #3 0x0000000000406daa in ?? () #4 0x0000000000401680 in ?? () #5 0x00000000004016b2 in ?? () #6 0x00000000004016b2 in ?? () #7 0x00000000004016b2 in ?? () #8 0x00000000004016b2 in ?? () #9 0x00000000004016b2 in ?? () #10 0x00000000004016b2 in ?? () #11 0x00000000004016b2 in ?? () #12 0x00000000004016b2 in ?? () #13 0x00000000004016b2 in ?? () #14 0x00000000004016b2 in ?? () #15 0x00000000004016b2 in ?? () #16 0x00000000004016b2 in ?? () #17 0x00000000004016b2 in ?? () #18 0x00000000004016b2 in ?? () #19 0x00000000004016b2 in ?? () #20 0x00000000004014b6 in ?? () #21 0x00000000004012ef in ?? () #22 0x0000000800627000 in ?? () #23 0x0000000000000000 in ?? () -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Wed May 13 12:48:08 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79761C6B for ; Wed, 13 May 2015 12:48:08 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA1A12C4 for ; Wed, 13 May 2015 12:48:08 +0000 (UTC) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id B739613E2 for ; Wed, 13 May 2015 15:48:00 +0300 (MSK) Message-ID: <555347FF.2070302@FreeBSD.org> Date: Wed, 13 May 2015 15:47:59 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: chflags doesn't understand flag 2048 whihc could be printed by stat -f '%f' on ZFS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 12:48:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have script which copies permissions & flags from one file to another. It is like this: chmod `stat -f '%Lp' "$from"` "$to" chflags `stat -f '%f' "$from"` "$to" It works on UFS but sometimes fails on ZFS because some files has "2048" flag and chflags doesn't understand this one. Is it Ok or it is bug in chflags? - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJVU0f/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePlngP/RSz9iqXY11FVu0h9lSZqc7y g97CSiKt0VLglzb0uHMxNjvLCcKY0d4QYLFAYc+4uKdwgOQr6X1SYCWXmBRgGfZQ 41GQ+rvmw48TH5vyBANjEphr4LdAZ18es4xoJ9f96qYC2LeHaUQaYqEWFxED6DfE JS1NhcSOJx2h21jYFgKVdBbvpw3XNknpnGhcLsDoIQJs01HnMEVKl3lEBzr6wS6c KyMSiE65hct56v2QamrDPdmEmJeI77iEw+yKhuSIqM5ApkvWLzweYN7GxIRfB86z 16AG4VY4Qsy6+nINFYSTqJDZLgYD2ZsFt6zhKgWUZ89mSc5A7Ehc1mJnK2bDb3XB Z1koBYx/cyNG1mPGMt5FkHcA7WIB0ROB4rw37kgLqO1HtsSuVQ9GiXEYunhitr9z Qkq2G46TPEqVLGWzIU2ndJufT5sY88TxwkRIGCLrDBuD7oLuHk0epmIu3fYwQ8DJ 3vtV2ryCgMVSMEqO44WKrXIXecr8RY3NKR09wwQUZ++lF88GDDTTaYg6x2iuk0W2 hMdp6dedyuew494gFuKQp39f3y1znvWaJfd/FvrgE1ePs/xLcOdQ2nhrK1ysKCqD 9/ahplzQH3l6zF9L7gpLH1naOjvXem4psKvKy1Qei3LpYG5DVaYiwqbVZo9mf69H qFIY//rnpBDvuEXEVA8z =3K+Z -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Wed May 13 13:14:21 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74C827D4; Wed, 13 May 2015 13:14:21 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA0081721; Wed, 13 May 2015 13:14:20 +0000 (UTC) Received: by lbcga7 with SMTP id ga7so29215577lbc.1; Wed, 13 May 2015 06:14:18 -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=WQwOM82vIl0F3BjYaNeHuB8tkMRBHB24wP9IXeKVFqM=; b=Sv18e9icljDxVOTdA/CDQes40t86A45ZkxoeZ2rcZqzvR5UcAbrJdlHsQq3GWVVfz4 Zqc63rXCj+Xx77siBrX1EBuOsLjkrmrXFjpUfwInPFGsiOK3b1j7Da8dblgE0lgirnpV EhRlp1+9K1xPUmpEdBJZWxWDssspbEFk9Rlo3bogsgbiJBxJ29cr6/wuwoVeYDjlACUm i0WCtyYtopNTMz4DXaxDtFAvgpvTXnQctxVbHlaTT6BbIiKC+zKYW8FDRm1F2NtobbIo tv6xDW8xr2yoGmiW91rI5C/UT6sL4nijHFvs4X9nsZmM/PsiUAT7o9J55U/fyUubweMq In2g== MIME-Version: 1.0 X-Received: by 10.112.220.34 with SMTP id pt2mr16173408lbc.81.1431522858860; Wed, 13 May 2015 06:14:18 -0700 (PDT) Received: by 10.152.127.34 with HTTP; Wed, 13 May 2015 06:14:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 15:14:18 +0200 Message-ID: Subject: Re: exfatfsck UTF-8 From: Tomek CEDRO To: FreeBSD Filesystems , freebsd-bugs@freebsd.org, samm@os2.kiev.ua Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 13:14:21 -0000 Here goes the output with debug symbols included of exFAT-FSCK UTF-8 BUG :-= ) root@hexagon:/usr/ports/sysutils/exfat-utils # uname -a FreeBSD hexagon 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr 7 01:09:46 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@hexagon:/usr/ports/sysutils/exfat-utils # gdb /usr/local/sbin/exfatfsc= k GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) run /dev/da0s1 Starting program: /usr/local/sbin/exfatfsck /dev/da0s1 exfatfsck 1.0.1 WARN: volume was not unmounted cleanly. Checking file system on /dev/da0s1. File system version 1.0 Sector size 512 bytes Cluster size 128 KB Volume size 1863 GB Used space 1822 GB Available space 42 GB ERROR: `0.indexGroups' real size does not equal to size (237568 !=3D 419431= ). ERROR: failed to open directory `/.Spotlight-V100/Store-V2/7FAF0041-B011-4200-ACD2-8EB7654E2B06'. ERROR: name is too long. BUG: failed to convert name to UTF-8. Program received signal SIGABRT, Aborted. 0x0000000800b71a1a in kill () from /lib/libc.so.7 (gdb) bt #0 0x0000000800b71a1a in kill () from /lib/libc.so.7 #1 0x0000000800b70149 in abort () from /lib/libc.so.7 #2 0x0000000000403f0d in exfat_bug (format=3D0x40be98 "failed to convert name to UTF-8") at libexfat/log.c:48 #3 0x000000000040a79b in exfat_get_name (node=3D0x80c55d100, buffer=3D0x8029e6b21 "AudioConverterFillComplexBuffer(AudioConverterRef,AudioConverterComplexInp= utDataProc,UnsafeMutablePointer=EF=BF=BD\200=EF=BF=BDVoid=EF=BF=BD\200=EF= =BF=BD,UnsafeMutablePointer=EF=BF=BD\200=EF=BF=BDUInt32=EF=BF=BD\200=EF=BF= =BD,UnsafeMutablePointer=EF=BF=BD\200=EF=BF=BDAudioBufferList=EF=BF=BD\200= =EF=BF=BD,UnsafeMut"..., n=3D256) at libexfat/utils.c:50 #4 0x0000000000401883 in dirck (ef=3D0x7fffffffea58, path=3D0x8029e68c0 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Tokens/s= wift/func/-") at fsck/main.c:98 #5 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x8029e6700 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Tokens/s= wift/func") at fsck/main.c:105 #6 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x8029e6540 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Tokens/s= wift") at fsck/main.c:105 #7 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x8029e6380 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Tokens") at fsck/main.c:105 #8 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x8029e61c0 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources") at fsck/main.c:105 #9 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801fc6480 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets/com.apple.adc.documentation.iOS.docset/Contents") at fsck/main.c:105 #10 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801fc6300 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets/com.apple.adc.documentation.iOS.docset") at fsck/main.c:105 #11 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801fc6180 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= /DocSets") at fsck/main.c:105 #12 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801be68c0 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer/Documentation= ") at fsck/main.c:105 #13 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801be6780 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents/Developer") at fsck/main.c:105 #14 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801be6640 "/TOSCA/20150320bkp/Applications/Xcode.app/Contents") at fsck/main.c:105 #15 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801be6500 "/TOSCA/20150320bkp/Applications/Xcode.app") at fsck/main.c:105 #16 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801be63c0 "/TOSCA/20150320bkp/Applications") at fsck/main.c:105 #17 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801be6280 "/TOSCA/20150320bkp") at fsck/main.c:105 #18 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x801be6140 "/TOSCA") at fsck/main.c:105 #19 0x00000000004018bf in dirck (ef=3D0x7fffffffea58, path=3D0x40af86 "") at fsck/main.c:105 #20 0x00000000004016d0 in fsck (ef=3D0x7fffffffea58) at fsck/main.c:122 #21 0x0000000000401573 in main (argc=3D2, argv=3D0x7fffffffeba0) at fsck/ma= in.c:159 (gdb) q The program is running. Exit anyway? (y or n) y --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Wed May 13 13:21:53 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D3A598A; Wed, 13 May 2015 13:21:53 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C36B3183F; Wed, 13 May 2015 13:21:52 +0000 (UTC) Received: by lagv1 with SMTP id v1so29141250lag.3; Wed, 13 May 2015 06:21:50 -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=PGYlgrc29/TJ7isxkvX4mspkFx06/Kife6j83naEz20=; b=sR8ZfAQL1i/J9cmQtVrqNFRvTEEMxifWNrQAddD03iqx1bKIH+yexeCMYH2hJRMWEs L4rTgeji3v7IgfZUbng3PTbgj7M4ytt7L8p8LsfEhOrYZ7wi+g7fGWkhvcSAgc5cDl6N OJGobFLz/eB3FLfVyzQSC4oz/C80UGWWye4aUEg3DrDJa7C9kUHIjsMF960ZyZdtZEi5 bYxrJbIsf6Blzl3DBUDuCcBUECpaS9M5fSzpggLzwHHY1uvMgSgheDK71tyAhU1VhfRl 2+LFAE7+gM2G7VYnhA26GDqWkProtC/U0lwHwy6fOMTfHtaMWx6J36ewPA+f+m9aWGlu YdEw== MIME-Version: 1.0 X-Received: by 10.112.161.226 with SMTP id xv2mr16207931lbb.106.1431523310077; Wed, 13 May 2015 06:21:50 -0700 (PDT) Received: by 10.152.127.34 with HTTP; Wed, 13 May 2015 06:21:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 15:21:50 +0200 Message-ID: Subject: Re: exfatfsck UTF-8 From: Tomek CEDRO To: FreeBSD Filesystems , freebsd-bugs@freebsd.org, samm@os2.kiev.ua Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 13:21:53 -0000 According to project website downloads [1] version 1.0.1 is far behind the head and over 2 years old. Please update the port to end-of-2014 1.1.1 if possible :-) [1] https://code.google.com/p/exfat/wiki/Downloads?tm=2 -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Wed May 13 16:40:20 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F98F6D9 for ; Wed, 13 May 2015 16:40:20 +0000 (UTC) Received: from smtp102-5.vfemail.net (eightfive.vfemail.net [96.30.253.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E93015D2 for ; Wed, 13 May 2015 16:40:20 +0000 (UTC) Received: (qmail 29072 invoked by uid 89); 13 May 2015 16:33:37 -0000 Received: by simscan 1.4.0 ppid: 29065, pid: 29068, t: 0.0957s scanners:none Received: from unknown (HELO d3d3MTExQDE0MzE1MzQ4MTc=) (cmlja0BoYXZva21vbi5jb21AMTQzMTUzNDgxNw==@MTcyLjE2LjEwMC45M0AxNDMxNTM0ODE3) by 172.16.100.62 with ESMTPA; 13 May 2015 16:33:37 -0000 Date: Wed, 13 May 2015 11:33:37 -0500 Message-ID: <20150513113337.Horde.PhGEagHa3QWN97i4Qrk6hw8@www.vfemail.net> From: Rick Romero To: freebsd-fs@freebsd.org Subject: Re: 10.1 + ZFS snapshot eating diskspace In-Reply-To: <20150427110832.Horde.MAoPtcoic1-3sfV0OhkyxQ1@www.vfemail.net> User-Agent: Internet Messaging Program (IMP) H5 (6.2.2) X-VFEmail-Originating-IP: MTIuMzEuMTAwLjE0Ng== X-VFEmail-AntiSpam: Notify admin@vfemail.net of any spam, and include VFEmail headers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes Content-Transfer-Encoding: 8bit Content-Disposition: inline Content-Description: Plaintext Message X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:40:20 -0000 Ronald was on the right track.  https://lists.freebsd.org/pipermail/freebsd-fs/2015-April/021144.html The drives on the new system, while identical to the old, use native 4k sectors. In FreeBSD 10.1, ZFS automatically used ashift=12 - the old 9.2 system used an ashift of 9. Since my data is small files (mostly < 16k), the space is used VERY inefficiently with an ashift of 12. Setting vfs.zfs.max_auto_ashift: 9  prior to creating the new pool resulted in a properly sized volume after the zfs receive. zpool status complains about performace degradation, of which I'm definitely choosing space+cost over performance, but at least zpool status -x shows all good. Quoting Rick Romero : > Try number two.   I built another new system, no encryption this time. > > I replacated ONE snapshot that is about 562GB of data. > (I just found Ronalds reply in my Spam folder, sorry!) > This new 10.1 system has the exact same 3 drives in RAIDZ1 as the original > source (9.2).  What's confusing is the original RAIDZ1 is replicated > correctly to a 10 drive RAIDZ2 (10.1), but the RAIDZ2 source cannot > replicate data correctly to a new 3 drive RAIDZ1. > So not only is this a problem with the new system, but it concerns me that > if there were a problem with the old system that a full restore from > backup > would eat all the disk space. > > Source: > # zfs get all sysvol/primessd_home |grep -i used > sysvol/primessd_home  used                  > 822G                   - > sysvol/primessd_home  usedbysnapshots       > 260G                   - > sysvol/primessd_home  usedbydataset         > 562G                   - > sysvol/primessd_home  usedbychildren        > 0                      - > sysvol/primessd_home  usedbyrefreservation  > 0                      - > sysvol/primessd_home  logicalused           > 811G                   - > > Right? 562 is the 'current' amount of space used?  > > So I send it to a new box, and this is the result > > # zfs list -t all > NAME                        USED  AVAIL  REFER  > MOUNTPOINT > sysvol                      919G      0  12.5G  > /sysvol > sysvol/home                 906G      0   898G  > /sysvol/home > sysvol/home@remrep-Week16  8.53G      -   898G  - > > I can see a possible sector size diff or recordsize affecting a few bytes, > but 400G is a bit excessive. The fact that it more closely matches the > full > dataset+snapshots, IMHO, is much more telling. > > # zfs get all sysvol/home | grep used > sysvol/home  used                  > 906G                   - > sysvol/home  usedbysnapshots       > 8.53G                  - > sysvol/home  usedbydataset         > 898G                   - > sysvol/home  usedbychildren        > 0                      - > sysvol/home  usedbyrefreservation  > 0                      - > sysvol/home  logicalused           > 574G                   - > > logical used is actual used, correct?   Why is it the 'full' amount, when > only one snapshot was replicated? > > So I thought maybe it's not reporting correctly > > # zfs list > NAME          USED  AVAIL  REFER  MOUNTPOINT > sysvol        907G  12.3G   256M  /sysvol > sysvol/home   906G  12.3G   898G  /sysvol/home > > # dd bs=1M count=12560 if=/dev/zero of=test2 > dd: test2: No space left on device > 12558+0 records in > 12557+1 records out > 13167886336 bytes transferred in 33.499157 secs (393081126 bytes/sec) > # zfs list > NAME          USED  AVAIL  REFER  MOUNTPOINT > sysvol        919G      0  12.5G  /sysvol > sysvol/home   906G      0   898G  /sysvol/home > # dd bs=1M count=12560 if=/dev/zero of=test3 > dd: test3: No space left on device > > So what's going on?  Is this a known issue? > I suppose I can take the new server down to the colo and replicate from > the > original, but that doesn't resolve the 'restore from backup' issue that I > see happening... > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fsTo unsubscribe, send > any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 13 18:54:23 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 386279BE for ; Wed, 13 May 2015 18:54:23 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAB41167C for ; Wed, 13 May 2015 18:54:22 +0000 (UTC) Received: by lagv1 with SMTP id v1so36224975lag.3 for ; Wed, 13 May 2015 11:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iastate.edu; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=NOMxrgqsF/hz/KTlVK3cqOvWFrJ/EdJR8ZqOvNQDjWI=; b=eTB6T218K2ZZc18V7azmt762yQM3ltuUOMtZbVdltrYqmB+Nnm23PQ0CEkP90YOU+q R2zR1RORUCCvKmFMStmURD+78PEwHL7uDg5/HMPzgAfxqqAEvSvaLHd05l8hDFy25aNd 1r/+u7dXaMpY9ZuX1zSfUF4QnAfmSWQ6svdOM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=NOMxrgqsF/hz/KTlVK3cqOvWFrJ/EdJR8ZqOvNQDjWI=; b=klyaxVMNgsfCuYHtqb+5knCLXXBDzdw6Nb4XzVBnvwA9hU0otJooWSIfFjoIy12QTl QoSF6QqC9lRJeJ6esRDwXCz+Z4+E+ZbwvlA2D6QhaaZY5Ca97uT+zhTGS8NWADe2lrad Hjl4yt4e38ozQC0YfJJqtH5uQUxOm9eobxntbZJLiKyQ9ZdLA23FiHvWj25u5h3CpWeS rKrbmkiqhCGk0vuyOWBV7EQfVRtpnzAMMqrHOG/AXanKLyXBQ/B8BAf0aeTHS0k0Bran vmmw6jiHiongk2BIdj5g31FU36pA8IMkUHxzvqfuvBoWymtIfaykjEQxwIzaKADqPeOU WK4A== X-Gm-Message-State: ALoCoQkA9x/5HTAj5rF+V30q9MJPhrmim3lh2tTEDJNhL9WwBcykAX81D+zVUw0Wf/9HixdsU4Z4 X-Received: by 10.153.7.133 with SMTP id dc5mr244203lad.17.1431543260651; Wed, 13 May 2015 11:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.12.202 with HTTP; Wed, 13 May 2015 11:54:00 -0700 (PDT) From: Nathan Weeks Date: Wed, 13 May 2015 13:54:00 -0500 Message-ID: Subject: ZFS read performance disparity between clone and parent To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:54:23 -0000 While troubleshooting performance disparities between development and production jails hosting PostgreSQL instances, I noticed (with the help of dtruss) that the 8k read() performance in the production jail was an order of magnitude worse than the read() performance in the development jail. As the ZFS file system hosting the production jail was cloned from a snapshot of the development jail, and had not been modified, this didn't make sense to me. Using "dd" command with an 8k block size to emulate the PostgreSQL read() size, I observed a large performance difference between reading one of the large (1G) underlying postgres database files in the development jail's file system vs. the corresponding file in the cloned file system: # dd if=/jails/dev/usr/local/pgsql/data/base/16399/16436 of=/dev/null bs=8192 131072+0 records in 131072+0 records out 1073741824 bytes transferred in 4.198993 secs (255714128 bytes/sec) # dd if=/jails/prod/usr/local/pgsql/data/base/16399/16436 of=/dev/null bs=8192 131072+0 records in 131072+0 records out 1073741824 bytes transferred in 17.314135 secs (62015331 bytes/sec) # ls -l /jails/dev/usr/local/pgsql/data/base/16399/16436 /jails/prod/usr/local/pgsql/data/base/16399/16436 -rw------- 1 70 70 1073741824 Feb 5 16:41 /jails/dev/usr/local/pgsql/data/base/16399/16436 -rw------- 1 70 70 1073741824 Feb 5 16:41 /jails/prod/usr/local/pgsql/data/base/16399/16436 I repeated this exercise several times to verify the read performance difference. Interestingly, prefixing the "dd" command with "/usr/bin/time -l" revealed that in both cases, "block input operations" was 0, apparently indicating that both files were being read from cache. In neither case did "zpool iostat 1" show significant I/O being performed during the execution of the "dd" command. Has anyone else encountered a similar issue, and know of an explanation/solution/better workaround? I had previously assumed that there would be no performance difference between reading a file on a ZFS file system and the corresponding file on a cloned file system when none of the data blocks have changed (this is FreeBSD 9.3, so the "Single Copy ARC" feature should apply). Dedup isn't being used on any file system. The output of zfs-stats follows; I can provide any additional info that might be of use in identifying the cause of this issue. ------------------------------------------------------------------------ ZFS Subsystem Report Wed May 13 12:22:00 2015 ------------------------------------------------------------------------ System Information: Kernel Version: 903000 (osreldate) Hardware Platform: amd64 Processor Architecture: amd64 ZFS Storage pool Version: 5000 ZFS Filesystem Version: 5 FreeBSD 9.3-RELEASE-p5 #0: Mon Nov 3 22:38:58 UTC 2014 root 12:22PM up 166 days, 3:36, 7 users, load averages: 2.34, 2.31, 2.17 ------------------------------------------------------------------------ System Memory: 8.83% 21.95 GiB Active, 1.67% 4.14 GiB Inact 68.99% 171.40 GiB Wired, 0.40% 1.00 GiB Cache 20.10% 49.93 GiB Free, 0.01% 16.12 MiB Gap Real Installed: 256.00 GiB Real Available: 99.99% 255.97 GiB Real Managed: 97.06% 248.43 GiB Logical Total: 256.00 GiB Logical Used: 78.49% 200.92 GiB Logical Free: 21.51% 55.08 GiB Kernel Memory: 117.28 GiB Data: 99.98% 117.25 GiB Text: 0.02% 26.07 MiB Kernel Memory Map: 241.10 GiB Size: 43.83% 105.67 GiB Free: 56.17% 135.43 GiB ------------------------------------------------------------------------ ARC Summary: (HEALTHY) Memory Throttle Count: 0 ARC Misc: Deleted: 143.56m Recycle Misses: 275.73m Mutex Misses: 1.50m Evict Skips: 20.24b ARC Size: 99.77% 127.71 GiB Target Size: (Adaptive) 100.00% 128.00 GiB Min Size (Hard Limit): 12.50% 16.00 GiB Max Size (High Water): 8:1 128.00 GiB ARC Size Breakdown: Recently Used Cache Size: 68.86% 88.15 GiB Frequently Used Cache Size: 31.14% 39.85 GiB ARC Hash Breakdown: Elements Max: 27.87m Elements Current: 40.13% 11.18m Collisions: 1.95b Chain Max: 26 Chains: 2.44m ------------------------------------------------------------------------ ARC Efficiency: 88.77b Cache Hit Ratio: 99.52% 88.34b Cache Miss Ratio: 0.48% 426.00m Actual Hit Ratio: 98.86% 87.76b Data Demand Efficiency: 99.99% 58.75b Data Prefetch Efficiency: 98.47% 1.08b CACHE HITS BY CACHE LIST: Anonymously Used: 0.21% 187.51m Most Recently Used: 1.93% 1.71b Most Frequently Used: 97.41% 86.05b Most Recently Used Ghost: 0.04% 39.14m Most Frequently Used Ghost: 0.41% 358.78m CACHE HITS BY DATA TYPE: Demand Data: 66.49% 58.74b Prefetch Data: 1.21% 1.07b Demand Metadata: 31.74% 28.04b Prefetch Metadata: 0.56% 491.01m CACHE MISSES BY DATA TYPE: Demand Data: 1.70% 7.26m Prefetch Data: 3.89% 16.56m Demand Metadata: 83.84% 357.15m Prefetch Metadata: 10.57% 45.03m ------------------------------------------------------------------------ L2ARC is disabled ------------------------------------------------------------------------ File-Level Prefetch: (HEALTHY) DMU Efficiency: 187.26b Hit Ratio: 82.21% 153.94b Miss Ratio: 17.79% 33.32b Colinear: 33.32b Hit Ratio: 0.01% 3.35m Miss Ratio: 99.99% 33.32b Stride: 150.63b Hit Ratio: 100.00% 150.63b Miss Ratio: 0.00% 453.04k DMU Misc: Reclaim: 33.32b Successes: 0.36% 118.64m Failures: 99.64% 33.20b Streams: 3.31b +Resets: 0.00% 20.36k -Resets: 100.00% 3.31b Bogus: 0 ------------------------------------------------------------------------ VDEV cache is disabled ------------------------------------------------------------------------ ZFS Tunables (sysctl): kern.maxusers 16718 vm.kmem_size 266754412544 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 329853485875 vfs.zfs.l2c_only_size 0 vfs.zfs.mfu_ghost_data_lsize 63695688192 vfs.zfs.mfu_ghost_metadata_lsize 8300248064 vfs.zfs.mfu_ghost_size 71995936256 vfs.zfs.mfu_data_lsize 34951425024 vfs.zfs.mfu_metadata_lsize 4976638976 vfs.zfs.mfu_size 41843978240 vfs.zfs.mru_ghost_data_lsize 41844330496 vfs.zfs.mru_ghost_metadata_lsize 23598693888 vfs.zfs.mru_ghost_size 65443024384 vfs.zfs.mru_data_lsize 67918019072 vfs.zfs.mru_metadata_lsize 411918848 vfs.zfs.mru_size 71823354880 vfs.zfs.anon_data_lsize 0 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_size 29893120 vfs.zfs.l2arc_norw 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_noprefetch 1 vfs.zfs.l2arc_feed_min_ms 200 vfs.zfs.l2arc_feed_secs 1 vfs.zfs.l2arc_headroom 2 vfs.zfs.l2arc_write_boost 8388608 vfs.zfs.l2arc_write_max 8388608 vfs.zfs.arc_meta_limit 34359738368 vfs.zfs.arc_meta_used 34250008792 vfs.zfs.arc_min 17179869184 vfs.zfs.arc_max 137438953472 vfs.zfs.dedup.prefetch 1 vfs.zfs.mdcomp_disable 0 vfs.zfs.nopwrite_enabled 1 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.zfetch.block_cap 256 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.max_streams 8 vfs.zfs.prefetch_disable 0 vfs.zfs.no_scrub_prefetch 0 vfs.zfs.no_scrub_io 0 vfs.zfs.resilver_min_time_ms 3000 vfs.zfs.free_min_time_ms 1000 vfs.zfs.scan_min_time_ms 1000 vfs.zfs.scan_idle 50 vfs.zfs.scrub_delay 4 vfs.zfs.resilver_delay 2 vfs.zfs.top_maxinflight 32 vfs.zfs.write_to_degraded 0 vfs.zfs.mg_noalloc_threshold 0 vfs.zfs.condense_pct 200 vfs.zfs.metaslab.weight_factor_enable 0 vfs.zfs.metaslab.preload_enabled 1 vfs.zfs.metaslab.preload_limit 3 vfs.zfs.metaslab.unload_delay 8 vfs.zfs.metaslab.load_pct 50 vfs.zfs.metaslab.min_alloc_size 10485760 vfs.zfs.metaslab.df_free_pct 4 vfs.zfs.metaslab.df_alloc_threshold 131072 vfs.zfs.metaslab.debug_unload 0 vfs.zfs.metaslab.debug_load 0 vfs.zfs.metaslab.gang_bang 131073 vfs.zfs.check_hostid 1 vfs.zfs.spa_asize_inflation 24 vfs.zfs.deadman_enabled 1 vfs.zfs.deadman_checktime_ms 5000 vfs.zfs.deadman_synctime_ms 1000000 vfs.zfs.recover 0 vfs.zfs.txg.timeout 5 vfs.zfs.min_auto_ashift 9 vfs.zfs.max_auto_ashift 13 vfs.zfs.vdev.cache.bshift 16 vfs.zfs.vdev.cache.size 0 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.trim_on_init 1 vfs.zfs.vdev.write_gap_limit 4096 vfs.zfs.vdev.read_gap_limit 32768 vfs.zfs.vdev.aggregation_limit 131072 vfs.zfs.vdev.scrub_max_active 2 vfs.zfs.vdev.scrub_min_active 1 vfs.zfs.vdev.async_write_max_active 10 vfs.zfs.vdev.async_write_min_active 1 vfs.zfs.vdev.async_read_max_active 3 vfs.zfs.vdev.async_read_min_active 1 vfs.zfs.vdev.sync_write_max_active 10 vfs.zfs.vdev.sync_write_min_active 10 vfs.zfs.vdev.sync_read_max_active 10 vfs.zfs.vdev.sync_read_min_active 10 vfs.zfs.vdev.max_active 1000 vfs.zfs.vdev.bio_delete_disable 0 vfs.zfs.vdev.bio_flush_disable 0 vfs.zfs.vdev.trim_max_pending 64 vfs.zfs.vdev.trim_max_bytes 2147483648 vfs.zfs.cache_flush_disable 0 vfs.zfs.zil_replay_disable 0 vfs.zfs.sync_pass_rewrite 2 vfs.zfs.sync_pass_dont_compress 5 vfs.zfs.sync_pass_deferred_free 2 vfs.zfs.zio.use_uma 0 vfs.zfs.snapshot_list_prefetch 0 vfs.zfs.version.ioctl 3 vfs.zfs.version.zpl 5 vfs.zfs.version.spa 5000 vfs.zfs.version.acl 1 vfs.zfs.debug 0 vfs.zfs.super_owner 0 vfs.zfs.trim.enabled 1 vfs.zfs.trim.max_interval 1 vfs.zfs.trim.timeout 30 vfs.zfs.trim.txg_delay 32 ------------------------------------------------------------------------ -- Nathan Weeks USDA-ARS Corn Insects and Crop Genetics Research Unit Crop Genome Informatics Laboratory Iowa State University http://weeks.public.iastate.edu/ From owner-freebsd-fs@FreeBSD.ORG Wed May 13 20:40:26 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 143122B6; Wed, 13 May 2015 20:40:26 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90C3912A2; Wed, 13 May 2015 20:40:25 +0000 (UTC) Received: by laat2 with SMTP id t2so39980734laa.1; Wed, 13 May 2015 13:40:23 -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; bh=rR2YuZbVUobeq6pZH8bTI8EmJ+NHah7TcsHFeXwt7D8=; b=DyWCnBf8m9G+AZN8Z9zsqXCGNmR1Z+ATXyvuyWx0yPhNzzl10NGFW/0K6a07icrD8l WSkCncMRyz+JdhsVawe1eZH+WtXzOzPxob+KyHoQA2LsmD/+HnZjw/w76zbBh9WZH11l 6rVTSR/FDqvlLLOkCiMuP/EhJrDte5KsF60DETXLla313K8UCsYzkOpyoPX0X2Uv0IY/ OGPwB2tPaIcpxZ//XyDoHxMDpQ6xxdJVpaReiTKUkFgozIEnjig5c42beBun1mc8Mvbz 1Tjh+uv0oiu8cDVgOn6SRPIn1HqcZi2iNOC7nLt8Coi9qgpDZ09hYYTE7BG9uhdH7zvS xzeA== MIME-Version: 1.0 X-Received: by 10.112.161.226 with SMTP id xv2mr560742lbb.106.1431549623658; Wed, 13 May 2015 13:40:23 -0700 (PDT) Received: by 10.152.127.34 with HTTP; Wed, 13 May 2015 13:40:23 -0700 (PDT) In-Reply-To: <5553A92F.4080106@gmail.com> References: <41f6f1f6-a1c8-4819-af45-f3d291737f63@googlegroups.com> <5553A92F.4080106@gmail.com> Date: Wed, 13 May 2015 22:40:23 +0200 Message-ID: Subject: Re: exfatfsck 1.0.1 UTF-8 bug From: Tomek CEDRO To: Andrew Nayenko Cc: "exfat@googlegroups.com" , freebsd-bugs@freebsd.org, FreeBSD Filesystems , samm@os2.kiev.ua Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 20:40:26 -0000 On Wed, May 13, 2015 at 9:42 PM, Andrew Nayenko wrote: > Hi Tomasz, > Thanks for reporting the bug! No problem Andrew :-) >> ERROR: `0.indexGroups' real size does not equal to size (237568 != >> 419431). > > That's the actual problem. This is a USB drive where you've copied the > /Application folder under OS X, right? Which OS X version have you been > using? Yes, the drive is USB/Thunderbolt Lacie Rugged 2TB (using USB connection), MacOSX Yosemite 10.10.* (hard to tell exactly as several computers use it). >> ERROR: name is too long. >> BUG: failed to convert name to UTF-8. > > I believe this bug was fixed in 1.1. Unfortunately, FreeBSD port is > outdated. I've tried to contact the maintainer about a month ago without > success. Yes, I have also noticed that and reported to FreeBSD FS/BUGS mailing list and the maintainer. If there is no response I will try to verify and prepare an updated version :-) Thank you! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Wed May 13 21:13:41 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E770AECD for ; Wed, 13 May 2015 21:13:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D26661720 for ; Wed, 13 May 2015 21:13:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4DLDfhr005403 for ; Wed, 13 May 2015 21:13:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Wed, 13 May 2015 21:13:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: davor.cubranic@alumni.cs.ubc.ca X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:13:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189 Davor Cubranic changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |davor.cubranic@alumni.cs.ub | |c.ca --- Comment #14 from Davor Cubranic --- I tried running Vermaden's Perl script on a freshly installed 10.1-RELEASE on a ThinkPad 430s with 8GB RAM and a 2G swap zvol on an SSD with no tuning whatsoever. I experienced no lockups: the script was killed after about a minute and I barely even saw any slowdown in the interactive console. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu May 14 13:24:27 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09B01E6F; Thu, 14 May 2015 13:24:27 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B3D8C1913; Thu, 14 May 2015 13:24:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CmBABVoVRV/95baINchEeDGMFYhHuCUwKBdxIBAQEBAQEBgQqEIwEBBCNWGxgRGQIEVQaIP7AYpDYBAQEBAQEBAwEBAQEBAQEBGos6hDoXGRsHgmiBRQWUap9hI2GBKByBbiKBdoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,427,1427774400"; d="scan'208";a="210739343" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 14 May 2015 09:24:25 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id AD5F3B3FD4; Thu, 14 May 2015 09:24:25 -0400 (EDT) Date: Thu, 14 May 2015 09:24:25 -0400 (EDT) From: Rick Macklem To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= Cc: FreeBSD Filesystems Message-ID: <1693868675.37887047.1431609865698.JavaMail.root@uoguelph.ca> In-Reply-To: <20150512074602.GA93864@brick.home> Subject: Re: RFC: should automounted file systems be exportable? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_37887045_646449297.1431609865694" X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:24:27 -0000 ------=_Part_37887045_646449297.1431609865694 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Edward Tomasz Napierala wrote: > On 0511T2217, Rick Macklem wrote: > > A recent bug was reported related to mountd and the > > "automounted" flag. > > > > Loosely related to this is the question... > > Should automounted file systems be exportable? > > > > I haven't tested it, but I suspect that it would be > > broken and the NFS server will reply NFSERR_STALE > > after the file system has been dismounted. > > > > So, should I patch mountd so that it won't export > > automounted file systems? > > Exporting an automounted filesystem doesn't seem to make much sense, > I agree, but I'm not sure if adding code to prevent it is such > a good idea. If the user asks for it, by putting it into exports(5), > it's his fault; the only thing this code could add would be a more > friendly error message. > > So, how about having mountd generate a warning message in syslog(), but allow it to proceed? (Untested patch for this is attached.) rick ps: One other person emailed me suggesting that it should be doable and no one emailed that it should be restricted, so I figure that the "vote" favours a warning. ------=_Part_37887045_646449297.1431609865694 Content-Type: text/x-patch; name=mountd-automount.patch Content-Disposition: attachment; filename=mountd-automount.patch Content-Transfer-Encoding: base64 LS0tIG1vdW50ZC5jLm9yaWcJMjAxNS0wNS0wOSAyMjowNDoxNS4wMDAwMDAwMDAgLTA0MDAKKysr IG1vdW50ZC5jCTIwMTUtMDUtMTQgMDk6MTg6MDEuMDAwMDAwMDAwIC0wNDAwCkBAIC0xNDEwLDYg KzE0MTAsOSBAQCBnZXRfZXhwb3J0bGlzdF9vbmUodm9pZCkKIAkJCSAgICB9CiAJCQkgICAgaWYg KGNoZWNrX2RpcnBhdGgoY3ApICYmCiAJCQkJc3RhdGZzKGNwLCAmZnNiKSA+PSAwKSB7CisJCQkJ aWYgKChmc2IuZl9mbGFncyAmIE1OVF9BVVRPTU9VTlRFRCkgIT0gMCkKKwkJCQkgICAgc3lzbG9n KExPR19FUlIsICJXYXJuaW5nOiBleHBvcnRpbmcgb2YgIgorCQkJCQkiYXV0b21vdW50ZWQgZnMg JXMgbm90IHN1cHBvcnRlZCIsIGNwKTsKIAkJCQlpZiAoZ290X25vbmRpcikgewogCQkJCSAgICBz eXNsb2coTE9HX0VSUiwgImRpcnMgbXVzdCBiZSBmaXJzdCIpOwogCQkJCSAgICBnZXRleHBfZXJy KGVwLCB0Z3JwKTsK ------=_Part_37887045_646449297.1431609865694-- From owner-freebsd-fs@FreeBSD.ORG Thu May 14 13:42:28 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4CEF4E7 for ; Thu, 14 May 2015 13:42:28 +0000 (UTC) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 818EE1B96 for ; Thu, 14 May 2015 13:42:28 +0000 (UTC) Received: by qkgy4 with SMTP id y4so49276377qkg.2 for ; Thu, 14 May 2015 06:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=eT/rfuBFs8oStKTqYFEXqeuYLjzK+EscJ1ouKDy9A+A=; b=ZQr3AB8GQnkprO8ZSkWlQnIdBzsDGuCi+LX5JOsMRtRr/kGLgkbSAQ1nYAb3QauINN TpVYwFtErjsaaigV/su15jXxInPGwyo/TZlhUns8g3DN6xXak4HyEFBCwcFs0rRGMQ7R iMIDckHYfHhtrlruYNTAIg13nUnD3mLOJQJ8R8XMLE5wjg/95jDIgU98jAP7kms7CvLV VIPI5FMY4HBIfeX0LeLvUQnbynkxnM/Dbxo5sUW/uso1fw9S185FXs+tzzBplYRTk3q3 soAeDoXfjLPEfCeTqt5TlNMWobgv5EAb8KXRB6w2EKWr59enbPEZ2ut4p8zDMh12UJk0 /9cQ== X-Received: by 10.55.15.129 with SMTP id 1mr9080683qkp.29.1431610947739; Thu, 14 May 2015 06:42:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.96.118 with HTTP; Thu, 14 May 2015 06:42:07 -0700 (PDT) From: Gabor Radnai Date: Thu, 14 May 2015 15:42:07 +0200 Message-ID: Subject: Re: ZFS RAID 10 capacity expansion and uneven data distribution To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:42:28 -0000 Hi Kai, As others pointed out the cleanest way is to destroy / recreate your pool from backup. Though if you have no backup a hackish, in-place recreation process can be the following. But please be *WARNED* it is your data, the recommended solution is to use backup, if you follow below process it is your call - it may work but I cannot guarantee. You can have power outage, disk outage, sky falling down, whatever and you may lose your data. And this may not even work - more skilled readers could bit me on head how stupid this is. So, again be warned. If you are still interested: > On one server I am currently using a four disk RAID 10 zpool: > > zpool ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/zpool-da2 ONLINE 0 0 0 > gpt/zpool-da3 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/zpool-da4 ONLINE 0 0 0 > gpt/zpool-da5 ONLINE 0 0 0 1. zpool split zpool zpool.old this will leave your current zpool composed from slice of da2 and da4, and create a new pool from da3 and da5. 2. zpool destroy zpool 3. truncate -s /tmp/dummy.1 && truncate -s /tmp/dummy.2 4. zpool create zpool mirror da2 /tmp/dummy.1 mirror da4 /tmp/dummy.2 5. zpool zpool offline /tmp/dummy.1 & zpool offline /tmp/dummy.2 6. zpool import zpool.old 7. (zfs create ... on zpool as needed) copy your stuff from zpool.old to zpool 8. cross your fingers, *no* return from here !! 9. zpool destroy zpool.old 10. zpool labelclear da3 && zpool labelclear da5 # just to be on clear side 11. zpool replace zpool /tmp/dummy.1 da3 && zpool replace zpool /tmp/dummy.2 da5 12. wait for resilver ... If this is total sh*t please ignore, i tried it in VM seemed to work. Thanks. From owner-freebsd-fs@FreeBSD.ORG Thu May 14 14:10:30 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C46653B5 for ; Thu, 14 May 2015 14:10:30 +0000 (UTC) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C74F1F05 for ; Thu, 14 May 2015 14:10:30 +0000 (UTC) Received: from [193.68.6.125] ([193.68.6.125]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.9/8.14.9) with ESMTP id t4EDxKjW071178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 16:59:20 +0300 (EEST) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: ZFS RAID 10 capacity expansion and uneven data distribution From: Daniel Kalchev In-Reply-To: Date: Thu, 14 May 2015 16:59:20 +0300 Cc: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Gabor Radnai X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:10:31 -0000 Not a total bs, but.. it could be made simpler/safer. skip 2,3,4 and 5 7a. zfs snapshot -r zpool.old@send 7b. zfs send -R zpool.old@send | zfs receive -F zpool do not skip 8 :) 11. zpool attach zpool da1 da2 && zpool attach zpool da3 da4 Everywhere in the instruction where it says daX replace with = gpt/zpool-daX as in the original config. After this operation, you should have the exact same zpool, with evenly = redistributed data. You could use the chance to change ashift etc. = Sadly, this works only for mirrors. Important to understand that since the first step you have an = non-redundant pool. It=E2=80=99s very reasonable to do a scrub before = starting this process and of course have usable backup. Daniel > On 14.05.2015 =D0=B3., at 16:42, Gabor Radnai = wrote: >=20 > Hi Kai, >=20 > As others pointed out the cleanest way is to destroy / recreate your = pool > from backup. >=20 > Though if you have no backup a hackish, in-place recreation process = can be > the following. > But please be *WARNED* it is your data, the recommended solution is to = use > backup, > if you follow below process it is your call - it may work but I cannot > guarantee. You can > have power outage, disk outage, sky falling down, whatever and you may = lose > your data. > And this may not even work - more skilled readers could bit me on head = how > stupid this is. >=20 > So, again be warned. >=20 > If you are still interested: >=20 >> On one server I am currently using a four disk RAID 10 zpool: >>=20 >> zpool ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> gpt/zpool-da2 ONLINE 0 0 0 >> gpt/zpool-da3 ONLINE 0 0 0 >> mirror-1 ONLINE 0 0 0 >> gpt/zpool-da4 ONLINE 0 0 0 >> gpt/zpool-da5 ONLINE 0 0 0 >=20 >=20 > 1. zpool split zpool zpool.old > this will leave your current zpool composed from slice of da2 and da4, = and > create a new pool from da3 and da5. > 2. zpool destroy zpool > 3. truncate -s /tmp/dummy.1 && truncate -s > /tmp/dummy.2 > 4. zpool create zpool mirror da2 /tmp/dummy.1 mirror da4 > /tmp/dummy.2 > 5. zpool zpool offline /tmp/dummy.1 & zpool offline /tmp/dummy.2 > 6. zpool import zpool.old > 7. (zfs create ... on zpool as needed) copy your stuff from zpool.old = to > zpool > 8. cross your fingers, *no* return from here !! > 9. zpool destroy zpool.old > 10. zpool labelclear da3 && zpool labelclear da5 # just to be on clear = side > 11. zpool replace zpool /tmp/dummy.1 da3 && zpool replace zpool > /tmp/dummy.2 da5 > 12. wait for resilver ... >=20 > If this is total sh*t please ignore, i tried it in VM seemed to work. >=20 > 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" From owner-freebsd-fs@FreeBSD.ORG Thu May 14 14:40:16 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B5CAE5B for ; Thu, 14 May 2015 14:40:16 +0000 (UTC) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A00C12CA for ; Thu, 14 May 2015 14:40:16 +0000 (UTC) Received: by qkgw4 with SMTP id w4so10254850qkg.3 for ; Thu, 14 May 2015 07:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=f2OT7sNIqBT5xN4vahqtgmXgqMCEo7d5Mxz1HWlCKEU=; b=MOyORI4w4qyNTSf/UJOCJaWBIIO4VGr/WZfincT9+vmMlk2mwcLtovz7hr8R3h1W3e 4+brOokTBWKalqr+T9Akid2VSpDCVgIlYYAm4xc/zYdC7+TSfNXkbXkhH1FaMTfxsiRt +u7Kh+7wjjiIlfkeMvdLL3z+ADnX6vabTIjbcMXfQJesXkMdSHl359uG1aQGgfrOlbJ1 Ffp6YnnurvBncCe97EeOh9HdnRirM4NRTVibQN+rrXHPtNMzO0U/foClD1QF05IwF68N ztmtq0jkIzKBFMQdYluNNm3ux5vCuO3K2CbP9XuigCb22GPcoWYZl6nMHF5YZ3mfa1VQ R4Mg== X-Received: by 10.140.150.143 with SMTP id 137mr6220956qhw.0.1431614415410; Thu, 14 May 2015 07:40:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.96.118 with HTTP; Thu, 14 May 2015 07:39:55 -0700 (PDT) From: Gabor Radnai Date: Thu, 14 May 2015 16:39:55 +0200 Message-ID: Subject: Re: ZFS RAID 10 capacity expansion and uneven data distribution To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:40:16 -0000 Thanks for the improved version :-) Indeed looks better. From owner-freebsd-fs@FreeBSD.ORG Thu May 14 19:29:30 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16AE2811; Thu, 14 May 2015 19:29:30 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6CA51791; Thu, 14 May 2015 19:29:29 +0000 (UTC) Received: by lagr1 with SMTP id r1so1529944lag.0; Thu, 14 May 2015 12:29:27 -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=gde/G1CDs0qNVJW2PcZrxwoReuiY/T3Ozz5sNquKzLY=; b=Xgksxne9p/CJ7wHZkO2tC8CChYH+Ie4KFRDOk7cgDC4X5Ma8K8Hhb/Hz0WbMhgud1g XxSTbxxpX35InjnpNskEIJibW3O37X9HtIUyB0RCDvtq3PtGMQ/MNCQGzmom24F5rtkV 6Y/UQZJ57qlEtzkryBnr77AQ/Yw3H9GZF3+TipCMKbbkyjPO9/kZRZF7lANVEbnO9B+1 AC9hzATiUIovznx7KoGvHXsaI6b/z3WiIPCtGWNHGWP9parVMqTLeMUkihzUj0VsTPvo T23G1oRFChVKgXaISLQ66glorQwHXU+7SP6ctpiELUylUvINz+4SHRExvM65uc1sBHdD SWgQ== X-Received: by 10.112.83.135 with SMTP id q7mr4429097lby.13.1431631767558; Thu, 14 May 2015 12:29:27 -0700 (PDT) Received: from buran.kosmos (host-87-255-31-13.bigtelecom.ru. [87.255.31.13]) by mx.google.com with ESMTPSA id uj9sm6402039lbb.38.2015.05.14.12.29.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 12:29:26 -0700 (PDT) Message-ID: <5554F790.6010604@gmail.com> Date: Thu, 14 May 2015 22:29:20 +0300 From: Andrew Nayenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tomek CEDRO CC: "exfat@googlegroups.com" , freebsd-bugs@freebsd.org, FreeBSD Filesystems , samm@os2.kiev.ua Subject: Re: exfatfsck 1.0.1 UTF-8 bug References: <41f6f1f6-a1c8-4819-af45-f3d291737f63@googlegroups.com> <5553A92F.4080106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 19:29:30 -0000 >>> ERROR: `0.indexGroups' real size does not equal to size (237568 != >>> 419431). >> >> That's the actual problem. This is a USB drive where you've copied the >> /Application folder under OS X, right? Which OS X version have you been >> using? > > Yes, the drive is USB/Thunderbolt Lacie Rugged 2TB (using USB > connection), MacOSX Yosemite 10.10.* (hard to tell exactly as several > computers use it). I see. I relaxed this check in 1.1, so you just need to upgrade to the latest version of fuse-exfat and exfat-utils. Let me know whether they work for you. >>> ERROR: name is too long. >>> BUG: failed to convert name to UTF-8. >> >> I believe this bug was fixed in 1.1. Unfortunately, FreeBSD port is >> outdated. I've tried to contact the maintainer about a month ago without >> success. > > Yes, I have also noticed that and reported to FreeBSD FS/BUGS mailing > list and the maintainer. If there is no response I will try to verify > and prepare an updated version :-) This would be great! Please keep me informed. -- Andrew Nayenko From owner-freebsd-fs@FreeBSD.ORG Sat May 16 07:59:24 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 122D0E62 for ; Sat, 16 May 2015 07:59:24 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98F8D160B for ; Sat, 16 May 2015 07:59:23 +0000 (UTC) Received: by wibt6 with SMTP id t6so15810301wib.0 for ; Sat, 16 May 2015 00:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=xtRvjzNuVAn3D4qE4uL5DLFdqpFYMHHczJ3sPAoJwdw=; b=iAcFImPnJgeJpmK4sXX161DRLZzcd5pIVkZOBC/IBZ0hi2W3dvcCbaNx9ppXdYJ9W5 n7SgUPcNa9iUnxQRcXlbSXicJnnq3KcNLvMeZ9eceb8LpJVRcIcKYhFO/ijnJsjWQA0O mApmgpRe/MGQ2sXN2RCrf+AiOf0o9XfAbeUYVOlqFH0KCXL1AptetukE3KX+FHkReJZ4 QJNt3jYqbf+n35l7Bsq+Lf0SjR2F250oY5mPV8S8MiYqC+qi1EYCPmZI5SKtfbTlruQX 1RxjxKRdP4S9RSvF10noyLM1WBIn19HL0kGppDZtlcPaNB7LxEObVCkrIe2+pjZqFIBu 9oiA== X-Received: by 10.194.5.103 with SMTP id r7mr24890495wjr.47.1431763162174; Sat, 16 May 2015 00:59:22 -0700 (PDT) Received: from brick.home (aegz87.neoplus.adsl.tpnet.pl. [79.186.181.87]) by mx.google.com with ESMTPSA id hn7sm1751164wib.5.2015.05.16.00.59.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 00:59:21 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 16 May 2015 09:59:19 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Rick Macklem Cc: FreeBSD Filesystems Subject: nmount(2) vs 64 bit flags [Was: Re: RFC: should automounted file systems be exportable?] Message-ID: <20150516075919.GB4528@brick.home> Mail-Followup-To: Rick Macklem , FreeBSD Filesystems References: <20150512074602.GA93864@brick.home> <599930852.36285001.1431431429794.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <599930852.36285001.1431431429794.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 07:59:24 -0000 On 0512T0750, Rick Macklem wrote: > Edward Napierala wrote: > > On 0511T2217, Rick Macklem wrote: > > > A recent bug was reported related to mountd and the > > > "automounted" flag. > > > > > > Loosely related to this is the question... > > > Should automounted file systems be exportable? > > > > > > I haven't tested it, but I suspect that it would be > > > broken and the NFS server will reply NFSERR_STALE > > > after the file system has been dismounted. > > > > > > So, should I patch mountd so that it won't export > > > automounted file systems? > > > > Exporting an automounted filesystem doesn't seem to make much sense, > > I agree, but I'm not sure if adding code to prevent it is such > > a good idea. If the user asks for it, by putting it into exports(5), > > it's his fault; the only thing this code could add would be a more > > friendly error message. > > > > > Well, my thinking is that the recent patch to mountd that avoids > doing mount update for non-exported file systems + one that doesn't > allow automounted volumes to be exported fixes this bug: > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > That way, there is no rush w.r.t. how to update the high order > bits of flags. (As noted in the comment w.r.t. the review of D2506, > I'm not sure if an updated syscall is allowed to be MFC'd.) > Since MNT_AUTOMOUNTED is the only high order bit at this time, > once it is fixed, no MFC of the more generic fix is needed. > > Make sense? rick Yes. To sum this up: one approach of dealing with it would be to add a separate textual "flags" field (https://reviews.freebsd.org/D2506); another is extending the flags nmount(2) argument to uint64 (https://reviews.freebsd.org/D2524), and autors of both don't intend to bring either of them into the tree at this time, since the mountd problem was actually fixed earlier, by a simple mountd(8) change. To be honest, I wonder if we should just have an API to convert binary flags (as obtained from statfs) back to textual form (iov), and use that to ignore the 'flags' argument altogether and pass everything in textual form. Either way - let's leave it until it's actually needed. From owner-freebsd-fs@FreeBSD.ORG Sat May 16 12:36:00 2015 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CDF67E1; Sat, 16 May 2015 12:36:00 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 048111145; Sat, 16 May 2015 12:35:59 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 861BE16A403; Sat, 16 May 2015 14:35:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQhKGTKnIfJy; Sat, 16 May 2015 14:35:19 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:dc9e:d6c5:9f0d:6a43] (unknown [IPv6:2001:4cb8:3:1:dc9e:d6c5:9f0d:6a43]) by smtp.digiware.nl (Postfix) with ESMTPA id 11EF816A406; Sat, 16 May 2015 14:25:59 +0200 (CEST) Message-ID: <55573756.9070503@digiware.nl> Date: Sat, 16 May 2015 14:25:58 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: fs@freebsd.org, Edward Tomasz Napierala Subject: Unexpected reboot after ctld run into trouble. Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 12:36:00 -0000 Hi, Found the following in my logs: Losts of ---- (0:4:0/0): Task Action: LUN Reset (0:4:0/0): CTL Status: Command Completed Successfully sonewconn: pcb 0xfffff8004e69e930: Listen queue overflow: 8 already in queue awaiting acceptance (740688 occurrences) (0:4:0/0): Task Action: LUN Reset (0:4:0/0): CTL Status: Command Completed Successfully sonewconn: pcb 0xfffff8004e69e930: Listen queue overflow: 8 already in queue awaiting acceptance (713721 occurrences) (0:4:0/0): Task Action: LUN Reset (0:4:0/0): CTL Status: Command Completed Successfully sonewconn: pcb 0xfffff8004e69e930: Listen queue overflow: 8 already in queue awaiting acceptance (691776 occurrences) ---- Which then ends in: ---- panic: deadlkres: possible deadlock detected for 0xfffff8001ee94920, blocked for 1801009 ticks cpuid = 1 Uptime: 14d13h13m47s Dumping 7557 out of 8175 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%Table 'FACP' at 0xcfedbcf8 ---- The system is running ZFS with ZFS-on-root: FreeBSD zfs.digiware.nl 10.1-STABLE FreeBSD 10.1-STABLE #221 r282282: Fri May 1 06:51:41 CEST 2015 This could stem from the fact that I woke up my Win8 PC which has a iscsi volume mounted. It is used to store security cam captures on and does have somewhat bigger traffic on it. Suggestions or question to look at are welcom. --WjW I do have a core in /var/crash, but will need some guidance to retreive stuff from it.