From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 01:15:56 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9992C106564A for ; Sun, 10 Jul 2011 01:15:56 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id E6FCF8FC0C for ; Sun, 10 Jul 2011 01:15:55 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6A1FpPA015337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jul 2011 11:15:53 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p6A1FokP001283; Sun, 10 Jul 2011 11:15:50 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p6A1Fnt2001282; Sun, 10 Jul 2011 11:15:49 +1000 (EST) (envelope-from peter) Date: Sun, 10 Jul 2011 11:15:49 +1000 From: Peter Jeremy To: Rick van der Zwet Message-ID: <20110710011549.GA88534@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: fsck_ufs a 2TB partition with 256MB RAM stalls X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 01:15:56 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jul-07 15:57:52 +0200, Rick van der Zwet w= rote: >I want to build a file server with limited power usage, so I got >myself an ALIX alix2d13 which has 256MB DDR RAM. I connected a 2TB >USB2.0 disk to the alix2d13 to be used as storage. > >The file system gets corrupted due to power failure, which is likely >going to happen when running Solar Power in The Netherlands, I cannot >fix it anymore cause the fsck_ufs never to complete. This actually >makes sense as the recommendation [1] says ``1TB storage needs 1GB of >RAM for fsck_ufs''. The problem is that fsck allocates both per-CG and per-allocated-inode space (and possibly other space) so running fsck on a large UFS needs lots of RAM. I suspect you'll need to find an amd64 box to run the fsck on but you might be able to get the fsck to complete (very slowly) by adding plenty of swap (on another disk) and increasing kern.maxdsiz in loader.conf. >I can partition my disk in 16 parts of 128GB to work around the >matter, but I rather keep one large partition. That's probably the best solution but you could reduce the need to run fsck by: - Arrange an "about to run flat" warning from your battery to allow clean shutdown. - Use SU+J (the journal file should remove the need for fsck in almost all situations) - don't fsck on all unclean startups - soft-updates means that it's safe (or should be) to mount and continue to use a "dirty" FS - the downside is that you may be missing some free space. If you have ready access to an amd64 box, then a combination of the above may be workable. Note that if your disk loses power uncleanly, it's fairly important to disable the write-cache (or at least do some tests to verify that synchronous writes make it to the platter before being acknowledged). If synchronous writes aren't guaranteed to be on-disk then you can't rely on soft-updates, with or without journalling, and must do full fsck if the FS is unclean. --=20 Peter Jeremy --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4Y/UUACgkQ/opHv/APuIdWawCeKbGK3QMaaNeOvXuFAvcp3DIw /tMAoLbA0Ysm3qktV6tsJ1DdsayQBLJB =5Qb7 -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 04:38:35 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B770D1065672 for ; Sun, 10 Jul 2011 04:38:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 426658FC13 for ; Sun, 10 Jul 2011 04:38:34 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6A4cPTV008603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jul 2011 14:38:26 +1000 Date: Sun, 10 Jul 2011 14:38:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Jeremy In-Reply-To: <20110710011549.GA88534@server.vk2pj.dyndns.org> Message-ID: <20110710133025.V1039@besplex.bde.org> References: <20110710011549.GA88534@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org Subject: Re: fsck_ufs a 2TB partition with 256MB RAM stalls X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 04:38:35 -0000 On Sun, 10 Jul 2011, Peter Jeremy wrote: > On 2011-Jul-07 15:57:52 +0200, Rick van der Zwet wrote: >> I want to build a file server with limited power usage, so I got >> myself an ALIX alix2d13 which has 256MB DDR RAM. I connected a 2TB >> USB2.0 disk to the alix2d13 to be used as storage. >> >> The file system gets corrupted due to power failure, which is likely >> going to happen when running Solar Power in The Netherlands, I cannot >> fix it anymore cause the fsck_ufs never to complete. This actually >> makes sense as the recommendation [1] says ``1TB storage needs 1GB of >> RAM for fsck_ufs''. > > The problem is that fsck allocates both per-CG and per-allocated-inode > space (and possibly other space) so running fsck on a large UFS needs > lots of RAM. I suspect you'll need to find an amd64 box to run the > fsck on but you might be able to get the fsck to complete (very > slowly) by adding plenty of swap (on another disk) and increasing > kern.maxdsiz in loader.conf. This (and the inherent slowness of fscking an enormous number of CGs might be fixable by using a per-CG dirty flag. Each CG would become more like an independent file system, with most or all of the file systems effectively mounted read-only most of the time, so that most of them don't have to be looked at by fsck after a crash. Upgrades to read-write would be automatic and instant, while downgrades to read-only would be either automatic (in the kernel, after a timeout), or managed by an application. The dirty flags should be stored together and not in individual CGs (except as backups) so that examining them to determine what to fsck doesn't require reading all CGs. This should work well, since on a multi-TB disk, it is physically impossible to have more than a tiny proportion of the disk active at any one time. The proportion might be scattered over the whole disk and thus require too many "mounted" CGs, but that is bad for performance in other ways so should be avoided, and implementing this avoidance is relatively easy (just add a mild preference to use "mounted" CGs to existing preferences for the same and nearby CGs). The complications for independent sub-filesystems in CGs are similar but much smaller than ones for growing a filesystem by turning separate filesystems into sub-filesystems. I have little need for large file systems so I haven't tried implementing any of this. I just use a poor man's version with too many separate file systems so that each can be mounted read-only and backed up to small media independently. The automatic upgrade and downgrade would be useful even for this setup, since most of my small file systems are also rarely written to, but I have to mount half of them read-write all the time since it is too much work to manually upgrade and downgrade them. msdosfs's single dirty flag is a bit closer to working right than ffs's. msdosfs doesn't scribble timestamps on the super block for read-write mounts that never write any data. But non-scribbling on the super-block was broken when the dirty flag was implemented (very late, via bad bits from Apple) for msdosfs. Read-write mounts of msdosfs now scribble the dirty flag itself on the superblock, so after a crash a read-write mounted msdosfs filesystem is now considered dirty and has to be fscked, although for lightly used ones the only dirt on it is the flag that marks it as dirty. And this dirt even has bugs in it: msdosfs's superblock is actually its FAT; the dirty bit is in magic bytes at the start of the FAT; but msdosfs file systems normally have 2 FATs, and the dirty bit is not maintained properly in both of them, except accidentally if a real FAT entry near the start is changed -- then the second FAT is written to properly back up the real FAT entry, and this accidentally backs up the dirty bit entry so that fsck doesn't find the FATs to be inconsistent. (Perhaps fsck should only look at the dirty bit in the first copy. Nothing really cares about this, and only the simple comparision used in fsck notices the difference. I don't know if OtherOS's fscks notice this difference.) msdosfs also has a dynamic dirty flag (pm_fmod) which tracks changes to FAT metadata, but this is not really used and the addition of the dirty flag turned it it into nonsense. It is only used to panic when an assertion fails. Its useful use is only indicated in a comment. But the useful use never worked, since the flag is never downgraded to 0 (after making the FAT undirty by writing it), and setting the dirty flag made it further from working since pm_fmod is upgraded to 1 on every read-write mount. pm_fmod thus tracks !MNT_RDONLY and is useless. The corresponding flag in ffs (fs_fmod) which tracks changes to the superblock is useful and is used correctly. It is more needed since ffs scribbles timestamps and other metadata to the superblock and depends on delayed updates to write these to the disk. Clearing the flag on every superblock update prevents doing writes of null changes on every sync(). Maintaining a dynamic per-filesystem dirty flag is only slightly more complicated than maintaining this superblock dirty flag. It just has to track dirtyness for all data as well as superblock metadata. Bruce From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 12:26:24 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 187D1106564A; Sun, 10 Jul 2011 12:26:24 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3AC8FC12; Sun, 10 Jul 2011 12:26:23 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 02DF71CBA5; Sun, 10 Jul 2011 14:26:22 +0200 (CEST) Received: by cruwe.de (Postfix, from userid 65534) id D2E211CBA4; Sun, 10 Jul 2011 14:26:21 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37B008.dip.t-dialin.net [91.55.176.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id 55C901CB94; Sun, 10 Jul 2011 14:26:19 +0200 (CEST) Date: Sun, 10 Jul 2011 14:26:17 +0200 From: "Christopher J. Ruwe" To: freebsd-questions@freebsd.org Message-ID: <20110710142617.1d80289b@dijkstra> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/ICitDr9IVUgfV8mY8Yu1fTF" X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Cc: freebsd-fs@freebsd.org Subject: Fw: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 12:26:24 -0000 --MP_/ICitDr9IVUgfV8mY8Yu1fTF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Nearly a week ago I posted this question to freebsd-fs, but probalby my question is a) worded too complicatedly, b) not really a filesystem-issue or c) both. To rephrase: In setups requiring one or more ZFS-dataset to be mounted before another service is activated (GELI in my case) and the rest of the ZFS-datasets after that service is activated (because they require GELI), it seems to be necessary to add a `zfs mount -a` to mountcritlocal. Is this considered correct behaviour and wouldn't it make sense to add such a line to mountcritlocal in the standard setup? Thank you, cheers, -- Christopher J. Ruwe TZ GMT + 2 Begin forwarded message: Date: Tue, 5 Jul 2011 20:59:48 +0200 From: "Christopher J. Ruwe" To: Subject: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] I run my notebook under FreeBSD 8.2-stable, r223699. I have setup my disks with ZFS so that I boot from a very small rpool and mount datasets, among these /usr from another pool configured on top of an AES encrypted GELI. When installing a new world using this setup, it is necessary to manually adapt /etc/rc.d/mountcritlocal, mountcritlocal_start() to do a zfs mount -a. Failing to do so causes my rootpool to be mounted (which follows from rc.conf), then the GELI volume to be unlocked. After this, the boot routine hangs, as /usr (which resides) on the encrypted vol, which is not mounted, as the canonical zfs mounts are mounted before GELI. I cannot imagine that I am the only one to run ZFSes on an encrypted GELI volume. Am I booting this setup in an inadvisable way, so that I need to run into problems? If not, then it might be an idea to include a zfs mount -a in mountcritlocal in the canonical rc.d-setup. Am I getting this right or could you please comment? Thank you, cheers, -- Christopher J. Ruwe TZ GMT + 2 --MP_/ICitDr9IVUgfV8mY8Yu1fTF Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=zfs-mountcritlocal.patch *** /usr/src/etc/rc.d/mountcritlocal 2011-06-30 21:37:46.097575355 +0200 --- /etc/rc.d/mountcritlocal 2011-07-01 18:03:43.518493334 +0200 *************** *** 36,41 **** --- 36,42 ---- done mount_excludes=${mount_excludes%,} mount -a -t ${mount_excludes} + zfs mount -a err=$? check_startmsgs && echo '.' --MP_/ICitDr9IVUgfV8mY8Yu1fTF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit _______________________________________________ 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" --MP_/ICitDr9IVUgfV8mY8Yu1fTF-- From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 12:39:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD729106564A; Sun, 10 Jul 2011 12:39:06 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCCC8FC14; Sun, 10 Jul 2011 12:39:06 +0000 (UTC) Received: by wyg24 with SMTP id 24so2900777wyg.13 for ; Sun, 10 Jul 2011 05:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=K6ZWom27UxxE9/156jZ21uJPCJIimiHT9MWPfQ33cYc=; b=HC2srUTDgrNF9iB55T8IzcbZ2llDEBlBNBZW6Trzipr2bSBPzwaMxGgVcNXYqDScy9 PYtBFobWhK8DJYWB1Gb5BwHsvYpm42BOVnm3uc8uuzPiVv9w4D3I+eeEFCPuiUxar9BV EcTzgCz2dX2Fmp6C5MDkJeaU6Nh7qLKmWnSMA= Received: by 10.216.231.165 with SMTP id l37mr3163591weq.78.1310301545061; Sun, 10 Jul 2011 05:39:05 -0700 (PDT) Received: from localhost (tor6.anonymizer.ccc.de [80.237.226.76]) by mx.google.com with ESMTPS id k43sm2487692wed.33.2011.07.10.05.38.59 (version=SSLv3 cipher=OTHER); Sun, 10 Jul 2011 05:39:02 -0700 (PDT) From: Pan Tsu To: "Christopher J. Ruwe" References: <20110710142617.1d80289b@dijkstra> Date: Sun, 10 Jul 2011 16:38:43 +0400 In-Reply-To: <20110710142617.1d80289b@dijkstra> (Christopher J. Ruwe's message of "Sun, 10 Jul 2011 14:26:17 +0200") Message-ID: <86mxgmjooc.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Fw: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 12:39:07 -0000 "Christopher J. Ruwe" writes: > Nearly a week ago I posted this question to freebsd-fs, but probalby my > question is a) worded too complicatedly, b) not really a > filesystem-issue or c) both. > > To rephrase: In setups requiring one or more ZFS-dataset to be mounted > before another service is activated (GELI in my case) and the rest of > the ZFS-datasets after that service is activated (because they require > GELI), it seems to be necessary to add a `zfs mount -a` to > mountcritlocal. Is this considered correct behaviour and wouldn't it > make sense to add such a line to mountcritlocal in the standard setup? [...] Have you tried to set zfs_enable=YES in rc.conf? Based on rcorder(8) output rc.d/zfs should come just after rc.d/mountcritlocal. From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 14:05:16 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1A931065672; Sun, 10 Jul 2011 14:05:16 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5AFBA8FC42; Sun, 10 Jul 2011 14:05:16 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 30E351CE76; Sun, 10 Jul 2011 16:05:15 +0200 (CEST) Received: by cruwe.de (Postfix, from userid 65534) id 0D2B31CE70; Sun, 10 Jul 2011 16:05:15 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37B008.dip.t-dialin.net [91.55.176.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id 97DE21CE5E; Sun, 10 Jul 2011 16:05:12 +0200 (CEST) Date: Sun, 10 Jul 2011 16:05:04 +0200 From: "Christopher J. Ruwe" To: Pan Tsu Message-ID: <20110710160504.0d4bf4c0@dijkstra> In-Reply-To: <86mxgmjooc.fsf@gmail.com> References: <20110710142617.1d80289b@dijkstra> <86mxgmjooc.fsf@gmail.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/g_=5Uw8m_5L.Z.3xp0eX_.p"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 14:05:17 -0000 --Sig_/g_=5Uw8m_5L.Z.3xp0eX_.p Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 10 Jul 2011 16:38:43 +0400 Pan Tsu wrote: > "Christopher J. Ruwe" writes: >=20 > > Nearly a week ago I posted this question to freebsd-fs, but > > probalby my question is a) worded too complicatedly, b) not really a > > filesystem-issue or c) both. > > > > To rephrase: In setups requiring one or more ZFS-dataset to be > > mounted before another service is activated (GELI in my case) and > > the rest of the ZFS-datasets after that service is activated > > (because they require GELI), it seems to be necessary to add a `zfs > > mount -a` to mountcritlocal. Is this considered correct behaviour > > and wouldn't it make sense to add such a line to mountcritlocal in > > the standard setup? > [...] >=20 > Have you tried to set zfs_enable=3DYES in rc.conf? Based on rcorder(8) > output rc.d/zfs should come just after rc.d/mountcritlocal. zfs_enable=3D"YES" is set. rcorder gives curious output, so maybe my etcs a= re wrong? $> rcorder /etc/rc.d/zfs rcorder: file `/etc/rc.d/zfs' is before unknown provision `mountlate' /etc/rc.d/zfs $> rcorder /etc/rc.d/mountcritlocal rcorder: requirement `root' in file `/etc/rc.d/mountcritlocal' has no provi= ders. /etc/rc.d/mountcritlocal However, I fear I have not made my intent clear. My boot-sequence should be= as follows (intermittent steps left out): 1) mount zfs root-fs, which is on plain standard zpool A 2) unlock another, GELI-encrypted zpool B 3) mount all other fs (/usr,...), which reside on zpool B What my system does is first to mount the fs on zpool A, then GELI-unlock a= nd then halt because the contents of /usr are not accessible (yet) What I want my system to do is to first mount root, then unlock GELI and t= hen mount all other remaining fs on zpool B. I could either mount all remaining zfs'es in mountcritlocal, which requires another line there, which I have added locally as put in my patch. I cannot shift the order so that GELI-unlock comes first, because my keys for GELI reside on /boot, which resides on zpool A. So, is my setup anything from unfortunate to plain stupid or is mountcritlocal missing a statement catering for such cases as I described? Thank you for your help, cheers, --=20 Christopher J. Ruwe TZ GMT + 2 --Sig_/g_=5Uw8m_5L.Z.3xp0eX_.p Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJOGbGVAAoJEJTIKW/o3iwUPjQQANILgykncBQ0VL85din/a3HY veGlmpfVWM2I+lebeOwLEU3EJx93+T8mMbEQp0btz7J1Jd8Guf+2BeBJ1IZMkIYC qR/foBnBH5LQYUP8BLjozXB9Y2KgmekTDqQqTImUuDMXOlfi0HGQatGviUYRB3fy zjohMsK42VIQtG1x9UAkDpCe8K5NkFB2OrQ6zGVYiIoT68O89C/skKCa2g4KL4bi +QeaG5ShqeRNiiowPUsaTW0PVXuscg2r0GTKD6Y0ZWzwEAhm0pSojR9W6IshwTws 59hlHYjv0TeiYRDhuTP8nhSpkmVWAO4qqyPh0cSsvd3Ot8M7drIwIzeivAA81x98 J88K70rP/QWBCbpwsZcPFAIIQdURBvgn6T7OiTm0nDzWr2+JX+RjNVj3FPehxCNA xAEvREkEFb61jPkTue6Bb4HC47aAkhpowgegWFUdRGskRhmpFjZ+hnht6oL9a1xp nEf+mxnieL3eCa5U/4RtuX2ZtciBOuL9/Se/1Zk+nwsKGAnZsu7we8pNYrqysBER eUpX6yqERUWW2yLHPYbvQYFw4GeJwId7jf9bm+xx7dR5nFGJ5/lgsLCLKAEP4zVQ vQnAI3dHYawrz1+Dshh5XLWnk9dYnbJOr2jZuuXc7KkKydG8I/oNmLj5yLP+79g0 iNuDBw6DepWIDELEKVUL =bSSb -----END PGP SIGNATURE----- --Sig_/g_=5Uw8m_5L.Z.3xp0eX_.p-- From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 14:50:46 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 543E51065670 for ; Sun, 10 Jul 2011 14:50:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB318FC16 for ; Sun, 10 Jul 2011 14:50:45 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 6Eq91h0050QkzPwA1Eqjrn; Sun, 10 Jul 2011 14:50:43 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta02.emeryville.ca.mail.comcast.net with comcast id 6Eqi1h00r1t3BNj8NEqi0J; Sun, 10 Jul 2011 14:50:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8ACF8102C36; Sun, 10 Jul 2011 07:50:44 -0700 (PDT) Date: Sun, 10 Jul 2011 07:50:44 -0700 From: Jeremy Chadwick To: "Christopher J. Ruwe" Message-ID: <20110710145044.GA94832@icarus.home.lan> References: <20110710142617.1d80289b@dijkstra> <86mxgmjooc.fsf@gmail.com> <20110710160504.0d4bf4c0@dijkstra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110710160504.0d4bf4c0@dijkstra> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, Pan Tsu Subject: Re: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 14:50:46 -0000 On Sun, Jul 10, 2011 at 04:05:04PM +0200, Christopher J. Ruwe wrote: > On Sun, 10 Jul 2011 16:38:43 +0400 > Pan Tsu wrote: > > > "Christopher J. Ruwe" writes: > > > > > Nearly a week ago I posted this question to freebsd-fs, but > > > probalby my question is a) worded too complicatedly, b) not really a > > > filesystem-issue or c) both. > > > > > > To rephrase: In setups requiring one or more ZFS-dataset to be > > > mounted before another service is activated (GELI in my case) and > > > the rest of the ZFS-datasets after that service is activated > > > (because they require GELI), it seems to be necessary to add a `zfs > > > mount -a` to mountcritlocal. Is this considered correct behaviour > > > and wouldn't it make sense to add such a line to mountcritlocal in > > > the standard setup? > > [...] > > > > Have you tried to set zfs_enable=YES in rc.conf? Based on rcorder(8) > > output rc.d/zfs should come just after rc.d/mountcritlocal. > > zfs_enable="YES" is set. rcorder gives curious output, so maybe my etcs are wrong? > > $> rcorder /etc/rc.d/zfs > rcorder: file `/etc/rc.d/zfs' is before unknown provision `mountlate' > /etc/rc.d/zfs > > $> rcorder /etc/rc.d/mountcritlocal > rcorder: requirement `root' in file `/etc/rc.d/mountcritlocal' has no providers. > /etc/rc.d/mountcritlocal You're using rcorder wrong here. "rcorder /etc/rc.d/*" will get you what you're looking for. Yes, literally an asterisk. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 15:20:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75CDE1065670; Sun, 10 Jul 2011 15:20:25 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5D68FC08; Sun, 10 Jul 2011 15:20:24 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 0369A1C123; Sun, 10 Jul 2011 17:20:24 +0200 (CEST) Received: by cruwe.de (Postfix, from userid 65534) id D35C31C121; Sun, 10 Jul 2011 17:20:23 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37B008.dip.t-dialin.net [91.55.176.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id DCB591C110; Sun, 10 Jul 2011 17:20:20 +0200 (CEST) Date: Sun, 10 Jul 2011 17:20:12 +0200 From: "Christopher J. Ruwe" To: freebsd@jdc.parodius.com Message-ID: <20110710172012.51fce47c@dijkstra> In-Reply-To: <20110710145044.GA94832@icarus.home.lan> References: <20110710142617.1d80289b@dijkstra> <86mxgmjooc.fsf@gmail.com> <20110710160504.0d4bf4c0@dijkstra> <20110710145044.GA94832@icarus.home.lan> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/A=OqQpayWJb/b1/olJpKxKn"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, inyaoo@gmail.com Subject: Re: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 15:20:25 -0000 --Sig_/A=OqQpayWJb/b1/olJpKxKn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 10 Jul 2011 07:50:44 -0700 Jeremy Chadwick wrote: > On Sun, Jul 10, 2011 at 04:05:04PM +0200, Christopher J. Ruwe wrote: > > On Sun, 10 Jul 2011 16:38:43 +0400 > > Pan Tsu wrote: > >=20 > > > "Christopher J. Ruwe" writes: > > >=20 > > > > Nearly a week ago I posted this question to freebsd-fs, but > > > > probalby my question is a) worded too complicatedly, b) not > > > > really a filesystem-issue or c) both. > > > > > > > > To rephrase: In setups requiring one or more ZFS-dataset to be > > > > mounted before another service is activated (GELI in my case) > > > > and the rest of the ZFS-datasets after that service is activated > > > > (because they require GELI), it seems to be necessary to add a > > > > `zfs mount -a` to mountcritlocal. Is this considered correct > > > > behaviour and wouldn't it make sense to add such a line to > > > > mountcritlocal in the standard setup? > > > [...] > > >=20 > > > Have you tried to set zfs_enable=3DYES in rc.conf? Based on > > > rcorder(8) output rc.d/zfs should come just after > > > rc.d/mountcritlocal. > >=20 > > zfs_enable=3D"YES" is set. rcorder gives curious output, so maybe my > > etcs are wrong? > >=20 > > $> rcorder /etc/rc.d/zfs > > rcorder: file `/etc/rc.d/zfs' is before unknown provision > > `mountlate' /etc/rc.d/zfs > >=20 > > $> rcorder /etc/rc.d/mountcritlocal > > rcorder: requirement `root' in file `/etc/rc.d/mountcritlocal' has > > no providers. /etc/rc.d/mountcritlocal >=20 > You're using rcorder wrong here. "rcorder /etc/rc.d/*" will get you > what you're looking for. Yes, literally an asterisk. >=20 I see. Thank you. That gives me (I skip the rest after mountcritlocal) /etc/rc.d/zvol /etc/rc.d/zfs /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/hostid_save /etc/rc.d/mdconfig /etc/rc.d/mountcritlocal This makes sense to me and reflects the order I assumed in my description. = The question remains, however, if my configuration is of any in {unusual, .= .., stupid} as I require first zfs mount of /, then GELI-unlock and then zf= s mount of {/usr,/usr/local, ...}. Anyhow, thanks for setting me up on the proper usage of rcorder. Cheers,=20 --=20 Christopher J. Ruwe TZ GMT + 2 --Sig_/A=OqQpayWJb/b1/olJpKxKn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJOGcMxAAoJEJTIKW/o3iwU9bQQAOPzESChzsRE/gJleQzaRm8P e7SGlvrJkix+2QlHq2GkS53Xm5A2jugEwzPoOfu7K0yNYUCFnGLDQAyCunR5OcQb xnB9ga1+XjlU6vilHjddOVeb0uv9nk3CJuTetSic9Br9puJYkLO3pLiO3pGv1Pur xiGhW1a2otKzkhI92eywURnovUo7vJ+ouwkhbubqqMmNkojY9E1zdlY9RJtXkbxZ mIOb97Ruio+YbrKWs1O36kWEJ0Djgmvh1CvpE5lgQVh9MJ2kzajHi8VotWBQVZSp 7vEhmfXH08eH9+jrju/m6qFj3e8RJVB7xI8i1B33o6iuoT3LBxP8Ke5AXXdHf6Pp KFt75DvuKYqCuytTargkP2NFosCwISCdy6C18q13hfy2Q5YWo7yl2bfvJctJKkn5 8uYow30HyvwLJYe9LjcdDC+l7XnOHTNfWpHyqYFHd2OO9FAqlD9PCeP6Ci2yEUg2 zRDaiJ7Th+f56hkN3e/GtfQJwK2Xp3uVyope5gsHpe6yjPBMxajAq+WjtomzAt6R EtU5P0sUHsnFBRid23dp1/tSoFZndTGg3MLBjyZUVMXraConIxwSVMxk8ec4qeAt p0keYtZ9lUkpfQXoTf7Lrj1kJF9YJtzrSzmyGw7cex55j6Y80OwQdVhhWEJ1/0TT gbHZF/Cnx+E37c8ALE+5 =uN0b -----END PGP SIGNATURE----- --Sig_/A=OqQpayWJb/b1/olJpKxKn-- From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 18:23:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B0021065740; Sun, 10 Jul 2011 18:23:45 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 181478FC08; Sun, 10 Jul 2011 18:23:44 +0000 (UTC) Received: by pvg11 with SMTP id 11so2871466pvg.13 for ; Sun, 10 Jul 2011 11:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=oDm9lpGPhUsnFIlGh9OqNvxdCcOlYu8DUyLxb42pycI=; b=QifAFVmPccDrPBmfCDKEDK8ooa6xub2auhvcn/4RA88WnUaTRcrEQw0eX+d94hVFoJ nuJdKZOKBSprClpyWbNv6Sj6WzFaeBhQlVSUNAUy6TrtMYX8MjXSff4BEOXdXIFSRJZN zOa8cXfGI0s460Z7JoOZIlmXxi6OnT4G0G09E= Received: by 10.68.12.101 with SMTP id x5mr6257290pbb.267.1310322224517; Sun, 10 Jul 2011 11:23:44 -0700 (PDT) Received: from localhost (tor-exit-router41-readme.formlessnetworking.net [199.48.147.41]) by mx.google.com with ESMTPS id x1sm7880502pbb.50.2011.07.10.11.23.41 (version=SSLv3 cipher=OTHER); Sun, 10 Jul 2011 11:23:43 -0700 (PDT) From: Pan Tsu To: "Christopher J. Ruwe" References: <20110710142617.1d80289b@dijkstra> <86mxgmjooc.fsf@gmail.com> <20110710160504.0d4bf4c0@dijkstra> <20110710145044.GA94832@icarus.home.lan> <20110710172012.51fce47c@dijkstra> Date: Sun, 10 Jul 2011 22:23:36 +0400 In-Reply-To: <20110710172012.51fce47c@dijkstra> (Christopher J. Ruwe's message of "Sun, 10 Jul 2011 17:20:12 +0200") Message-ID: <86tyauc7vb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 18:23:45 -0000 "Christopher J. Ruwe" writes: [...] > /etc/rc.d/zvol > /etc/rc.d/zfs > /etc/rc.d/dumpon > /etc/rc.d/ddb > /etc/rc.d/initrandom > /etc/rc.d/geli > /etc/rc.d/gbde > /etc/rc.d/encswap > /etc/rc.d/ccd > /etc/rc.d/swap1 > /etc/rc.d/fsck > /etc/rc.d/root > /etc/rc.d/hostid_save > /etc/rc.d/mdconfig > /etc/rc.d/mountcritlocal > > This makes sense to me and reflects the order I assumed in my > description. The question remains, however, if my configuration is of > any in {unusual, ..., stupid} as I require first zfs mount of /, then > GELI-unlock and then zfs mount of {/usr,/usr/local, ...}. Do you mount the root pool over smth else? Otherwise, root should be mounted by kernel before init(8) is started. And /etc/rc.d doesn't exist before root is mounted. I think the correct order is 0 vfs_mountroot* .. 2 rc.d/zvol (pre v28) .. 6 rc.d/geli .. 15 rc.d/mountcritlocal 16 rc.d/zfs where extra datasets from the root pool can be mounted via fstab at rc.d/mountcritlocal time. Not sure if you import geli pool during boot or not and leak its configuration via zpool.cache. > > Anyhow, thanks for setting me up on the proper usage of rcorder. From owner-freebsd-fs@FreeBSD.ORG Sun Jul 10 22:09:09 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C399F106566B; Sun, 10 Jul 2011 22:09:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 48EF1151D6D; Sun, 10 Jul 2011 22:08:58 +0000 (UTC) Message-ID: <4E1A22F9.6000305@FreeBSD.org> Date: Sun, 10 Jul 2011 15:08:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: "Christopher J. Ruwe" References: <20110710142617.1d80289b@dijkstra> <86mxgmjooc.fsf@gmail.com> <20110710160504.0d4bf4c0@dijkstra> In-Reply-To: <20110710160504.0d4bf4c0@dijkstra> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, Pan Tsu Subject: Re: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 22:09:09 -0000 On 07/10/2011 07:05, Christopher J. Ruwe wrote: > $> rcorder /etc/rc.d/zfs You want to use: service -r -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 05:14:54 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BE31065675 for ; Mon, 11 Jul 2011 05:14:54 +0000 (UTC) (envelope-from samueldotj@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF6D8FC08 for ; Mon, 11 Jul 2011 05:14:54 +0000 (UTC) Received: by eyg7 with SMTP id 7so1524639eyg.13 for ; Sun, 10 Jul 2011 22:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ClkawMt7a2tDdUbuV7yB5jgAOsSktfMM/xFqyayuVuc=; b=CLdlBE1V/HlsLcaSrjMIhc/7ByNG9vaj8CuwsPWHuZEBllBVu0yqkzpCZRgxUIR9zY hmrFaXuAfdMKiarhgDfggLGEpi8A8RA6jYQoekB3tAgLPJsCr9b+xL7ju3wuOokvXnQm oY+zmHQ/UHMQ2Pt4LK+OHDjXy6oHsqS+Az5GQ= MIME-Version: 1.0 Received: by 10.14.94.80 with SMTP id m56mr1292092eef.155.1310359721667; Sun, 10 Jul 2011 21:48:41 -0700 (PDT) Received: by 10.14.119.16 with HTTP; Sun, 10 Jul 2011 21:48:41 -0700 (PDT) Date: Mon, 11 Jul 2011 10:18:41 +0530 Message-ID: From: Sam To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FS Endianess X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 05:14:55 -0000 Hi, I am under the assumption that a Filesystem created on big endian machine cant be read on little endian machine and vice versa. However I am able to mount FAT formatted(on Windows PC) USB flash drive on FreeBSD(PowerPC - BigEndian) and able to view contents of a text file. I am not able to locate FS code where it does the byte conversion. Can somebody kindly point me the code? Or my assumption is wrong? Thanks Samuel From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 05:31:16 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A79A0106566B for ; Mon, 11 Jul 2011 05:31:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 534BB8FC0A for ; Mon, 11 Jul 2011 05:31:16 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward2.mail.yandex.net (Yandex) with ESMTP id 7B9AD12A10E4; Mon, 11 Jul 2011 09:31:14 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1310362274; bh=07EuOP1ukrYttZD9wMPyKCEEZEBKGF0vqw1ro77OOX8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=UTruUJIgBsEXWJmk0NebD+bGyes0hAw3SXsh6DvlWthEsykjBpmKdvLk7QW13/ccm T2SsM9Az1qkdg60Gjcr0EWcFkvlOo32BEoSRUOCfN/dqu7AZpxtbFDH1ZSXzqO7RWo sZ9fNQkFN2oIYRhoIIc0JdhY/tA2mPbPz89uWnlI= Received: from [127.0.0.1] (proxy.kirov.so-ups.ru [77.72.136.146]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id 3AE62649809A; Mon, 11 Jul 2011 09:31:14 +0400 (MSD) Message-ID: <4E1A8A8B.4020005@yandex.ru> Date: Mon, 11 Jul 2011 09:30:51 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Sam References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig70BB18F571F8E3506A283DC3" X-Yandex-Spam: 1 Cc: freebsd-fs@freebsd.org Subject: Re: FS Endianess X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 05:31:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig70BB18F571F8E3506A283DC3 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 11.07.2011 8:48, Sam wrote: > Hi, >=20 > I am under the assumption that a Filesystem created on big endian > machine cant be read on little endian machine and vice versa. However > I am able to mount FAT formatted(on Windows PC) USB flash drive on > FreeBSD(PowerPC - BigEndian) and able to view contents of a text file. > I am not able to locate FS code where it does the byte conversion. Can > somebody kindly point me the code? Or my assumption is wrong? [freebsd msdosfs]> pwd /usr/home/devel/freebsd/base/head/sys/fs/msdosfs [freebsd msdosfs]> grep -E '[0-9]+(dec|enc)' * bpb.h:#define getushort(x) le16dec(x) bpb.h:#define getulong(x) le32dec(x) bpb.h:#define putushort(p, v) le16enc(p, v) bpb.h:#define putulong(p, v) le32enc(p, v) --=20 WBR, Andrey V. Elsukov --------------enig70BB18F571F8E3506A283DC3 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.4.10 (MingW32) iQEcBAEBAgAGBQJOGoqaAAoJEAHF6gQQyKF6n+4H/3Ey+r6au6HOjIHXyxmyTqGh rxuo/zApM/GKKbDoES/0Oh11w4Eeb020eCH9JuhX9/SyF11rNCUce/1Jg/qIMCXe Zx7ripvm4Bf0lb2FhEFqKMG6oTdO37pTrQYR9BGaKJ9m5thV4bm3Np2kN9DmSscY qEmRmgAM5Ecrit/9g+WovOgtJeMRCQKWMYEB99eCswTJMxZ7roFmlo1OM12qFzuW tnOA9sDu7eFic75ViaGlPNNpxbIUtTVkpHk3iiqJs2lz/m6R0TJdIxEzRI6ds3W6 F3DcXVWCWMd+QC1V2pNi/2EqDpvmvvcSvs+OLDJyjaP5KCi3ZLFnJvHX1HtfkMo= =GuQv -----END PGP SIGNATURE----- --------------enig70BB18F571F8E3506A283DC3-- From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 06:23:08 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC93106566B for ; Mon, 11 Jul 2011 06:23:08 +0000 (UTC) (envelope-from samueldotj@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BBA1A8FC1C for ; Mon, 11 Jul 2011 06:23:07 +0000 (UTC) Received: by ewy1 with SMTP id 1so1556022ewy.13 for ; Sun, 10 Jul 2011 23:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qbLO+KAZDrggfgFREj6B0oVaaS2308a04iL4fy0opA4=; b=jLEzJAgVpdp+cmV6uqDhD9CY8onV3sFtD4SSCNiO7h5TkbzluRVtD6G6y4IYG4YK05 ztVlJ9GsVwPqaEhNeJnkdx7fShf72xaYQ8mMDkRbpXODk26SNU4crfd4frKq1NCiwN8o kJr67gy7vYzRruvhZEEwnuo0+9/fN+NtssREw= MIME-Version: 1.0 Received: by 10.14.0.69 with SMTP id 45mr1330747eea.123.1310365386508; Sun, 10 Jul 2011 23:23:06 -0700 (PDT) Received: by 10.14.119.16 with HTTP; Sun, 10 Jul 2011 23:23:06 -0700 (PDT) In-Reply-To: <4E1A8A8B.4020005@yandex.ru> References: <4E1A8A8B.4020005@yandex.ru> Date: Mon, 11 Jul 2011 11:53:06 +0530 Message-ID: From: Sam To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: FS Endianess X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 06:23:08 -0000 Thanks for the quick response. Samuel 2011/7/11 Andrey V. Elsukov : > On 11.07.2011 8:48, Sam wrote: >> Hi, >> >> I am under the assumption that a Filesystem created on big endian >> machine cant be read on little endian machine and vice versa. However >> I am able to mount FAT formatted(on Windows PC) USB flash drive on >> FreeBSD(PowerPC - BigEndian) and able to view contents of a text file. >> I am not able to locate FS code where it does the byte conversion. Can >> somebody kindly point me the code? Or my assumption is wrong? > > [freebsd msdosfs]> pwd > /usr/home/devel/freebsd/base/head/sys/fs/msdosfs > [freebsd msdosfs]> grep -E '[0-9]+(dec|enc)' * > bpb.h:#define =A0 getushort(x) =A0 =A0le16dec(x) > bpb.h:#define =A0 getulong(x) =A0 =A0 le32dec(x) > bpb.h:#define =A0 putushort(p, v) le16enc(p, v) > bpb.h:#define =A0 putulong(p, v) =A0le32enc(p, v) > > -- > WBR, Andrey V. Elsukov > > From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 07:41:44 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEB39106566B for ; Mon, 11 Jul 2011 07:41:44 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 452168FC18 for ; Mon, 11 Jul 2011 07:41:43 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6B7ferA021049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jul 2011 17:41:41 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p6B7fdua078601 for ; Mon, 11 Jul 2011 17:41:39 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p6B7fd27078600 for freebsd-fs@freebsd.org; Mon, 11 Jul 2011 17:41:39 +1000 (EST) (envelope-from peter) Date: Mon, 11 Jul 2011 17:41:39 +1000 From: Peter Jeremy To: freebsd-fs@freebsd.org Message-ID: <20110711074139.GA77617@server.vk2pj.dyndns.org> References: <1309793921.2618.YahooMailRC@web120016.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Are thumpers still interesting in 2011 ? (raidz3 on x4500 @ 3.0gbps ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 07:41:44 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jul-05 14:20:39 +0200, Ivan Voras wrote: >It's a bit outdated, but here are the plans for a do-it-yourself=20 >slightly scaled down Thumper-like server: > >http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-ch= eap-cloud-storage/ Note that that article doesn't address acoustic and vibration issues. There's plenty of evidence that disks are very sensitive to vibration - even at low levels, it will adversely impact performance. Designing a box to provide optimal throughput with 48 disks is going to need a lot more attention to vibration isolation and damping than is shown. --=20 Peter Jeremy --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4aqTMACgkQ/opHv/APuIfM9gCfT+ycQsfTKxThYDvMNywqK2zx V0AAnRp/Th26qAPyXe96F6yOXAeZ+Tuw =1ZNm -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 09:12:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0215B106566B for ; Mon, 11 Jul 2011 09:12:13 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id B606C8FC13 for ; Mon, 11 Jul 2011 09:12:12 +0000 (UTC) Received: by ywf7 with SMTP id 7so1757237ywf.13 for ; Mon, 11 Jul 2011 02:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L365KPdBqHc2XO8GXlN4PWdVnTWHap1nSZrgF/UMT7M=; b=SLBBnPwb8yIGbTZzUeAp7Iq9XqBtZ2K1p4Dq4zFYCPLNeWBxCfkKa9VFojJG2VB3ev fqt0tKv0Iywag++pNEoRz+gwyFnB8GuToz0DlIaeGwmryBlMIbmuy7PjSlGqw1qcHiQg UJijw9dTaZKgro+YZG4AkXsr7h/zfRZak08bI= MIME-Version: 1.0 Received: by 10.236.183.135 with SMTP id q7mr4659994yhm.480.1310375531806; Mon, 11 Jul 2011 02:12:11 -0700 (PDT) Received: by 10.236.110.14 with HTTP; Mon, 11 Jul 2011 02:12:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Jul 2011 10:12:11 +0100 Message-ID: From: krad To: Rick van der Zwet Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: fsck_ufs a 2TB partition with 256MB RAM stalls X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:12:13 -0000 On 7 July 2011 14:57, Rick van der Zwet wrote: > I want to build a file server with limited power usage, so I got > myself an ALIX alix2d13 which has 256MB DDR RAM. I connected a 2TB > USB2.0 disk to the alix2d13 to be used as storage. > > The file system gets corrupted due to power failure, which is likely > going to happen when running Solar Power in The Netherlands, I cannot > fix it anymore cause the fsck_ufs never to complete. This actually > makes sense as the recommendation [1] says ``1TB storage needs 1GB of > RAM for fsck_ufs''. > > I can partition my disk in 16 parts of 128GB to work around the > matter, but I rather keep one large partition. Any recommendations of > getting this solved or will the smaller partitions be my only friend? > > Br. /Rick > [1] > http://groups.google.com/group/lucky.freebsd.stable/msg/4f1dcc954ecb7392 > -- > http://rickvanderzwet.nl > _______________________________________________ > 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" > you could try soft updates + journaling. This would negate the need for fsck in nearly all cases. It would mean running CURRENT though. However it is quite stable at the moment and has been for some time, to the rewards might be worth the risk for you http://freebsd.stokely.org/2010/05/kirk-mckusick-on-journaling-soft.html From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 09:24:29 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 479B5106566B for ; Mon, 11 Jul 2011 09:24:29 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id E848A8FC14 for ; Mon, 11 Jul 2011 09:24:28 +0000 (UTC) Received: by gyf3 with SMTP id 3so1772878gyf.13 for ; Mon, 11 Jul 2011 02:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EKeCqItHqICh9A2Q/KxsNwnrU58PIE6/ZHQWYAVEHlg=; b=E0kmP7up0fUnR6Ab6nAlj9Yr7jyghKTWPI70140+L/U9OWnUJ9f96hULMMVh8lyo5R SfUQneb5tdRAMzu6F5Zyl+uaYNHXtwSS7BuU2DWl6lWeBEqsaKR1hTuGtwkSlrBTcWiG LRKBCsSurJnubVREF0ORyLx24cJDhGJnKGL0g= MIME-Version: 1.0 Received: by 10.236.184.202 with SMTP id s50mr5413670yhm.346.1310376268052; Mon, 11 Jul 2011 02:24:28 -0700 (PDT) Received: by 10.236.110.14 with HTTP; Mon, 11 Jul 2011 02:24:27 -0700 (PDT) In-Reply-To: References: <1309217450.43651.YahooMailRC@web120014.mail.ne1.yahoo.com> <20110628010822.GA41399@icarus.home.lan> <1309302840.88674.YahooMailRC@web120004.mail.ne1.yahoo.com> <20110628234723.GA63965@icarus.home.lan> Date: Mon, 11 Jul 2011 10:24:27 +0100 Message-ID: From: krad To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Improving old-fashioned UFS2 performance with lots of inodes... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:24:29 -0000 On 6 July 2011 11:34, Ivan Voras wrote: > On 29/06/2011 01:47, Jeremy Chadwick wrote: > > unfortunately, so for now we will use UFS2, and as I said ... it seems a >>> shame >>> that UFS2 cannot use system RAM for any good purpose... >>> >>> Or can it ? Anyone ? >>> >> >> Like I said: the only person (I know of) who could answer this would be >> Kirk McKusick. I'm not well-versed in the inner workings and design of >> filesystems; Kirk would be. I'm not sure who else "knows" UFS around >> here. >> > > UFS will use all your memory for caching, there's no known issues here. Of > course, you still need to read all this data in to be cached. > > As Jeremy said, even ZFS will not help you with huge file systems without > some work. You could read this: http://en.wikipedia.org/wiki/**Shardingand simply replace "databases" with "file systems" and "tables" with > "directories" :) > > > > ______________________________**_________________ > 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 > " > Sorry if i misread this but are you saying you are having memory issues with rsync? If so what version are you using? From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 09:38:21 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C74A1065673; Mon, 11 Jul 2011 09:38:21 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 229FC8FC08; Mon, 11 Jul 2011 09:38:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6B9cLel091923; Mon, 11 Jul 2011 09:38:21 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6B9cKbq091919; Mon, 11 Jul 2011 09:38:20 GMT (envelope-from ae) Date: Mon, 11 Jul 2011 09:38:20 GMT Message-Id: <201107110938.p6B9cKbq091919@freefall.freebsd.org> To: kamikaze@bsdforen.de, ae@FreeBSD.org, freebsd-fs@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/140134: [msdosfs] write and fsck destroy filesystem integrity X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:38:21 -0000 Synopsis: [msdosfs] write and fsck destroy filesystem integrity State-Changed-From-To: open->closed State-Changed-By: ae State-Changed-When: Mon Jul 11 09:35:23 UTC 2011 State-Changed-Why: The submitter has requested close this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=140134 From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 10:12:01 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD90C106566C for ; Mon, 11 Jul 2011 10:12:01 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87A5B8FC08 for ; Mon, 11 Jul 2011 10:12:01 +0000 (UTC) Received: by vxg33 with SMTP id 33so3520570vxg.13 for ; Mon, 11 Jul 2011 03:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eoPBnad0vFrrCoFjCdr2e97hk4kUQlJRSNyZgUG/jrI=; b=SO20DJl8XiojKP2XQJIR7JHWp3Jv7AJ+kssupUx7wkxRMNpASSLDY07QZ/QPQ19U/x CUGorkIDA8Ktn/EcP2AAYuL79EJYAAKjl7OkK8pF8qUdkft9W8kk10JbmtvLR3l6iXc6 vDJxB8RoL/ppoYGvxWqhjx+HXvszMevxAdbsc= MIME-Version: 1.0 Received: by 10.52.92.78 with SMTP id ck14mr5413890vdb.100.1310377727121; Mon, 11 Jul 2011 02:48:47 -0700 (PDT) Received: by 10.52.101.197 with HTTP; Mon, 11 Jul 2011 02:48:46 -0700 (PDT) In-Reply-To: <20110711074139.GA77617@server.vk2pj.dyndns.org> References: <1309793921.2618.YahooMailRC@web120016.mail.ne1.yahoo.com> <20110711074139.GA77617@server.vk2pj.dyndns.org> Date: Mon, 11 Jul 2011 10:48:46 +0100 Message-ID: From: Tom Evans To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Are thumpers still interesting in 2011 ? (raidz3 on x4500 @ 3.0gbps ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:12:01 -0000 On Mon, Jul 11, 2011 at 8:41 AM, Peter Jeremy wrote: > On 2011-Jul-05 14:20:39 +0200, Ivan Voras wrote: >>It's a bit outdated, but here are the plans for a do-it-yourself >>slightly scaled down Thumper-like server: >> >>http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-c= heap-cloud-storage/ > > Note that that article doesn't address acoustic and vibration issues. > There's plenty of evidence that disks are very sensitive to vibration > - even at low levels, it will adversely impact performance. =C2=A0Designi= ng > a box to provide optimal throughput with 48 disks is going to need a > lot more attention to vibration isolation and damping than is shown. > Apart from the paragraph where they mention that they use nylon standoffs to provide vibration dampening? Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 11:07:02 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07539106566B for ; Mon, 11 Jul 2011 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA61E8FC1D for ; Mon, 11 Jul 2011 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6BB71hd076978 for ; Mon, 11 Jul 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6BB714i076976 for freebsd-fs@FreeBSD.org; Mon, 11 Jul 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jul 2011 11:07:01 GMT Message-Id: <201107111107.p6BB714i076976@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 11:07:02 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157728 fs [zfs] zfs (v28) incremental receive may leave behind t o kern/157722 fs [geli] unable to newfs a geli encrypted partition o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156933 fs [zfs] ZFS receive after read on readonly=on filesystem o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156168 fs [nfs] [panic] Kernel panic under concurrent access ove o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small p kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs f kern/130133 fs [panic] [zfs] 'kmem_map too small' caused by make clea o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs f kern/127375 fs [zfs] If vm.kmem_size_max>"1073741823" then write spee o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi f kern/126703 fs [panic] [zfs] _mtx_lock_sleep: recursed on non-recursi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/120210 fs [zfs] [panic] reboot after panic: solaris assert: arc_ o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 232 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 12:03:36 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FA591065672 for ; Mon, 11 Jul 2011 12:03:36 +0000 (UTC) (envelope-from luke@digital-crocus.com) Received: from mail.digital-crocus.com (node2.digital-crocus.com [91.209.244.128]) by mx1.freebsd.org (Postfix) with ESMTP id E08268FC1A for ; Mon, 11 Jul 2011 12:03:35 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dkselector; d=hybrid-logic.co.uk; h=Received:Received:Subject:From:To:Cc:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Spam-Score:X-Digital-Crocus-Maillimit:X-Authenticated-Sender:X-Complaints:X-Admin:X-Abuse; b=k71EOFTqf+dKcop68bCCp3AcbEWDLVjqIFN4+VHHEdeSSiQkpHP4ESHkN0HVThp0d6rw395rglBTkOd+iocLr0b6OBUH5MB8YbbmXB7CxbTmEfzR05mxfT11pV/y/3Es; Received: from luke by mail.digital-crocus.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QgEbT-000MFb-Em for freebsd-fs@freebsd.org; Mon, 11 Jul 2011 12:24:43 +0100 Received: from vlan111.pact.srf.ac.uk ([193.37.225.200] helo=[10.0.111.134]) by mail.digital-crocus.com with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QgEbS-000MFM-P5; Mon, 11 Jul 2011 12:24:43 +0100 From: Luke Marsden To: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Jul 2011 12:25:41 +0100 Message-ID: <1310383541.30844.73.camel@behemoth> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Digital-Crocus-Maillimit: done X-Authenticated-Sender: luke X-Complaints: abuse@digital-crocus.com X-Admin: admin@digital-crocus.com X-Abuse: abuse@digital-crocus.com (Please include full headers in abuse reports) Cc: tech@hybrid-logic.co.uk Subject: ZFS bug in v28 - temporary clones are not automatically destroyed on error X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 12:03:36 -0000 Hi all, I'm experiencing this bug on mm's ZFS v28 image from 19.06.2011 r222557M: cannot destroy 'hpool/hcfs/fs@snapshot': dataset already exists That is on a v4 formatted zfs filesystem on a v28 formatted pool, if I zfs upgrade the filesystem to v5 the error changes to "snapshot has dependent clones" (from memory) which is more informative but otherwise behaves the same. See: http://serverfault.com/questions/66414 http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0 FreeBSD dev1.demo 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #3 r222557M: Thu Jun 16 23:58:02 CEST 2011 root@neo.vx.sk:/usr/obj/releng_8_2/sys/GENERIC amd64 I found this email relating to a fix pushed to OpenSolaris in 2009. http://mail.opensolaris.org/pipermail/onnv-notify/2009-August/010064.html Did this fix ever get merged into the FreeBSD source tree, or is this a more recent regression unrelated to the fix from 2009? Unfortunately the OpenSolaris bug database seems to have disappeared so I can't find the actual patch. The workaround - zdb -d poolname |grep % - followed by manually zfs destroying the offending stray clones, works apart from that zdb on a busy pool (one with active zfs replication happening on it) gives EIO about 90% of the time, and that is the case in our application, which makes the workaround time consuming and temporary. We are resorting to attempting to predict and destroy all the possible stray clone names whenever a zfs replication event completes (either a failure or a success) to stop later destroys of snapshots failing with "cannot destroy [snapshot]: dataset already exists". In our application we do occasionally abort replication events if they appear to not be making any progress by sending SIGTERM to the corresponding zfs send/recv processes. FWIW, we didn't see this in v14 or v15 (8.1 or 8.2 respectively). Does anyone know better how to predict what the clone names will be, so that I can refine our workaround until we have a patch for 8-STABLE? Currently we are predicting that all the snapshot names included in an incremental receive are potential "stray clones", but this does not seem to catch all of them. Also, the clones corresponding to a snapshot do not have the same name as the snapshot, it seems that perhaps it is the "parent" snapshot (i.e. the previous snapshot on which the next snapshot is based upon) that becomes the name of the stray clone. This is fine but we lose this information by "pruning" intermediate snapshots. Is there any way to interrogate ZFS for the names of any such clones prior to attempting the destroy of the snapshot so that we can automatically clean them up more efficiently? Thank you all for your excellent work :-) -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Mobile: +447791750420 www.hybrid-cluster.com - Cloud web hosting platform From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 17:47:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2103B1065676; Mon, 11 Jul 2011 17:47:20 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id BFBA48FC13; Mon, 11 Jul 2011 17:47:19 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 3B3121CC0B; Mon, 11 Jul 2011 19:47:18 +0200 (CEST) Received: by cruwe.de (Postfix, from userid 65534) id 1C9921CC08; Mon, 11 Jul 2011 19:47:18 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED, MIME_QP_LONG_LINE autolearn=unavailable version=3.3.1 Received: from dijkstra (p57BDFF08.dip.t-dialin.net [87.189.255.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id E17691CBFB; Mon, 11 Jul 2011 19:47:15 +0200 (CEST) Date: Mon, 11 Jul 2011 19:47:07 +0200 From: "Christopher J. Ruwe" To: Pan Tsu Message-ID: <20110711194707.48812c43@dijkstra> In-Reply-To: <86tyauc7vb.fsf@gmail.com> References: <20110710142617.1d80289b@dijkstra> <86mxgmjooc.fsf@gmail.com> <20110710160504.0d4bf4c0@dijkstra> <20110710145044.GA94832@icarus.home.lan> <20110710172012.51fce47c@dijkstra> <86tyauc7vb.fsf@gmail.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Pwder25aXRME1k3orx/=e2r"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 17:47:20 -0000 --Sig_/Pwder25aXRME1k3orx/=e2r Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 10 Jul 2011 22:23:36 +0400 Pan Tsu wrote: > "Christopher J. Ruwe" writes: >=20 > [...] > > /etc/rc.d/zvol > > /etc/rc.d/zfs > > /etc/rc.d/dumpon > > /etc/rc.d/ddb > > /etc/rc.d/initrandom > > /etc/rc.d/geli > > /etc/rc.d/gbde > > /etc/rc.d/encswap > > /etc/rc.d/ccd > > /etc/rc.d/swap1 > > /etc/rc.d/fsck > > /etc/rc.d/root > > /etc/rc.d/hostid_save > > /etc/rc.d/mdconfig > > /etc/rc.d/mountcritlocal > > > > This makes sense to me and reflects the order I assumed in my > > description. The question remains, however, if my configuration is > > of any in {unusual, ..., stupid} as I require first zfs mount of /, > > then GELI-unlock and then zfs mount of {/usr,/usr/local, ...}. >=20 > Do you mount the root pool over smth else? Otherwise, root should be > mounted by kernel before init(8) is started. And /etc/rc.d doesn't > exist before root is mounted. I mount root-pool via=20 zfs_load=3D"YES" vfs.root.mountfrom=3D"zfs:rpool/root" in /boot/loader.conf. So far, all is right from what I understand. =20 > I think the correct order is >=20 > 0 vfs_mountroot* > .. > 2 rc.d/zvol (pre v28) > .. > 6 rc.d/geli > .. > 15 rc.d/mountcritlocal > 16 rc.d/zfs >=20 > where extra datasets from the root pool can be mounted via fstab at > rc.d/mountcritlocal time. Not sure if you import geli pool during boot > or not and leak its configuration via zpool.cache. In this setup, I should not have any problems. However, I do not realize (a= nd very much doubt) that I changed anything in the order of the services (l= acking the capability to deterministically do so, anyway). =46rom rcorder I understand that all that is required to set rcorder right wo= uld be to change /etc/rc.d/zfs to include a REQUIRE: geli, so that my geli-= encrypted volume would be unlocked before all zfs-datasets are mounted? If so, what could be the reason that my rcorder-setup deviates from the sta= ndard and how could I coerce it back to standard? Thank you for your help so far, cheers --=20 Christopher J. Ruwe TZ GMT + 2 --Sig_/Pwder25aXRME1k3orx/=e2r Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJOGzchAAoJEJTIKW/o3iwUgZwP/jSZ68Bk4xCaxGcsM9+t6TCe 8fUcUqrrxWqpq0QbYd8J5XpKP1GMYtCEqZ9xlg04ycmnQidN8bHiYkADx26cWQbU SoFf9DoPLDSF+8ADC+5VMjHNauq40bErhjAlFQRFsjKrJrueceg/5eD+MCWFT0mn UUwdM7NM/s2rqxKb9VchWeElplBJi+Sl44RIT7R528p6H2/ek9avJOkwwvzfpglI aRIIhxfA7Wmj7DGDh+rClTyKA4DcCMFNXQiA8t7oNkpeMJkWeDOeBmoJcfa0YELl oKTRAoU8PKQLG02H5oxZEamWl08IL8kCC3IaGoPN8gSRBjaZATzJi4QjyFPfz7i3 GcqWqUou8H53vsbUhJRqYBHsVlzS41W1kA4nXkyVitDOVDKVp56tHN6DYkdUgPwe p7F1DqqEMxJ6oBk6RbTIq6bh1ognmKv6vz5+H1HjKPwIDvI+grbTwy1ensrCN281 IaTq0R86g7YumN3//EwOvrFjpmqBFc/T9/XFiTjhRlm1ieMA2iczZ+WcNn6a8NL5 RbjIzKoCGauDNUiEEFFB5sm1KCshXGrl6LaCKbL6MX+3g/L7t8SCQcJVwEZPtagg LM46awwsQjUNPcIISwmEE63HUiLZ6OptIJ2cWbfJ0iH//m2dDUGdzBQIIVdfJhxu LNSNGE67P7FYRe+K5iKR =y8+j -----END PGP SIGNATURE----- --Sig_/Pwder25aXRME1k3orx/=e2r-- From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 20:26:03 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B3591065670; Mon, 11 Jul 2011 20:26:03 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E54518FC0A; Mon, 11 Jul 2011 20:26:02 +0000 (UTC) Received: by vws18 with SMTP id 18so4126073vws.13 for ; Mon, 11 Jul 2011 13:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=5qLLH/Rm1o9HStENz63mjEvCQMBRKbVtJK82xhX3dGY=; b=KLKhUDsMkNhEkhvyGsOO66Eni6x1ILQS3cKbK2UOa8uLG/OeY80gJCClgGJv1fykmB vmwtG6j+bTBNEcMRoxS9whCHYc3VQ9zb5KuMnj4z6MP4xJ69PA/v7fr8etzpHvp13hBx rIdsjBJckdA6IpQy5+CaoDVsS/l8Hcb4TCprY= Received: by 10.52.88.76 with SMTP id be12mr2870606vdb.366.1310415961948; Mon, 11 Jul 2011 13:26:01 -0700 (PDT) Received: from localhost (gpftor6.privacyfoundation.de [62.212.67.209]) by mx.google.com with ESMTPS id bh17sm4683381vdc.3.2011.07.11.13.25.54 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 13:25:57 -0700 (PDT) From: Pan Tsu To: "Christopher J. Ruwe" References: <20110710142617.1d80289b@dijkstra> <86mxgmjooc.fsf@gmail.com> <20110710160504.0d4bf4c0@dijkstra> <20110710145044.GA94832@icarus.home.lan> <20110710172012.51fce47c@dijkstra> <86tyauc7vb.fsf@gmail.com> <20110711194707.48812c43@dijkstra> Date: Tue, 12 Jul 2011 00:25:38 +0400 In-Reply-To: <20110711194707.48812c43@dijkstra> (Christopher J. Ruwe's message of "Mon, 11 Jul 2011 19:47:07 +0200") Message-ID: <86r55wd0ot.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:26:03 -0000 "Christopher J. Ruwe" writes: [...] > In this setup, I should not have any problems. However, I do not > realize (and very much doubt) that I changed anything in the order of > the services (lacking the capability to deterministically do so, > anyway). > > From rcorder I understand that all that is required to set rcorder > right would be to change /etc/rc.d/zfs to include a REQUIRE: geli, so > that my geli-encrypted volume would be unlocked before all > zfs-datasets are mounted? Yep, or revert to default where rc.d/zfs depends on rc.d/mountcritlocal. $ svn co -qr223699 svn://svn.freebsd.org/base/stable/8/etc/rc.d $ rcorder rc.d/* | nl | sed /zfs/q 1 rc.d/hostid 2 rc.d/zvol 3 rc.d/dumpon 4 rc.d/ddb 5 rc.d/initrandom 6 rc.d/geli 7 rc.d/gbde 8 rc.d/encswap 9 rc.d/ccd 10 rc.d/swap1 11 rc.d/fsck 12 rc.d/root 13 rc.d/hostid_save 14 rc.d/mdconfig 15 rc.d/mountcritlocal 16 rc.d/zfs > > If so, what could be the reason that my rcorder-setup deviates from > the standard and how could I coerce it back to standard? No idea. Try basic check with $ diff -ur /usr/src/etc/rc.d /etc/rc.d $ mergemaster $ mergemaster -s unless someone else can reproduce your issue. From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 21:09:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90E2B106564A for ; Mon, 11 Jul 2011 21:09:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5460E8FC1F for ; Mon, 11 Jul 2011 21:09:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFVmG06DaFvO/2dsb2JhbABTG4Qpo1ipaY4/kHaBK4QAgQ8EklaQYw X-IronPort-AV: E=Sophos;i="4.65,517,1304308800"; d="scan'208";a="126872217" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 11 Jul 2011 17:09:16 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C2F28B3FE3 for ; Mon, 11 Jul 2011 17:09:16 -0400 (EDT) Date: Mon, 11 Jul 2011 17:09:16 -0400 (EDT) From: Rick Macklem To: FreeBSD FS Message-ID: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Subject: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 21:09:25 -0000 Hi, I've added a few sentences to the exports.5 man page in an effort to try and clarify how NFSv4 exports work. If anyone would like to comment on these changes, it would be appreciated. Ideally, you are familiar with the FreeBSD /etc/exports file, but not w.r.t. NFSv4. The diff is at: http://people.freebsd.org/~rmacklem/exports.5.diff in case you can't handle looking at the following. (The email system I use loves to mess with whitespace, etc.) Index: usr.sbin/mountd/exports.5 =================================================================== --- usr.sbin/mountd/exports.5 (revision 223937) +++ usr.sbin/mountd/exports.5 (working copy) @@ -28,7 +28,7 @@ .\" @(#)exports.5 8.3 (Berkeley) 3/29/95 .\" $FreeBSD$ .\" -.Dd December 3, 2009 +.Dd July 11, 2011 .Dt EXPORTS 5 .Os .Sh NAME @@ -72,6 +72,12 @@ There are three forms of this specification. The first is to list all mount points as absolute directory paths separated by whitespace. +This list of directory paths should be considered an +``administrative control'', since it only enforced by the +.Xr mountd 8 +daemon and not the kernel. +As such, it only applies to NFSv2, NFSv3 mounts and only w.r.t. the +client's use of the mount protocol. The second is to specify the pathname of the root of the file system followed by the .Fl alldirs @@ -81,8 +87,19 @@ .Fl r option is used on .Xr mountd 8 . +For NFSv4, since the ``administrative controls'' are not applied +because NFSv4 does not use the mount protocol, +all of the above export line(s) should be considered to have the +.Fl alldirs +flag, even if the line is specified without it. The third form has the string ``V4:'' followed by a single absolute path name, to specify the NFSv4 tree root. +This line does not export any file system, but simply marks where the root +of the server's directory tree is for NFSv4 clients. +The exported file systems for NFSv4 are specified via the other lines +in the +.Xr exports 5 +file in the same way as for NFSv2, NFSv3. The pathnames must not have any symbolic links in them and should not have any .Dq Pa \&. From owner-freebsd-fs@FreeBSD.ORG Mon Jul 11 23:55:24 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33E0D1065672 for ; Mon, 11 Jul 2011 23:55:24 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id DC20E8FC13 for ; Mon, 11 Jul 2011 23:55:23 +0000 (UTC) X-AuditID: 1209190d-b7bdeae0000004f8-9a-4e1b8d11e9f8 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E5.CC.01272.11D8B1E4; Mon, 11 Jul 2011 19:53:53 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p6BNtMcR013177; Mon, 11 Jul 2011 19:55:22 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p6BNtLia029488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2011 19:55:22 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p6BNtKu8020213; Mon, 11 Jul 2011 19:55:20 -0400 (EDT) Date: Mon, 11 Jul 2011 19:55:20 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrSvYK+1nMOGllMWxxz/ZLB4uu8bk wOQx49N8Fo/fm/cyBTBFcdmkpOZklqUW6dslcGUsOjCRtWCPRMWu9auYGhi3CHcxcnBICJhI XP1W1cXICWSKSVy4t56ti5GLQ0hgH6PEvvUvWSCcDYwSJ58eh3IOMEnsnTuNHcJpYJR4cGQe M0g/i4C2xJzL25lAbDYBFYmZbzaygdgiAuoSm1f3g9UwA9lXD/1mBLGFBYwlDm3ZxQZyBqeA n8SThwogYV4BB4lPS0+AlQgJ+Er8OTcTzBYV0JFYvX8KC0SNoMTJmU9YIEZaSvxb+4t1AqPg LCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6eVmluilppRuYgQHqiTvDsZ3B5UO MQpwMCrx8K6WlvYTYk0sK67MPcQoycGkJMr7qwsoxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ3 pBYox5uSWFmVWpQPk5LmYFES51Xz/u8rJJCeWJKanZpakFoEk5Xh4FCS4H3RA9QoWJSanlqR lplTgpBm4uAEGc4DNHwhSA1vcUFibnFmOkT+FKOilDjvF5CEAEgiozQPrheWSF4xigO9Isz7 EaSKB5iE4LpfAQ1mAhr8WloSZHBJIkJKqoHx3OybRc2J8osjb/xZrpzy879WWczbKObVHkfr GHL3GU8zfHzkm8WiDwu2L7v9zcxA0Vnvy5p9lxsVs5yOt3ce2afw9ssmzYyZDRMbe0uC/vQ4 6cXF5797VXQs/kDOxVl777n4hH19wO61PVFT4nLc2rsnPku5lXzLU3l8dQ2P/6kzt8tZ3lX9 UmIpzkg01GIuKk4EAI2Vo1r/AgAA Cc: FreeBSD FS Subject: Re: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 23:55:24 -0000 Hi Rick, On Mon, 11 Jul 2011, Rick Macklem wrote: > Hi, > > I've added a few sentences to the exports.5 man page in an effort > to try and clarify how NFSv4 exports work. > > If anyone would like to comment on these changes, it would be > appreciated. Ideally, you are familiar with the FreeBSD /etc/exports > file, but not w.r.t. NFSv4. > > The diff is at: > http://people.freebsd.org/~rmacklem/exports.5.diff > > in case you can't handle looking at the following. (The email > system I use loves to mess with whitespace, etc.) > > Index: usr.sbin/mountd/exports.5 > =================================================================== > --- usr.sbin/mountd/exports.5 (revision 223937) > +++ usr.sbin/mountd/exports.5 (working copy) > @@ -28,7 +28,7 @@ > .\" @(#)exports.5 8.3 (Berkeley) 3/29/95 > .\" $FreeBSD$ > .\" > -.Dd December 3, 2009 > +.Dd July 11, 2011 > .Dt EXPORTS 5 > .Os > .Sh NAME > @@ -72,6 +72,12 @@ > There are three forms of this specification. > The first is to list all mount points as absolute > directory paths separated by whitespace. > +This list of directory paths should be considered an > +``administrative control'', since it only enforced by the This wants to be ===== .Dq administrative control , since it is only enforced by the ===== (note the "is" as well as the Dq macro) > +.Xr mountd 8 > +daemon and not the kernel. > +As such, it only applies to NFSv2, NFSv3 mounts and only w.r.t. the The comma between v2 and v3 is not really right and should be replaced by "and"; the mdoc gurus seem to want to put the trailing "the" on the next line in a case like this. > +client's use of the mount protocol. > The second is to specify the pathname of the root of the file system > followed by the > .Fl alldirs > @@ -81,8 +87,19 @@ > .Fl r > option is used on > .Xr mountd 8 . > +For NFSv4, since the ``administrative controls'' are not applied The Dq macro should be used here as well. > +because NFSv4 does not use the mount protocol, > +all of the above export line(s) should be considered to have the > +.Fl alldirs > +flag, even if the line is specified without it. > The third form has the string ``V4:'' followed by a single absolute path > name, to specify the NFSv4 tree root. > +This line does not export any file system, but simply marks where the root > +of the server's directory tree is for NFSv4 clients. > +The exported file systems for NFSv4 are specified via the other lines > +in the > +.Xr exports 5 > +file in the same way as for NFSv2, NFSv3. I must confess that this chunk leaves me slightly confused. Does the V4 server export everything starting from the root of its export, or must subdirectories/filesystems be specified as well? Thanks, Ben Kaduk > The pathnames must not have any symbolic links in them and should not have > any > .Dq Pa \&. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 00:09:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29FA7106566C for ; Tue, 12 Jul 2011 00:09:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id D89D48FC16 for ; Tue, 12 Jul 2011 00:09:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJyQG06DaFvO/2dsb2JhbABTEAuEKaNZiHqwJZB6gSuEAIEPBJBLgguQEFM X-IronPort-AV: E=Sophos;i="4.65,517,1304308800"; d="scan'208";a="130511060" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 11 Jul 2011 20:09:35 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BA443B3F52; Mon, 11 Jul 2011 20:09:35 -0400 (EDT) Date: Mon, 11 Jul 2011 20:09:35 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <1274844194.450446.1310429375748.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD FS Subject: Re: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:09:41 -0000 Benjamin Kaduk wrote: > Hi Rick, > > On Mon, 11 Jul 2011, Rick Macklem wrote: > > > Hi, > > > > I've added a few sentences to the exports.5 man page in an effort > > to try and clarify how NFSv4 exports work. > > > > If anyone would like to comment on these changes, it would be > > appreciated. Ideally, you are familiar with the FreeBSD /etc/exports > > file, but not w.r.t. NFSv4. > > > > The diff is at: > > http://people.freebsd.org/~rmacklem/exports.5.diff > > > > in case you can't handle looking at the following. (The email > > system I use loves to mess with whitespace, etc.) > > > > Index: usr.sbin/mountd/exports.5 > > =================================================================== > > --- usr.sbin/mountd/exports.5 (revision 223937) > > +++ usr.sbin/mountd/exports.5 (working copy) > > @@ -28,7 +28,7 @@ > > .\" @(#)exports.5 8.3 (Berkeley) 3/29/95 > > .\" $FreeBSD$ > > .\" > > -.Dd December 3, 2009 > > +.Dd July 11, 2011 > > .Dt EXPORTS 5 > > .Os > > .Sh NAME > > @@ -72,6 +72,12 @@ > > There are three forms of this specification. > > The first is to list all mount points as absolute > > directory paths separated by whitespace. > > +This list of directory paths should be considered an > > +``administrative control'', since it only enforced by the > > This wants to be > ===== > .Dq administrative control , > since it is only enforced by the > ===== > (note the "is" as well as the Dq macro) > > > +.Xr mountd 8 > > +daemon and not the kernel. > > +As such, it only applies to NFSv2, NFSv3 mounts and only w.r.t. the > > The comma between v2 and v3 is not really right and should be replaced > by > "and"; the mdoc gurus seem to want to put the trailing "the" on the > next > line in a case like this. > > > +client's use of the mount protocol. > > The second is to specify the pathname of the root of the file system > > followed by the > > .Fl alldirs > > @@ -81,8 +87,19 @@ > > .Fl r > > option is used on > > .Xr mountd 8 . > > +For NFSv4, since the ``administrative controls'' are not applied > > The Dq macro should be used here as well. > > > +because NFSv4 does not use the mount protocol, > > +all of the above export line(s) should be considered to have the > > +.Fl alldirs > > +flag, even if the line is specified without it. > > The third form has the string ``V4:'' followed by a single absolute > > path > > name, to specify the NFSv4 tree root. > > +This line does not export any file system, but simply marks where > > the root > > +of the server's directory tree is for NFSv4 clients. > > +The exported file systems for NFSv4 are specified via the other > > lines > > +in the > > +.Xr exports 5 > > +file in the same way as for NFSv2, NFSv3. > > I must confess that this chunk leaves me slightly confused. Does the > V4 > server export everything starting from the root of its export No, the "V4:" line does not export the file systems. It only chooses where the NFSv4 client's notion of "/" is (and sets some limits on which client IP#s are allowed to do NFSv4 mounts, because there are state related NFSv4 Ops that don't refer to a file, so they can't be tied to any file system). >, or must > subdirectories/filesystems be specified as well? > Yes. Specifically the filesystems (directories within a filesystem are only known to the mount protocol for the so called administrative controls). For filesystems below the NFSv4 root that are not exported, all that can be done is traversal of them for the purpose of doing a mount. (And I'm not sure ZFS even allows that?) So, if you can come up with words that make this clearer than what I wrote, feel free to suggest something. > Thanks, > > Ben Kaduk > And thanks for the formatting comments. I'll incorporate those in the patch. rick > > The pathnames must not have any symbolic links in them and should > > not have > > any > > .Dq Pa \&. > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to > > "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 06:59:07 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C0D51065672 for ; Tue, 12 Jul 2011 06:59:07 +0000 (UTC) (envelope-from vnik@arqa.ru) Received: from grom.arqa.ru (grom.sicex.ru [193.178.135.38]) by mx1.freebsd.org (Postfix) with ESMTP id C0A0E8FC12 for ; Tue, 12 Jul 2011 06:59:05 +0000 (UTC) Received: from maik.arqa.ru (maik [192.168.47.115]) by grom.arqa.ru (8.14.3/8.14.3) with ESMTP id p6C6x369088815 for ; Tue, 12 Jul 2011 13:59:03 +0700 (NOVST) (envelope-from vnik@arqa.ru) Received: from [127.0.0.1] (pc-vnik.arqa.ru [192.168.40.162]) by maik.arqa.ru (8.14.4/8.14.4) with ESMTP id p6C6x3dr064207 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 12 Jul 2011 13:59:03 +0700 (NOVST) (envelope-from vnik@arqa.ru) Message-ID: <4E1BF0B6.4010001@arqa.ru> Date: Tue, 12 Jul 2011 13:59:02 +0700 From: Nikitin Vitaly User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20110712 #5546674, check: 20110712 notchecked Cc: Subject: zfs filesystem and hast X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 06:59:07 -0000 Hello! I have some problrm with zfs filesystem on hast device. I have 2 nodes with hast replication. I set up on both nodes zfs filesystem on hast storage device. When roles of nodes are changed all is good, but if roles come back after 5-10 minutes. On the one of nodes I detect panic kernel error. It is: "panic: solaris assert: load_nvlist (spa, spa -> spa_config_object, &nv)= =0, file: /usr/src/sys/modules/zfs/.../.../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c, line:1124 " Plesase, help me. What does mean this error? And how I can correct this problem? Thank you. From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 10:14:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EA631065670 for ; Tue, 12 Jul 2011 10:14:41 +0000 (UTC) (envelope-from luke@digital-crocus.com) Received: from mail.digital-crocus.com (node2.digital-crocus.com [91.209.244.128]) by mx1.freebsd.org (Postfix) with ESMTP id 15E2C8FC12 for ; Tue, 12 Jul 2011 10:14:40 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dkselector; d=hybrid-logic.co.uk; h=Received:Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Spam-Score:X-Digital-Crocus-Maillimit:X-Authenticated-Sender:X-Complaints:X-Admin:X-Abuse; b=0Wb8tmXW0zb5v5WnrPKDKA8U/+tEskLflqKVTd/MQKoNfGRMgotwmXAMUag0vmWX0ljxI/+ewjYik1hhqJS5+jhBx1cEuAE49Ncfr3jGaDXILvoWgC/ZrdRUrvaplFmF; Received: from luke by mail.digital-crocus.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QgZyQ-000MWP-Vr for freebsd-fs@freebsd.org; Tue, 12 Jul 2011 11:13:50 +0100 Received: from vlan111.pact.srf.ac.uk ([193.37.225.200] helo=[10.0.111.134]) by mail.digital-crocus.com with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QgZyQ-000MS2-Fs; Tue, 12 Jul 2011 11:13:50 +0100 From: Luke Marsden To: freebsd-fs@freebsd.org In-Reply-To: <1310383541.30844.73.camel@behemoth> References: <1310383541.30844.73.camel@behemoth> Content-Type: text/plain; charset="UTF-8" Date: Tue, 12 Jul 2011 11:14:51 +0100 Message-ID: <1310465691.26698.1.camel@behemoth> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Digital-Crocus-Maillimit: done X-Authenticated-Sender: luke X-Complaints: abuse@digital-crocus.com X-Admin: admin@digital-crocus.com X-Abuse: abuse@digital-crocus.com (Please include full headers in abuse reports) Cc: tech@hybrid-logic.co.uk Subject: Re: ZFS bug in v28 - temporary clones are not automatically destroyed on error X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 10:14:41 -0000 On Mon, 2011-07-11 at 12:25 +0100, Luke Marsden wrote: > Hi all, > > I'm experiencing this bug on mm's ZFS v28 image from 19.06.2011 > r222557M: > > cannot destroy 'hpool/hcfs/fs@snapshot': dataset already exists > > That is on a v4 formatted zfs filesystem on a v28 formatted pool, if I > zfs upgrade the filesystem to v5 the error changes to "snapshot has > dependent clones" (from memory) which is more informative but otherwise > behaves the same. See: > > http://serverfault.com/questions/66414 > http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0 > Just an update on this for posterity, I found this: http://www.freebsd.org/cgi/query-pr.cgi?pr=157728 The workaround indicated there - which in our case was implemented by a semaphore around 'zfs list' and 'zfs recv' operations (so they never run in parallel for the same filesystem), seems to have worked perfectly and we're not seeing any more stray clones. It would be good to fix this properly, of course :-) -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Mobile: +447791750420 www.hybrid-cluster.com - Cloud web hosting platform From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 10:50:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E17F106566B for ; Tue, 12 Jul 2011 10:50:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id CBD1A8FC17 for ; Tue, 12 Jul 2011 10:50:13 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6CAo97D010546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 20:50:10 +1000 Date: Tue, 12 Jul 2011 20:50:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Benjamin Kaduk In-Reply-To: Message-ID: <20110712202759.H1311@besplex.bde.org> References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD FS Subject: Re: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 10:50:14 -0000 On Mon, 11 Jul 2011, Benjamin Kaduk wrote: > Hi Rick, > > On Mon, 11 Jul 2011, Rick Macklem wrote: > >> Hi, >> >> I've added a few sentences to the exports.5 man page in an effort >> to try and clarify how NFSv4 exports work. >> >> If anyone would like to comment on these changes, it would be >> appreciated. Ideally, you are familiar with the FreeBSD /etc/exports >> file, but not w.r.t. NFSv4. >> ... > >> +.Xr mountd 8 >> +daemon and not the kernel. >> +As such, it only applies to NFSv2, NFSv3 mounts and only w.r.t. the > > The comma between v2 and v3 is not really right and should be replaced by > "and"; the mdoc gurus seem to want to put the trailing "the" on the next > line in a case like this. Also, there is a rule against contractions (e.g., "it's"), so there is presumably a rule against nonstandard abbreviations (e.g., "w.r.t."). Currently, "w.r.t" is only used once, in 1 man page, and was presumably written there by Rick :-) (mount_nfs.8 and the link to it). This use shows an apparent syntactical complication related to "the" in the above -- it also has "the" on the same line, but for some reason it has "\&" after "w.r.t.". The briefer and even more informal abbreviation "wrt" is not used in any man page. But "with respect to" is used 2445 times (but many are duplicates due to links). BTW, does anyone know a good way of not seeing duplicates in commands like "zgrep -r wrt /usr/share/man"? find(1) doesn't seem to have any flag to suppress duplicates. du(1) has to know how to not count duplicates internally. I think it as special code for this and there is no special support for this in fts(3). Recently I have been annoyed by duplicates under .svn. I want to type a simple grep -r or "find . | xargs grep" without any complicated pattern for the file names and not see multiple copies. Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 11:29:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27EBD106566B for ; Tue, 12 Jul 2011 11:29:39 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D589E8FC0A for ; Tue, 12 Jul 2011 11:29:38 +0000 (UTC) Received: by vxg33 with SMTP id 33so4607838vxg.13 for ; Tue, 12 Jul 2011 04:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yXSYvA/S1CGwIFN7A3NSTFsnhhsZdKqZMnvkeSwNOLI=; b=W0Njd+ZZV+0ELL1/DagtOjotDl+J0dDN/Ae7hTLujgMPCfwT9SQu7Vs66KgTS5EHSd 0ZkWKL1srbb3s+66OTGFnRunaZM9K62eg2NxduDI4+kXhRDs1xasTReEYJQ4MTDnI3dh yL9eGv3hWQGtYC2WQkcmhbI7f627oDDih95GI= MIME-Version: 1.0 Received: by 10.52.109.38 with SMTP id hp6mr3529855vdb.435.1310470177953; Tue, 12 Jul 2011 04:29:37 -0700 (PDT) Received: by 10.52.182.225 with HTTP; Tue, 12 Jul 2011 04:29:37 -0700 (PDT) In-Reply-To: <20110712202759.H1311@besplex.bde.org> References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> <20110712202759.H1311@besplex.bde.org> Date: Tue, 12 Jul 2011 12:29:37 +0100 Message-ID: From: Tom Evans To: Bruce Evans Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD FS Subject: Re: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 11:29:39 -0000 On Tue, Jul 12, 2011 at 11:50 AM, Bruce Evans wrote: > BTW, does anyone know a good way of not seeing duplicates in commands > like "zgrep -r wrt /usr/share/man"? =C2=A0find(1) doesn't seem to have an= y > flag to suppress duplicates. =C2=A0du(1) has to know how to not count > duplicates internally. =C2=A0I think it as special code for this and ther= e > is no special support for this in fts(3). =C2=A0Recently I have been anno= yed > by duplicates under .svn. =C2=A0I want to type a simple grep -r or > "find . | xargs grep" without any complicated pattern for the file names > and not see multiple copies. > > Bruce This probably won't help in this case, but I use ack [1] to search source. It's smarter than grep, it knows not to look at VC files or directories, object files, etc. Its written in standalone perl [2], so you can just drop it in your ~/bin. Your pattern can use all of PCRE, and it knows all about lots of different file types, eg "ack --hh" will just search headers. It won't help in this case though, since it doesn't know how to look inside gzipped files. Cheers Tom [1] http://betterthangrep.com/ [2] curl http://betterthangrep.com/ack-standalone > ~/bin/ack && chmod 0755= !#: From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 11:44:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C7B1106564A for ; Tue, 12 Jul 2011 11:44:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 32B708FC08 for ; Tue, 12 Jul 2011 11:44:27 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DB60546B03; Tue, 12 Jul 2011 07:44:26 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 683B58A02C; Tue, 12 Jul 2011 07:44:26 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Tue, 12 Jul 2011 07:44:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> <20110712202759.H1311@besplex.bde.org> In-Reply-To: <20110712202759.H1311@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107120744.26047.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 12 Jul 2011 07:44:26 -0400 (EDT) Cc: Subject: Re: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 11:44:27 -0000 On Tuesday, July 12, 2011 6:50:09 am Bruce Evans wrote: > BTW, does anyone know a good way of not seeing duplicates in commands > like "zgrep -r wrt /usr/share/man"? find(1) doesn't seem to have any > flag to suppress duplicates. du(1) has to know how to not count > duplicates internally. I think it as special code for this and there > is no special support for this in fts(3). Recently I have been annoyed > by duplicates under .svn. I want to type a simple grep -r or > "find . | xargs grep" without any complicated pattern for the file names > and not see multiple copies. I actually have resorted to using specialized commands and aliases for doing diffs and greps in source trees. From my .cshrc: alias cvsdiff diff -uprN -x \'\*~\' -x \'\*.o\' -x \'\*.orig\' -x \'\*.rej\' -x compile -x CVS -x .svn -I \'\\\$FreeBSD\' alias cvsndiff diff -upr -x \'\*~\' -x \'\*.o\' -x \'\*.orig\' -x \'\*.rej\' -x compile -x CVS -x .svn -I \'\\\$FreeBSD\' (cvsndiff doesn't include new files) And a script I keep in my ~/bin: % cat kgrep #!/bin/sh # # Grep inside a kernel directory skipping compile directories and revision # control directories find `ls` ! -path '*compile*' ! -path '*.svn*' ! -path '*CVS*' \ ! -path '*cscope*' ! -type d -print0 | xargs -0 grep -H "$@" I also use cscope and xcscope.el to navigate kernel trees which is faster than grep for cases where it works. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 12:32:06 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7778F1065675 for ; Tue, 12 Jul 2011 12:32:06 +0000 (UTC) (envelope-from prvs=11747cbab7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 076AB8FC0A for ; Tue, 12 Jul 2011 12:32:05 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 12 Jul 2011 13:22:27 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 12 Jul 2011 13:22:27 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014114083.msg for ; Tue, 12 Jul 2011 13:22:26 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11747cbab7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.ORG Message-ID: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> From: "Steven Hartland" To: Date: Tue, 12 Jul 2011 13:22:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Subject: strange zpool status output X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 12:32:06 -0000 zpool status pool: tank state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub in progress for 307445734561825859h27m, 6.96% done, 307445734561825849h8m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 da0s3h ONLINE 0 0 0 This has only just started scrubbing after a reboot into single user mode about 5 mins ago, so something looks odd here ;-) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 12:33:06 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51584106566B for ; Tue, 12 Jul 2011 12:33:06 +0000 (UTC) (envelope-from prvs=11747cbab7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D4D688FC14 for ; Tue, 12 Jul 2011 12:33:05 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 12 Jul 2011 13:21:20 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 12 Jul 2011 13:21:20 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014114069.msg for ; Tue, 12 Jul 2011 13:21:20 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11747cbab7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.ORG Message-ID: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> From: "Steven Hartland" To: Date: Tue, 12 Jul 2011 13:21:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Subject: Forcing a full file read in ZFS even when checksum error encountered X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 12:33:06 -0000 I was wondering if anyone found a solution to the following thread posted back in 2008. http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/004269.html I have a volume here which has a jpg reporting a checksum error which refuses to read with cp giving a "Bad Address". Being a jpg is highly likely that a simple error will be recoverable if I can read the data off. I'm also interested to see if this is an error or just a false positive. Has anyone found a solution to this? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 14:28:18 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93FFD1065675 for ; Tue, 12 Jul 2011 14:28:18 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 607858FC1C for ; Tue, 12 Jul 2011 14:28:18 +0000 (UTC) Received: by iyb11 with SMTP id 11so6045110iyb.13 for ; Tue, 12 Jul 2011 07:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=eWKp4vR7MR/JIUpIcDnnrIxaW9uvBFmncjK97RHFISA=; b=KxGLItsx+Uig0XBS7L5wpp8gdfPpOacByDwGyEiyAbvaU0JMPFdImAWaCSwYNLOtXC jVoJiYiVpo0KenabbhSsFO2F1O3xqcTr3ryXWx8ZKfw8pspb1tlGEzlaHPY9N6EDC5AX R1hsC95zz1B7zYbLx/6sp9SipB92vIv9lUl9U= Received: by 10.231.112.193 with SMTP id x1mr5631824ibp.59.1310479594084; Tue, 12 Jul 2011 07:06:34 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.190.141 with HTTP; Tue, 12 Jul 2011 07:06:04 -0700 (PDT) In-Reply-To: <20110628010822.GA41399@icarus.home.lan> References: <1309217450.43651.YahooMailRC@web120014.mail.ne1.yahoo.com> <20110628010822.GA41399@icarus.home.lan> From: Chris Rees Date: Tue, 12 Jul 2011 15:06:04 +0100 X-Google-Sender-Auth: qQzwDKKlqa8YlpEdvw0xtsVP2HI Message-ID: To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, George Sanders Subject: Re: Improving old-fashioned UFS2 performance with lots of inodes... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 14:28:18 -0000 On 28 June 2011 02:08, Jeremy Chadwick wrote: > > On what exact OS version? =A0Please don't say "8.2", need to know > 8.2-RELEASE, -STABLE, or what. =A0You said "8.x" above, which is too > vague. =A0If 8.2-STABLE you should not be tuning vm.kmem_size_max at all, > and you probably don't need to tune vm.kmem_size either. We don't do 8.2-STABLE, it's 8-STABLE.... Are you referring to the difference between RELENG_8_2 and RELENG_8_2_0_RELEASE? Chris From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 14:38:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99A25106566B; Tue, 12 Jul 2011 14:38:50 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 45C5A8FC0A; Tue, 12 Jul 2011 14:38:50 +0000 (UTC) Received: by vws18 with SMTP id 18so4810181vws.13 for ; Tue, 12 Jul 2011 07:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KcpOaGD6bJdJYS39/eOkJ32XUpSfwsdyZJker3u01DY=; b=q84wpzR5nwuZ6qKeb//OL0RdtGkNBSSTICBLgUeGTOonD1FfWmeKV4bwJtSK7vJXsz I6V2NAtAAXmPwbr96uIYzumj6tNa1Y3pBLieKMftpJKz8+Zc9dQ5AnUxAxrRnSpliVAD JwPsvwQXrErVoGK68v738x0bUuGYWlETTmyHc= MIME-Version: 1.0 Received: by 10.52.92.78 with SMTP id ck14mr31498vdb.100.1310481529386; Tue, 12 Jul 2011 07:38:49 -0700 (PDT) Received: by 10.52.182.225 with HTTP; Tue, 12 Jul 2011 07:38:49 -0700 (PDT) In-Reply-To: References: <1309217450.43651.YahooMailRC@web120014.mail.ne1.yahoo.com> <20110628010822.GA41399@icarus.home.lan> Date: Tue, 12 Jul 2011 15:38:49 +0100 Message-ID: From: Tom Evans To: Chris Rees Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Improving old-fashioned UFS2 performance with lots of inodes... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 14:38:50 -0000 On Tue, Jul 12, 2011 at 3:06 PM, Chris Rees wrote: > On 28 June 2011 02:08, Jeremy Chadwick wrote: >> >> On what exact OS version? =C2=A0Please don't say "8.2", need to know >> 8.2-RELEASE, -STABLE, or what. =C2=A0You said "8.x" above, which is too >> vague. =C2=A0If 8.2-STABLE you should not be tuning vm.kmem_size_max at = all, >> and you probably don't need to tune vm.kmem_size either. > > We don't do 8.2-STABLE, it's 8-STABLE.... Are you referring to the > difference between RELENG_8_2 and RELENG_8_2_0_RELEASE? > > Chris I've heard this mantra repeated before on list. If this is in fact true, then something needs to change so that uname -r agrees: > $ svn info | grep URL ; uname -r URL: http://svn.freebsd.org/base/stable/8 8.2-STABLE As far as the OS is concerned, 8.2-STABLE is RELENG_8 sometime between when RELENG_8_2 was branched and when RELENG_8_3 will be branched, and is an entirely legit description. IMO, just because it does not correspond to a specific branch or tag does not leave it without meaning. Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 14:47:46 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB2E31065675 for ; Tue, 12 Jul 2011 14:47:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id B13938FC1E for ; Tue, 12 Jul 2011 14:47:46 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 72P41h0071bwxycA12njnD; Tue, 12 Jul 2011 14:47:43 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id 72nc1h00g1t3BNj8e2nd68; Tue, 12 Jul 2011 14:47:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 034A9102C36; Tue, 12 Jul 2011 07:47:45 -0700 (PDT) Date: Tue, 12 Jul 2011 07:47:44 -0700 From: Jeremy Chadwick To: Chris Rees Message-ID: <20110712144744.GA53733@icarus.home.lan> References: <1309217450.43651.YahooMailRC@web120014.mail.ne1.yahoo.com> <20110628010822.GA41399@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, George Sanders Subject: Re: Improving old-fashioned UFS2 performance with lots of inodes... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 14:47:46 -0000 On Tue, Jul 12, 2011 at 03:06:04PM +0100, Chris Rees wrote: > On 28 June 2011 02:08, Jeremy Chadwick wrote: > > > > On what exact OS version? ?Please don't say "8.2", need to know > > 8.2-RELEASE, -STABLE, or what. ?You said "8.x" above, which is too > > vague. ?If 8.2-STABLE you should not be tuning vm.kmem_size_max at all, > > and you probably don't need to tune vm.kmem_size either. > > We don't do 8.2-STABLE, it's 8-STABLE.... Are you referring to the > difference between RELENG_8_2 and RELENG_8_2_0_RELEASE? I was referring to someone coming along saying "I'm running 8.2", which isn't accurate enough these days. More specifically, I was referring to the fact that some people are running RELENG_8 (presently known as 8.2-STABLE), while others are running RELENG_8_2 (presently known as 8.2-RELEASE). Yes I'm aware of RELENG_8_2_0_RELEASE, but I don't go that far. I stick with what shows up in src/examples/cvsup/*-supfile, and what's listed on the releng/ page: http://www.freebsd.org/releng/ Let's get back on the subject of the OP's issue please. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 14:52:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02F64106564A for ; Tue, 12 Jul 2011 14:52:45 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D0B828FC13 for ; Tue, 12 Jul 2011 14:52:44 +0000 (UTC) Received: by pvg11 with SMTP id 11so5020501pvg.13 for ; Tue, 12 Jul 2011 07:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:references:date:message-id:user-agent:mime-version :content-type; bh=imw4YtK7tBQLmUeH0dzqi7g1/qFCMC9xpYMyU2Voj/I=; b=qqqmhmu/J7E+2qgaVBb+yhkunD9ZiBoPedmUnNllZj2+rIVAFCrwWJELlO5U8Ezd36 8LBQY0bQMXVfI1eRuvBL9Y1tMvc6MH37BD8kYSm4yr1E3eHqLUqZrjAt8OFXQBqWVmE6 NuEzFOEVzKniP4+D8tCk1RC+jqt3dDihEIUxY= Received: by 10.68.9.5 with SMTP id v5mr32360pba.140.1310482363693; Tue, 12 Jul 2011 07:52:43 -0700 (PDT) Received: from localhost (tor-exit-readme-2wh1.kromyon.net [68.169.35.41]) by mx.google.com with ESMTPS id q5sm8788641pbk.26.2011.07.12.07.52.40 (version=SSLv3 cipher=OTHER); Tue, 12 Jul 2011 07:52:42 -0700 (PDT) From: Pan Tsu To: freebsd-fs@freebsd.org References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> <20110712202759.H1311@besplex.bde.org> <201107120744.26047.jhb@freebsd.org> Date: Tue, 12 Jul 2011 18:52:28 +0400 Message-ID: <861uxvimab.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Subject: ignore duplicates (Was: request for review of exports.5 update) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 14:52:45 -0000 John Baldwin writes: > On Tuesday, July 12, 2011 6:50:09 am Bruce Evans wrote: >> BTW, does anyone know a good way of not seeing duplicates in commands >> like "zgrep -r wrt /usr/share/man"? How about following? - install man page links using symbolic links, not hard links - force zgrep(1) to ignore symbolic links [...] > % cat kgrep > #!/bin/sh > # > # Grep inside a kernel directory skipping compile directories and revision > # control directories > > find `ls` ! -path '*compile*' ! -path '*.svn*' ! -path '*CVS*' \ > ! -path '*cscope*' ! -type d -print0 | xargs -0 grep -H "$@" /usr/bin/grep has --exclude which is like your example *still* descends into ignored directories. textproc/gnugrep has --exclude-dir which is similar to using `-or -prune' which makes find(1) to not descend into ignored directories. As for whether it matters to descend here is an example # disable caching metadata/data before test $ zfs set primarycache=none foo/usr/src $ zfs set secondarycache=none foo/usr/src $ time find /usr/src/sys ! -path '*.svn*' >/dev/null $ time find /usr/src/sys ! -path '*.svn*' -or -prune >/dev/null On my 3yo box I don't even need ministat(1) to decide 26.78sr 0.21su 1.09ss 4% 1420k 45s+2194u 217pr+0pf+0w 28377+0io 28394+8935cs 3.68sr 0.07su 0.13ss 5% 1420k 46s+2260u 217pr+0pf+0w 3156+0io 3158+876cs From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 16:47:49 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62873106566C; Tue, 12 Jul 2011 16:47:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2928FC17; Tue, 12 Jul 2011 16:47:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6CGlnKq063040; Tue, 12 Jul 2011 16:47:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6CGlnVD063036; Tue, 12 Jul 2011 16:47:49 GMT (envelope-from linimon) Date: Tue, 12 Jul 2011 16:47:49 GMT Message-Id: <201107121647.p6CGlnVD063036@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158839: [zfs] ZFS Bootloader Fails if there is a Dead Disk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:47:49 -0000 Old Synopsis: ZFS Bootloader Fails if there is a Dead Disk New Synopsis: [zfs] ZFS Bootloader Fails if there is a Dead Disk Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jul 12 16:47:36 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158839 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 17:35:55 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6AC106566C for ; Tue, 12 Jul 2011 17:35:55 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B57418FC0A for ; Tue, 12 Jul 2011 17:35:54 +0000 (UTC) Received: by wyg24 with SMTP id 24so574wyg.13 for ; Tue, 12 Jul 2011 10:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4/AUM2D3n2p12MCH7b1AqpnbT5DVAvP0WX8AB7aQcDY=; b=G+kgSnZO7RivuSQ40Cbk+aAalmabe37miSGjmNYze0ZXKWSvmfjtQplPvN2kSl3IjA S3rZmCnsdvA54frBQBKDBw2QmiyVRjNTb5XLr5MV39DwBaQs0hKjShI5KA4EmTXCmSYU 35j11xjQqMEV8JoMVyNOno1lCb5chLMg0VXQI= MIME-Version: 1.0 Received: by 10.216.144.100 with SMTP id m78mr163651wej.55.1310492153410; Tue, 12 Jul 2011 10:35:53 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.216.46.18 with HTTP; Tue, 12 Jul 2011 10:35:53 -0700 (PDT) In-Reply-To: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> Date: Tue, 12 Jul 2011 10:35:53 -0700 X-Google-Sender-Auth: ZKY-8YN0kxdpdJ8PHVJi_JBFTvM Message-ID: From: Artem Belevich To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:35:55 -0000 On Tue, Jul 12, 2011 at 5:21 AM, Steven Hartland wrote: > I was wondering if anyone found a solution to the following thread > posted back in 2008. > http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/004269.html > > I have a volume here which has a jpg reporting a checksum error > which refuses to read with cp giving a "Bad Address". > > Being a jpg is highly likely that a simple error will be recoverable > if I can read the data off. > > I'm also interested to see if this is an error or just a false > positive. Chances are that *is* an error somewhere. It could be HDD or bad RAM(at the time the write happened) or bad cabling, but the error is probably there. > > Has anyone found a solution to this? Maybe. See here: http://blogs.oracle.com/relling/entry/holy_smokes_a_holey_file Using that method you still would not get the bad block, but you may be able to recover data beyond it. If you really want to get access to the data that ZFS considers to be corrupted, you need to get close and personal with zdb. This blog post may be a good starting point: http://cuddletech.com/blog/?p=407 --Artem From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 17:38:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D525C1065670 for ; Tue, 12 Jul 2011 17:38:14 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 958DA8FC15 for ; Tue, 12 Jul 2011 17:38:14 +0000 (UTC) Received: by yxl31 with SMTP id 31so1019569yxl.13 for ; Tue, 12 Jul 2011 10:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dsulq0QG4MWB1zCYQo8u8kVHnT5V2wgR0gG2pyiOlFw=; b=MM5LGf04RpkpqJ6k+C71CZI79f+lHFOiDsHr6Qd1iwwfZn948zYLBx4/kouWKKYd4m UU8Q+RT0Ao/3bowLo7dGcWrT2KTVXkvi6/qx2S/nOMZ8y9pCK/ykAxoMp986A6sNaI4A Zjw0kPDMcQW4d2u3Oeu8G95FYTRlEIUT8lpYc= MIME-Version: 1.0 Received: by 10.90.5.24 with SMTP id 24mr338921age.206.1310492293712; Tue, 12 Jul 2011 10:38:13 -0700 (PDT) Received: by 10.90.118.7 with HTTP; Tue, 12 Jul 2011 10:38:13 -0700 (PDT) In-Reply-To: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> References: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> Date: Tue, 12 Jul 2011 10:38:13 -0700 Message-ID: From: Freddie Cash To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: strange zpool status output X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:38:15 -0000 On Tue, Jul 12, 2011 at 5:22 AM, Steven Hartland wrote: > zpool status > pool: tank > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-**8000-8A > scrub: scrub in progress for 307445734561825859h27m, 6.96% done, > 307445734561825849h8m to go > Nothing odd. It takes a good 15 minutes or so for the scrub code to determine just how fast things are going, how much work there is to do, etc etc, before the progress line makes sense. The "time in progress" and "time to go" numbers will fluctuate rapidly for the first little while, and then settle down into "normal" numbers. I wouldn't worry about it unless it's still wonky like that after an hour. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 17:39:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9BEF106564A for ; Tue, 12 Jul 2011 17:39:27 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79CAC8FC13 for ; Tue, 12 Jul 2011 17:39:27 +0000 (UTC) Received: by yxl31 with SMTP id 31so1020171yxl.13 for ; Tue, 12 Jul 2011 10:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G5naC1Tu4M3zIr90j+AKYoxshD36WChnAjfNt9j0vos=; b=Qkx3ssTWTn8c4CooOsvDsXukglkVH2vfD1JuFVMASwSVHJ/UH4SSvAmn8dGpXaiem8 UWrnbNflmU3oZiAR+h4bXRyD0DIGpMYethvwbg53Ca/6rU07Mm3YaVJOsK3RTObF6Or7 WwFHq0MaRF/w1OxRNlezAfJcbQL7vWlqkRlHY= MIME-Version: 1.0 Received: by 10.90.23.39 with SMTP id 39mr364579agw.125.1310492366770; Tue, 12 Jul 2011 10:39:26 -0700 (PDT) Received: by 10.90.118.7 with HTTP; Tue, 12 Jul 2011 10:39:26 -0700 (PDT) In-Reply-To: References: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> Date: Tue, 12 Jul 2011 10:39:26 -0700 Message-ID: From: Freddie Cash To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: strange zpool status output X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:39:27 -0000 On Tue, Jul 12, 2011 at 10:38 AM, Freddie Cash wrote: > On Tue, Jul 12, 2011 at 5:22 AM, Steven Hartland wrote: > >> zpool status >> pool: tank >> state: ONLINE >> status: One or more devices has experienced an error resulting in data >> corruption. Applications may be affected. >> action: Restore the file in question if possible. Otherwise restore the >> entire pool from backup. >> see: http://www.sun.com/msg/ZFS-**8000-8A >> scrub: scrub in progress for 307445734561825859h27m, 6.96% done, >> 307445734561825849h8m to go >> > > Nothing odd. It takes a good 15 minutes or so for the scrub code to > determine just how fast things are going, how much work there is to do, etc > etc, before the progress line makes sense. The "time in progress" and "time > to go" numbers will fluctuate rapidly for the first little while, and then > settle down into "normal" numbers. > And, if there are any writes happening in the pool, or snapshots being created/deleted, then the numbers will also be wonky as the "end point" is constantly being moved further into the "future". -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 18:10:21 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37DC81065675 for ; Tue, 12 Jul 2011 18:10:21 +0000 (UTC) (envelope-from prvs=11747cbab7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id B28078FC0A for ; Tue, 12 Jul 2011 18:10:20 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 12 Jul 2011 19:09:12 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 12 Jul 2011 19:09:12 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014117821.msg for ; Tue, 12 Jul 2011 19:09:12 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11747cbab7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Freddie Cash" References: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> Date: Tue, 12 Jul 2011 19:09:40 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: strange zpool status output X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:10:21 -0000 It was still saying silly numbers when it finished, so yes. I've seen some high numbers while it homes in on the actual times but nothing quite so wildly out there. Regards Steve ----- Original Message -----=20 From: Freddie Cash=20 To: Steven Hartland=20 Cc: freebsd-fs@freebsd.org=20 Sent: Tuesday, July 12, 2011 6:38 PM Subject: Re: strange zpool status output On Tue, Jul 12, 2011 at 5:22 AM, Steven Hartland wrote: zpool status pool: tank state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub in progress for 307445734561825859h27m, 6.96% done, 307445734561825849h8m to go Nothing odd. It takes a good 15 minutes or so for the scrub code to determine just how fast things are going, how much work there is to do, etc etc, before the progress line makes sense. The "time in progress" and "time to go" numbers will fluctuate rapidly for the first little while, and then settle down into "normal" numbers. I wouldn't worry about it unless it's still wonky like that after an hour. --=20 Freddie Cash fjwcash@gmail.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 18:48:53 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D91D5106566B for ; Tue, 12 Jul 2011 18:48:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 612E114FD0F; Tue, 12 Jul 2011 18:48:53 +0000 (UTC) Message-ID: <4E1C9714.6090507@FreeBSD.org> Date: Tue, 12 Jul 2011 11:48:52 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Evans References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> <20110712202759.H1311@besplex.bde.org> In-Reply-To: <20110712202759.H1311@besplex.bde.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD FS , Benjamin Kaduk Subject: Re: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:48:53 -0000 On 07/12/2011 03:50, Bruce Evans wrote: > Also, there is a rule against contractions (e.g., "it's"), so there > is presumably a rule against nonstandard abbreviations (e.g., "w.r.t."). Yes to both, the reason being that we want to make life as easy as possible for non-native English readers (and maybe someday even translators). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 19:46:11 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675C5106567B for ; Tue, 12 Jul 2011 19:46:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9778FC0C for ; Tue, 12 Jul 2011 19:46:11 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DEAB046B2A; Tue, 12 Jul 2011 15:46:10 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 761EB8A03C; Tue, 12 Jul 2011 15:46:10 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Tue, 12 Jul 2011 15:36:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> <201107120744.26047.jhb@freebsd.org> <861uxvimab.fsf@gmail.com> In-Reply-To: <861uxvimab.fsf@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107121536.58643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 12 Jul 2011 15:46:10 -0400 (EDT) Cc: Pan Tsu Subject: Re: ignore duplicates (Was: request for review of exports.5 update) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:46:11 -0000 On Tuesday, July 12, 2011 10:52:28 am Pan Tsu wrote: > As for whether it matters to descend here is an example > > # disable caching metadata/data before test > $ zfs set primarycache=none foo/usr/src > $ zfs set secondarycache=none foo/usr/src > > $ time find /usr/src/sys ! -path '*.svn*' >/dev/null > $ time find /usr/src/sys ! -path '*.svn*' -or -prune >/dev/null > > On my 3yo box I don't even need ministat(1) to decide > > 26.78sr 0.21su 1.09ss 4% 1420k 45s+2194u 217pr+0pf+0w 28377+0io 28394+8935cs > 3.68sr 0.07su 0.13ss 5% 1420k 46s+2260u 217pr+0pf+0w 3156+0io 3158+876cs Ah, nice. This is a definite improvement. I've modified my script as such: #!/bin/sh # # Grep inside a kernel directory skipping compile directories and revision # control directories find `ls` '(' ! '(' -name compile -o -name .svn -o -name CVS ')' -o -prune ')' \ ! -name '*cscope*' ! -type d -print0 | xargs -0 grep -H "$@" -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Jul 12 22:14:23 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2993C106564A; Tue, 12 Jul 2011 22:14:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 02E2D8FC1E; Tue, 12 Jul 2011 22:14:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6CMEMeh063279; Tue, 12 Jul 2011 22:14:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6CMEMTD063275; Tue, 12 Jul 2011 22:14:22 GMT (envelope-from linimon) Date: Tue, 12 Jul 2011 22:14:22 GMT Message-Id: <201107122214.p6CMEMTD063275@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158802: [amd] amd(8) ICMP storm and unkillable process. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 22:14:23 -0000 Old Synopsis: amd(8) ICMP storm and unkillable process. New Synopsis: [amd] amd(8) ICMP storm and unkillable process. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jul 12 22:13:58 UTC 2011 Responsible-Changed-Why: assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=158802 From owner-freebsd-fs@FreeBSD.ORG Wed Jul 13 07:30:03 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 187EC1065676 for ; Wed, 13 Jul 2011 07:30:03 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 5698C8FC14 for ; Wed, 13 Jul 2011 07:30:01 +0000 (UTC) Received: (qmail 15001 invoked from network); 13 Jul 2011 07:03:36 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 13 Jul 2011 07:03:36 -0000 Received: (qmail 14978 invoked by uid 599); 13 Jul 2011 07:03:36 -0000 Received: from unknown (HELO icritical.com) (87.127.43.249) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 13 Jul 2011 08:03:36 +0100 Message-ID: <4E1D4347.9050508@icritical.com> Date: Wed, 13 Jul 2011 08:03:35 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110403 Thunderbird/3.1.9 MIME-Version: 1.0 To: Freddie Cash References: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2011 07:03:35.0223 (UTC) FILETIME=[FB95C470:01CC412A] X-Virus-Scanned: by iCritical at mail1.icritical.com Cc: freebsd-fs@freebsd.org Subject: Re: strange zpool status output X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 07:30:03 -0000 On 07/12/11 18:38, Freddie Cash wrote: > On Tue, Jul 12, 2011 at 5:22 AM, Steven Hartland wrote: >> scrub: scrub in progress for 307445734561825859h27m, 6.96% done, >> 307445734561825849h8m to go > > Nothing odd. It takes a good 15 minutes or so for the scrub code to > determine just how fast things are going, how much work there is to do, etc > etc, before the progress line makes sense. The "time in progress" and "time > to go" numbers will fluctuate rapidly for the first little while, and then > settle down into "normal" numbers. Why would "time in progress" fluctuate? It's simply (now-start)... I'd guess the system time's gone back since the scrub started. From owner-freebsd-fs@FreeBSD.ORG Wed Jul 13 08:37:09 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A36B106564A; Wed, 13 Jul 2011 08:37:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2537A8FC14; Wed, 13 Jul 2011 08:37:08 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6D8b3F2020185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2011 18:37:06 +1000 Date: Wed, 13 Jul 2011 18:37:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin In-Reply-To: <201107121536.58643.jhb@freebsd.org> Message-ID: <20110713174223.C932@besplex.bde.org> References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> <201107120744.26047.jhb@freebsd.org> <861uxvimab.fsf@gmail.com> <201107121536.58643.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, Pan Tsu Subject: Re: ignore duplicates (Was: request for review of exports.5 update) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 08:37:09 -0000 On Tue, 12 Jul 2011, John Baldwin wrote: > On Tuesday, July 12, 2011 10:52:28 am Pan Tsu wrote: >> As for whether it matters to descend here is an example >> >> # disable caching metadata/data before test >> $ zfs set primarycache=none foo/usr/src >> $ zfs set secondarycache=none foo/usr/src >> >> $ time find /usr/src/sys ! -path '*.svn*' >/dev/null >> $ time find /usr/src/sys ! -path '*.svn*' -or -prune >/dev/null Not exactly what I'm looking for, but it seems that a script that adds exotic args to some utility is needed. (I have only 1 nontrivial vcs script, for un-applying and then re-applying applying local patches to cvs checkouts). >> On my 3yo box I don't even need ministat(1) to decide >> >> 26.78sr 0.21su 1.09ss 4% 1420k 45s+2194u 217pr+0pf+0w 28377+0io 28394+8935cs >> 3.68sr 0.07su 0.13ss 5% 1420k 46s+2260u 217pr+0pf+0w 3156+0io 3158+876cs This still has some problems: - still extremely slow. On my 6yo system running ~5.2-CURRENT, there are only 10760 files in /usr/src/sys on ffs (including CVS files and about 1000 local files, but no object files). These take 0.04 seconds to find, once cached. Breaking the cache to test the uncached case is too hard with ffs. On a FreeBSD cluster machine running ~9.0- CURRENT, exponential bloat (mainly almost quadrupling for .svn files) results in 48556 files in /usr/src/sys on ffs, but only 12138 files after removing all .svn files and 13698 files after removing all .svn files except the .svn directories. These take 0.90 seconds to find with a plain find(1); 1.59 seconds with the first of the above, and 0.34 seconds with the second of the above. Breaking the cache to test the uncached case is too hard with ffs. - the first version works, but the one with -prune finds .svn directories (1560 of them in FreeBSD-9-not-quite-current). > Ah, nice. This is a definite improvement. I've modified my script as such: Pruning apparently reduces the number of files stat'ed by almost a factor of almost 4, since svn almost quadruplicates the number of files. But why is "find -path" so much slower than plain find? > #!/bin/sh > # > # Grep inside a kernel directory skipping compile directories and revision > # control directories > > find `ls` '(' ! '(' -name compile -o -name .svn -o -name CVS ')' -o -prune ')' \ > ! -name '*cscope*' ! -type d -print0 | xargs -0 grep -H "$@" "find -name" is much faster than "find -path" on the FreeBSD cluster machine. It takes only 0.08 seconds, which is acceptably slower than the 0.04 seconds on my old machine (due to the nfs overhead and 30% more files). It has the same problem as "find -path" when pruning -- it doesn't remove the .svn directories. These can be removed with another "! -name" of course. The first version with -path should be the best one. find(1) should be smarter and not descend into directories that already match "! -path". On my old machine, "find ... ! -name CVS -o -prune" (to prune a couple of thousand CVS files but not the 910 CVS directories)) takes only 0.02 seconds. "find ... ! -path '*CVS*' -prune" also takes 0.02 seconds; "find ... ! -path '*CVS*' is what takes 0.04 seconds, and a plain find takes 0.03 seconds. In other words, -name is imperceptibly faster than -prune. So there seems to be another problem with -path in -current -- it is 0.35/0.08 times slower than -name. On second thoughts, this is probably just the nfs close-to-open-consistency pessimization, perhaps combined with nfs opening directories more than necessary. [l]stat(2)'s should be cached even in nfs, but every directory open requires RPCs. Bruce From owner-freebsd-fs@FreeBSD.ORG Wed Jul 13 10:12:55 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2F67106566B for ; Wed, 13 Jul 2011 10:12:55 +0000 (UTC) (envelope-from prvs=1175a7be7a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5160B8FC14 for ; Wed, 13 Jul 2011 10:12:54 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 13 Jul 2011 11:01:17 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 13 Jul 2011 11:01:16 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014130760.msg; Wed, 13 Jul 2011 11:01:15 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1175a7be7a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <94D74687DE95420486730136248EEB77@multiplay.co.uk> From: "Steven Hartland" To: "Artem Belevich" References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> Date: Wed, 13 Jul 2011 11:01:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 10:12:55 -0000 ----- Original Message ----- From: "Artem Belevich" > Maybe. See here: > http://blogs.oracle.com/relling/entry/holy_smokes_a_holey_file > > Using that method you still would not get the bad block, but you may > be able to recover data beyond it. > > If you really want to get access to the data that ZFS considers to be > corrupted, you need to get close and personal with zdb. > This blog post may be a good starting point: http://cuddletech.com/blog/?p=407 Perfect, thanks Artem. For the record using the following zdb commands I've managed to get the file data off the pool. 1. zdb -dddd / (find the objectid by searching for the filename) 2. zdb -ddddd / (find the indirect blocks, the third block of hex) 3. zdb -R : 2>/tmp/filedata e.g. zdb -dddd tank/usr zdb -ddddd tank/usr 1243 zdb -R tank:0:22df120000:18000:r 2>corrupt.jpg Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Wed Jul 13 15:06:49 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC7DD1065674 for ; Wed, 13 Jul 2011 15:06:49 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 678B78FC0C for ; Wed, 13 Jul 2011 15:06:49 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 249254AA5; Wed, 13 Jul 2011 14:49:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ti9Gnhs5QqPC; Wed, 13 Jul 2011 14:49:46 +0000 (UTC) Received: from ernie.mlan.solnet.ch (ernie.mlan.solnet.ch [212.101.1.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id 9452B4A9E; Wed, 13 Jul 2011 14:49:46 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Vogt X-Priority: 3 In-Reply-To: <94D74687DE95420486730136248EEB77@multiplay.co.uk> Date: Wed, 13 Jul 2011 16:49:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39788F1B-DCF5-488C-8033-5628B97D4592@bsdunix.ch> References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> <94D74687DE95420486730136248EEB77@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 15:06:49 -0000 Hi Steven On Jul 13, 2011, at 12:01 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Artem Belevich" >> Maybe. See here: >> http://blogs.oracle.com/relling/entry/holy_smokes_a_holey_file >> Using that method you still would not get the bad block, but you may >> be able to recover data beyond it. >> If you really want to get access to the data that ZFS considers to be >> corrupted, you need to get close and personal with zdb. >> This blog post may be a good starting point: = http://cuddletech.com/blog/?p=3D407 >=20 > Perfect, thanks Artem. >=20 > For the record using the following zdb commands I've managed to get = the > file data off the pool. >=20 > 1. zdb -dddd / (find the objectid by searching for the > filename) > 2. zdb -ddddd / (find the indirect blocks, = the > third block of hex) > 3. zdb -R : 2>/tmp/filedata >=20 > e.g. > zdb -dddd tank/usr > zdb -ddddd tank/usr 1243 > zdb -R tank:0:22df120000:18000:r 2>corrupt.jpg Which ZFS version do you have? zdb core dumps on all my ZFS 28 with = 8-Stable if i use multiple -dd options.=20 Regards, Thomas=20 From owner-freebsd-fs@FreeBSD.ORG Wed Jul 13 16:07:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21845106566B; Wed, 13 Jul 2011 16:07:06 +0000 (UTC) (envelope-from prvs=1175a7be7a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 39CD98FC0A; Wed, 13 Jul 2011 16:07:05 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 13 Jul 2011 17:05:45 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 13 Jul 2011 17:05:45 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014134093.msg; Wed, 13 Jul 2011 17:05:44 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1175a7be7a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Thomas Vogt" References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> <94D74687DE95420486730136248EEB77@multiplay.co.uk> <39788F1B-DCF5-488C-8033-5628B97D4592@bsdunix.ch> Date: Wed, 13 Jul 2011 17:06:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:07:06 -0000 ----- Original Message ----- From: "Thomas Vogt" >> e.g. >> zdb -dddd tank/usr >> zdb -ddddd tank/usr 1243 >> zdb -R tank:0:22df120000:18000:r 2>corrupt.jpg > > Which ZFS version do you have? zdb core dumps on all my ZFS 28 with 8-Stable if i use multiple -dd options. We're using 8.2-RELEASE with ZFS 28 Thomas. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Wed Jul 13 16:38:10 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DFB1065670 for ; Wed, 13 Jul 2011 16:38:10 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E963C8FC1E for ; Wed, 13 Jul 2011 16:38:09 +0000 (UTC) Received: by wyg24 with SMTP id 24so359908wyg.13 for ; Wed, 13 Jul 2011 09:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lTrgxdvoFMC5bA2XhyDc5j2Kxt3B0dg06qul0/nrd0c=; b=KrFack8VzVGFObJXYREm/CH7LNdpBPFxHPmKp9lOdQmnZWQraMy7u2ttOwopxfLvwc KzZcYgcwlqWVraBHsxw6VZx7unwLmNn2eCoD5NMZ7eu8aTmyFyiL5DcLOEElpcj3XinP C3644eTAnq5KOQZAwUgXfrmhcXCC3/AmEzfdc= MIME-Version: 1.0 Received: by 10.216.61.198 with SMTP id w48mr1121438wec.40.1310575087229; Wed, 13 Jul 2011 09:38:07 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.216.46.18 with HTTP; Wed, 13 Jul 2011 09:38:07 -0700 (PDT) In-Reply-To: <94D74687DE95420486730136248EEB77@multiplay.co.uk> References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> <94D74687DE95420486730136248EEB77@multiplay.co.uk> Date: Wed, 13 Jul 2011 09:38:07 -0700 X-Google-Sender-Auth: fzdyRyr5RzUBR6V48Zuj-of9NXs Message-ID: From: Artem Belevich To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:38:10 -0000 On Wed, Jul 13, 2011 at 3:01 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Artem Belevich" >> >> Maybe. See here: >> http://blogs.oracle.com/relling/entry/holy_smokes_a_holey_file >> >> Using that method you still would not get the bad block, but you may >> be able to recover data beyond it. >> >> If you really want to get access to the data that ZFS considers to be >> corrupted, you need to get close and personal with zdb. >> This blog post may be a good starting point: >> http://cuddletech.com/blog/?p=3D407 > > Perfect, thanks Artem. > > For the record using the following zdb commands I've managed to get the > file data off the pool. > > 1. zdb -dddd / (find the objectid by searching for the > filename) If I understand it correctly, opjectid is used as inode number. "ls -i" would let you find it a bit faster. --Artem > 2. zdb -ddddd / (find the indirect blocks, the > third block of hex) > 3. zdb -R : 2>/tmp/filedata > > e.g. > zdb -dddd tank/usr > zdb -ddddd tank/usr 1243 > zdb -R tank:0:22df120000:18000:r 2>corrupt.jpg > > =A0 Regards > =A0 Steve > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he > person or entity to whom it is addressed. In the event of misdirection, t= he > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > From owner-freebsd-fs@FreeBSD.ORG Wed Jul 13 19:23:46 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1059F106564A for ; Wed, 13 Jul 2011 19:23:46 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by mx1.freebsd.org (Postfix) with SMTP id 9F8F78FC12 for ; Wed, 13 Jul 2011 19:23:45 +0000 (UTC) Received: from [98.139.212.151] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2011 19:10:54 -0000 Received: from [98.139.221.69] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2011 19:10:54 -0000 Received: from [127.0.0.1] by smtp106.rog.mail.bf1.yahoo.com with NNFMP; 13 Jul 2011 19:10:54 -0000 X-Yahoo-Newman-Id: 778154.52606.bm@smtp106.rog.mail.bf1.yahoo.com Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp106.rog.mail.bf1.yahoo.com with SMTP; 13 Jul 2011 12:10:54 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: ZUE1ZRAVM1k3d8m0n5YNwCllSS5BwZWl28.FgpkBsw27LMw DsWtcA_.mwMLuVnzGAZIKNZ1dUmnr5rCRJiji_hXa1WiGd02Z8OkM7ompGEr YumCkX7pD7jrQBZpBMJkVzkhmpx3EO0qsIJt3OWkBOTkmVgZ.1xpiXvOsMh9 Ql4zCi49.I4Qxqi2vI4j_eUs4rK3zWBvk.MN6xPgt.lINYwbb5bmBLwPxoPE z.7jiNgzhsJhUHHT2ydaXVc2JZtBT38u_wE5mNQSs5AFWWMAK9w1QjsMo5Ed FZcVMRSCpB8nQTZBMTWnWnZWkb9K.LydRFojti89rpkuKSedjZu5oDDeedFm Ahq95KO6TAh4DHLlCvjLF7d45qbgRw7LZWgBZXiSqRLopNEsTDSa96PYplbh L8f9Hc1PvViMKotw3_03Wi_nFCi4lR9L..4WsbyJxnMEd24Ze X-Yahoo-Newman-Property: ymail-3 Received: by smtp.irbisnet.com (Postfix, from userid 80) id 823195CCA; Wed, 13 Jul 2011 15:10:53 -0400 (EDT) To: Steven Hartland MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2011 15:10:53 -0400 From: Andriy Bakay In-Reply-To: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> References: <74BE0A7A690143C2AE50D102D4C850F7@multiplay.co.uk> Message-ID: X-Sender: andriy@irbisnet.com User-Agent: RoundCube Webmail/0.5.1 Cc: freebsd-fs@FreeBSD.ORG Subject: Re: strange zpool status output X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 19:23:46 -0000 On Tue, 12 Jul 2011 13:22:53 +0100, Steven Hartland wrote: > zpool status > pool: tank > state: ONLINE > status: One or more devices has experienced an error resulting in > data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore > the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scrub: scrub in progress for 307445734561825859h27m, 6.96% done, > 307445734561825849h8m to go > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > da0s3h ONLINE 0 0 0 > > This has only just started scrubbing after a reboot into single user > mode > about 5 mins ago, so something looks odd here ;-) > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained > in > it. > > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" I had similar "strange" numbers and some READ/WRITE/CKSUM intermittent recoverable error (in your case it could be not recoverable) when my non-ECC RAM was corrupted. Maybe you should run memtest86+? From owner-freebsd-fs@FreeBSD.ORG Thu Jul 14 09:56:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D62B106564A for ; Thu, 14 Jul 2011 09:56:39 +0000 (UTC) (envelope-from prvs=1176c4cfda=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 023118FC15 for ; Thu, 14 Jul 2011 09:56:38 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 14 Jul 2011 10:44:40 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 14 Jul 2011 10:44:40 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014148242.msg; Thu, 14 Jul 2011 10:44:40 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1176c4cfda=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <0D8E79D4B0204131B198D603D13B3F64@multiplay.co.uk> From: "Steven Hartland" To: "Artem Belevich" References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk><94D74687DE95420486730136248EEB77@multiplay.co.uk> Date: Thu, 14 Jul 2011 10:45:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:56:39 -0000 ----- Original Message ----- From: "Artem Belevich" >> 1. zdb -dddd / (find the objectid by searching for the >> filename) >> > If I understand it correctly, opjectid is used as inode number. "ls > -i" would let you find it a bit faster. Cool, didn't realise that :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Thu Jul 14 10:27:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F24151065679 for ; Thu, 14 Jul 2011 10:27:39 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id AD7F98FC17 for ; Thu, 14 Jul 2011 10:27:39 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QhJ8s-0005qy-2G for freebsd-fs@freebsd.org; Thu, 14 Jul 2011 12:27:38 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jul 2011 12:27:38 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jul 2011 12:27:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Thu, 14 Jul 2011 12:27:25 +0200 Lines: 13 Message-ID: References: <1309217450.43651.YahooMailRC@web120014.mail.ne1.yahoo.com> <20110628010822.GA41399@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 Subject: Re: Improving old-fashioned UFS2 performance with lots of inodes... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 10:27:40 -0000 On 12/07/2011 16:06, Chris Rees wrote: > On 28 June 2011 02:08, Jeremy Chadwick wrote: >> >> On what exact OS version? Please don't say "8.2", need to know >> 8.2-RELEASE, -STABLE, or what. You said "8.x" above, which is too >> vague. If 8.2-STABLE you should not be tuning vm.kmem_size_max at all, >> and you probably don't need to tune vm.kmem_size either. > > We don't do 8.2-STABLE, it's 8-STABLE.... Yeah, but colloquially "8.2-STABLE" means "8-STABLE in between 8.2 and 8.3 releases"... it's not a new thing. From owner-freebsd-fs@FreeBSD.ORG Thu Jul 14 12:13:34 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C6C81065670 for ; Thu, 14 Jul 2011 12:13:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id BAF698FC15 for ; Thu, 14 Jul 2011 12:13:33 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4310B.dip.t-dialin.net [79.196.49.11]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B4EB6844010; Thu, 14 Jul 2011 14:13:18 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTP id D416A2041; Thu, 14 Jul 2011 14:13:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1310645595; bh=mjIqksrOb0x+9SnYf3K6ClICLlQlN8Aj0HAhmYT+mMc=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cvKiGJ5/3b1MVCU0tKhpnj+XxbNqvae5QUb3ogZ+qLaFqvat9pZyGvCaI59GKF5z8 DLgOkNe/gWhkkGD9VTxhaqGTTSLeklebvs4KQuF35QrII3FL8Pfxua48yeAs6BXdkW iltUnCcmlK6PGQb+oNTPYuo+AT9Wbl6Y0pA4uutZGE6OyMGtWBMxb6sHKc0g94IFWf hausc5L50AA3N1U/+Sfbq2vNKdoJqGTEG4/fHUrUDubh6w5Mj8fa6NiPdQ5KsqdABi fgZ9eGRSQv5AF7R1VlkE+blYT94JHNpBHZ7E+Pp+zJiMGG1jzgftCt358op2wQ0oxW 3TK2Tpbc7Uhfw== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.14.4/Submit) id p6ECDFEN057404; Thu, 14 Jul 2011 14:13:15 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 62.72.127.66 ([62.72.127.66]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 14 Jul 2011 14:13:15 +0200 Message-ID: <20110714141315.11192skc1c6286l7@webmail.leidinger.net> Date: Thu, 14 Jul 2011 14:13:15 +0200 From: Alexander Leidinger To: Ivan Voras References: <1309217450.43651.YahooMailRC@web120014.mail.ne1.yahoo.com> <20110628010822.GA41399@icarus.home.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B4EB6844010.A1376 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.1, required 6, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1311250400.71433@CXhzJJqJ3nG02pzDzPDBTw X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: Improving old-fashioned UFS2 performance with lots of inodes... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 12:13:34 -0000 Quoting Ivan Voras (from Thu, 14 Jul 2011 12:27:25 +0200): > On 12/07/2011 16:06, Chris Rees wrote: >> On 28 June 2011 02:08, Jeremy Chadwick wrote: >>> >>> On what exact OS version? Please don't say "8.2", need to know >>> 8.2-RELEASE, -STABLE, or what. You said "8.x" above, which is too >>> vague. If 8.2-STABLE you should not be tuning vm.kmem_size_max at all, >>> and you probably don't need to tune vm.kmem_size either. >> >> We don't do 8.2-STABLE, it's 8-STABLE.... > > Yeah, but colloquially "8.2-STABLE" means "8-STABLE in between 8.2 > and 8.3 releases"... it's not a new thing. It can also be that "RELENG_8_2" respectively "releng/8.2" is meant (to speak in VCS terms), or 8.2pX if you want to stay in the user-visible version terminology. I agree that this does not make sense in this context, but in the global FreeBSD context I've seen use of it like this too. Bye, Alexander. -- Anarchy may not be the best form of government, but it's better than no government at all. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Fri Jul 15 09:58:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C891106566B for ; Fri, 15 Jul 2011 09:58:35 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id CB4518FC14 for ; Fri, 15 Jul 2011 09:58:34 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Qheju-0001I6-Bn for freebsd-fs@freebsd.org; Fri, 15 Jul 2011 12:31:18 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id DD4AD1CC21; Fri, 15 Jul 2011 12:31:17 +0300 (EEST) Date: Fri, 15 Jul 2011 12:31:17 +0300 From: Andrey Simonenko To: freebsd-fs@freebsd.org Message-ID: <20110715093117.GA1591@pm513-1.comsys.ntu-kpi.kiev.ua> References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 10-Dec-2010 16:36:10) X-Date: 2011-07-15 12:31:18 X-Connected-IP: 10.18.52.101:13414 X-Message-Linecount: 119 X-Body-Linecount: 105 X-Message-Size: 4977 X-Body-Size: 4328 Subject: Re: request for review of exports.5 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 09:58:35 -0000 On Mon, Jul 11, 2011 at 05:09:16PM -0400, Rick Macklem wrote: > Hi, > > I've added a few sentences to the exports.5 man page in an effort > to try and clarify how NFSv4 exports work. > > If anyone would like to comment on these changes, it would be > appreciated. Ideally, you are familiar with the FreeBSD /etc/exports > file, but not w.r.t. NFSv4. > > The diff is at: > http://people.freebsd.org/~rmacklem/exports.5.diff > > in case you can't handle looking at the following. (The email > system I use loves to mess with whitespace, etc.) > > Index: usr.sbin/mountd/exports.5 > =================================================================== > --- usr.sbin/mountd/exports.5 (revision 223937) > +++ usr.sbin/mountd/exports.5 (working copy) > @@ -28,7 +28,7 @@ > .\" @(#)exports.5 8.3 (Berkeley) 3/29/95 > .\" $FreeBSD$ > .\" > -.Dd December 3, 2009 > +.Dd July 11, 2011 > .Dt EXPORTS 5 > .Os > .Sh NAME > @@ -72,6 +72,12 @@ > There are three forms of this specification. > The first is to list all mount points as absolute > directory paths separated by whitespace. > +This list of directory paths should be considered an > +``administrative control'', since it only enforced by the > +.Xr mountd 8 > +daemon and not the kernel. > +As such, it only applies to NFSv2, NFSv3 mounts and only w.r.t. the > +client's use of the mount protocol. This is correct about administrative control, but these lines from the documentation do not specify that: 1) entire file system is exported and a client can guess a filehandle and can access any file in exported file system, even if administratively exported subdirectories to NFSv2/3 clients do not allow this; 2) export of nested file systems is insecure, even if a part of one file system is shadowed by another file system a user can guess a filehandle and access any file in a shadowed part; 3) if at least one of mount point components was renamed than this file system cannot be exported, since mountd uses f_mntonname value that is filled when file system is mounted. > The second is to specify the pathname of the root of the file system > followed by the > .Fl alldirs The -alldirs flag does not work as it is defined in exports(5), it worked like this before 1.84 revision of mountd.c. The idea of this flag was not only specifying administratively exported all subdirectories for NFSv2/3 clients, but this flag also specified that this pathname must be considered as a mount point. Now there is no way to specify what is a administratively exported subdirectory and what is a file system. Now if the -alldirs flag is used, then it is used for a file system. E.g. if /var is a file system and if there is line "/var/log -alldirs", then NFSv2/3 client can mount any pathname from /var. > @@ -81,8 +87,19 @@ > .Fl r > option is used on > .Xr mountd 8 . > +For NFSv4, since the ``administrative controls'' are not applied > +because NFSv4 does not use the mount protocol, > +all of the above export line(s) should be considered to have the > +.Fl alldirs > +flag, even if the line is specified without it. Since the -alldirs flag does not work as it is described in exports(5) looks like that this statement can be misunderstood. > The third form has the string ``V4:'' followed by a single absolute path > name, to specify the NFSv4 tree root. > +This line does not export any file system, but simply marks where the root > +of the server's directory tree is for NFSv4 clients. > +The exported file systems for NFSv4 are specified via the other lines > +in the > +.Xr exports 5 > +file in the same way as for NFSv2, NFSv3. > The pathnames must not have any symbolic links in them and should not have > any > .Dq Pa \&. Also I think it is necessary to add description that the -sec option works in a different way as it is defined in exports(5). According to kern/vfs_export.c security flavors are address specification property (struct netcred { netc_secflavors } and vfs_hang_addrlist() function). But when a client sends MOUNT RPC request, then mountd sends a client filehandle with security flavors that were specified last time for exported file system. This is struct exportlist { ex_secflavors } value. As a result a client's security flavors list and the kernel's security flavors list are different. From owner-freebsd-fs@FreeBSD.ORG Fri Jul 15 10:12:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAA51065670 for ; Fri, 15 Jul 2011 10:12:45 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 93D048FC18 for ; Fri, 15 Jul 2011 10:12:44 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1QhfNz-0003FZ-Gl for freebsd-fs@freebsd.org; Fri, 15 Jul 2011 13:12:43 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 2632A1CC21; Fri, 15 Jul 2011 13:12:43 +0300 (EEST) Date: Fri, 15 Jul 2011 13:12:42 +0300 From: Andrey Simonenko To: freebsd-fs@freebsd.org Message-ID: <20110715101242.GA87688@pm513-1.comsys.ntu-kpi.kiev.ua> References: <201107081310.p68DA3Nj019275@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107081310.p68DA3Nj019275@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 10-Dec-2010 16:36:10) X-Date: 2011-07-15 13:12:43 X-Connected-IP: 10.18.52.101:14723 X-Message-Linecount: 75 X-Body-Linecount: 60 X-Message-Size: 3219 X-Body-Size: 2570 Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to fail X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 10:12:45 -0000 On Fri, Jul 08, 2011 at 01:10:03PM +0000, Martin Birgmeier wrote: > The following reply was made to PR kern/131342; it has been noted by GNATS. > > From: Martin Birgmeier > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to > fail > Date: Fri, 08 Jul 2011 15:00:03 +0200 > > This is a friendly reminder that some kind soul with knowledge of the > relevant kernel parts look into this... the error can easily be > reproduced. I just had it on a 7.4 system which did heavy reading from > an 8.2 server. When I mounted something on the server, the client got a > "Permission denied" reply. > > So, to recap the scenario: > > 7.4 NFS client > 8.2 NFS server > client mounts a fs from the server (via IPv4, might be interesting to > look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/151681, too, but > that is unrelated) > client does heavy i/o on the mounted fs > server does a mount (on its side, in this case it was from an md device) > > --> error: client gets back some NFS error (in this case "permission > denied") > This is a well-known behaviour of NFS server on FreeBSD when some file system is mounted on a server part. This happens because when mount(8) mounts something it sends the SIGHUP signal to mountd(8), it then re-reads exports(5) file and loads new settings into NFS server. Since mountd(8) flushes current settings, loads new settings in a step-by-step style, all these changes are happened in nonatomic way. As a result exports settings in the NFS server are incomplete in any point of time during configuration loading or reloading. This time window allows "denied" clients to access not allowed parts of exported file systems and "allowed" clients can get access denied errors. If you are interested in this topic, you can look on the kern/136865 and my messages related to this topic (information in [3] is outdated and in [4] is very outdated): 1. NFS exports atomic and on-the-fly atomic updates http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136865 2. NFSE: new NFS exports support for FreeBSD http://nfse.sourceforge.net/ 3. NFS exports atomic and on-the-fly atomic updates http://lists.freebsd.org/pipermail/freebsd-hackers/2009-June/028782.html 4. Atomic updates of NFS export lists http://lists.freebsd.org/pipermail/freebsd-hackers/2006-April/016248.html 5. CFT: nfse compatible mode with mountd (NFS exports file) http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html From owner-freebsd-fs@FreeBSD.ORG Fri Jul 15 10:27:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7888106566C for ; Fri, 15 Jul 2011 10:27:13 +0000 (UTC) (envelope-from Martin.Birgmeier@aon.at) Received: from email.aon.at (nat-warsl417-01.aon.at [195.3.96.119]) by mx1.freebsd.org (Postfix) with ESMTP id 3123F8FC0A for ; Fri, 15 Jul 2011 10:27:12 +0000 (UTC) Received: (qmail 15662 invoked from network); 15 Jul 2011 10:27:11 -0000 Received: from smarthub96.highway.telekom.at (HELO email.aon.at) ([172.18.5.235]) (envelope-sender ) by fallback43.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 15 Jul 2011 10:27:11 -0000 Received: (qmail 26343 invoked from network); 15 Jul 2011 10:27:08 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL603.highway.telekom.at X-Spam-Level: Received: from 188-23-47-138.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([188.23.47.138]) (envelope-sender ) by smarthub96.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 15 Jul 2011 10:27:08 -0000 Received: from atpcdvvc.xyzzy (atpcdvvc.xyzzy [IPv6:fec0:0:0:4d42::84]) by gandalf.xyzzy (8.14.4/8.14.4) with ESMTP id p6FAR8ME009261 for ; Fri, 15 Jul 2011 12:27:08 +0200 (CEST) (envelope-from Martin.Birgmeier@aon.at) Message-ID: <4E2015FC.8020906@aon.at> Date: Fri, 15 Jul 2011 12:27:08 +0200 From: Martin Birgmeier User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110708 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201107081310.p68DA3Nj019275@freefall.freebsd.org> <20110715101308.GB87688@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <20110715101308.GB87688@pm513-1.comsys.ntu-kpi.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to fail X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 10:27:14 -0000 I do not think what you write has to do with the error condition I describe, for two reasons: first, mountd is only consulted while doing mounts, and the client is not doing a mount, but rather only a file access on an already mounted file system; and second, this happens when I mount a file system on the server which is not exported and thus does not cause the exports list to be changed. Regards, Martin On 07/15/11 12:13, Andrey Simonenko wrote: > On Fri, Jul 08, 2011 at 01:10:03PM +0000, Martin Birgmeier wrote: >> The following reply was made to PR kern/131342; it has been noted by GNATS. >> >> From: Martin Birgmeier >> To: bug-followup@FreeBSD.org >> Cc: >> Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to >> fail >> Date: Fri, 08 Jul 2011 15:00:03 +0200 >> >> This is a friendly reminder that some kind soul with knowledge of the >> relevant kernel parts look into this... the error can easily be >> reproduced. I just had it on a 7.4 system which did heavy reading from >> an 8.2 server. When I mounted something on the server, the client got a >> "Permission denied" reply. >> >> So, to recap the scenario: >> >> 7.4 NFS client >> 8.2 NFS server >> client mounts a fs from the server (via IPv4, might be interesting to >> look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/151681, too, but >> that is unrelated) >> client does heavy i/o on the mounted fs >> server does a mount (on its side, in this case it was from an md device) >> >> --> error: client gets back some NFS error (in this case "permission >> denied") >> > This is a well-known behaviour of NFS server on FreeBSD when some file > system is mounted on a server part. This happens because when mount(8) > mounts something it sends the SIGHUP signal to mountd(8), it then re-reads > exports(5) file and loads new settings into NFS server. Since mountd(8) > flushes current settings, loads new settings in a step-by-step style, all > these changes are happened in nonatomic way. As a result exports settings > in the NFS server are incomplete in any point of time during configuration > loading or reloading. > > This time window allows "denied" clients to access not allowed parts of > exported file systems and "allowed" clients can get access denied errors. > > If you are interested in this topic, you can look on the kern/136865 > and my messages related to this topic (information in [3] is outdated > and in [4] is very outdated): > > 1. NFS exports atomic and on-the-fly atomic updates > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136865 > > 2. NFSE: new NFS exports support for FreeBSD > http://nfse.sourceforge.net/ > > 3. NFS exports atomic and on-the-fly atomic updates > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-June/028782.html > > 4. Atomic updates of NFS export lists > http://lists.freebsd.org/pipermail/freebsd-hackers/2006-April/016248.html > > 5. CFT: nfse compatible mode with mountd (NFS exports file) > http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html > > From owner-freebsd-fs@FreeBSD.ORG Fri Jul 15 10:38:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10F731065672 for ; Fri, 15 Jul 2011 10:38:27 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 82CFF8FC16 for ; Fri, 15 Jul 2011 10:38:26 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Qhfmr-0004Ki-Hk for freebsd-fs@freebsd.org; Fri, 15 Jul 2011 13:38:25 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id B0B4B1CC21; Fri, 15 Jul 2011 13:38:25 +0300 (EEST) Date: Fri, 15 Jul 2011 13:38:25 +0300 From: Andrey Simonenko To: freebsd-fs@freebsd.org Message-ID: <20110715103825.GA88016@pm513-1.comsys.ntu-kpi.kiev.ua> References: <201107081310.p68DA3Nj019275@freefall.freebsd.org> <20110715101308.GB87688@pm513-1.comsys.ntu-kpi.kiev.ua> <4E2015FC.8020906@aon.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <4E2015FC.8020906@aon.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 10-Dec-2010 16:36:10) X-Date: 2011-07-15 13:38:25 X-Connected-IP: 10.18.52.101:59212 X-Message-Linecount: 140 X-Body-Linecount: 123 X-Message-Size: 5746 X-Body-Size: 5022 Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to fail X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 10:38:27 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 15, 2011 at 12:19:56PM +0200, Martin Birgmeier wrote: > I do not think what you write has to do with the error condition I > describe, for two reasons: first, mountd is only consulted while doing > mounts, and the client is not doing a mount, but rather only a file > access on an already mounted file system; and second, this happens when > I mount a file system on the server which is not exported and thus does > not cause the exports list to be changed. I completely understood the situation you have described. The mountd is responsible for NFSv2/3 MOUNT requests (all procedures MNT, DUMP, UMNT, UNMNTALL, EXPORT), and it is responsible for loading NFS export settings into the kernel part of NFS server. When one mounts any file system on the server, then the mount(8) utility sends SIGHUP to mountd(8), see the src/sbin/mount/mount.c:restart_mountd() function. When mountd(8) re-reads exports(5) file(s), it 1) flushes all current settings and 2) loads all new settings one-by-one. So, mountd(8) reloads all NFS export settings on each file system local mount, even if a file system is being mounted is not NFS exported. If a NFSv2/3/4 client is active on some NFS exported file system, then it will get "access denied" error, NFS export settings on a server side are incomplete. If you do not believe me, then apply attached patch to src/sbin/mount/mount.c and try to reproduce this error. ps: I send CC to freebsd-fs as a separate email, because for some reason my messages could not be delivered to freebsd-fs during last week. > > Regards, > > Martin > > On 07/15/11 12:13, Andrey Simonenko wrote: > > On Fri, Jul 08, 2011 at 01:10:03PM +0000, Martin Birgmeier wrote: > >> The following reply was made to PR kern/131342; it has been noted by GNATS. > >> > >> From: Martin Birgmeier > >> To: bug-followup@FreeBSD.org > >> Cc: > >> Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to > >> fail > >> Date: Fri, 08 Jul 2011 15:00:03 +0200 > >> > >> This is a friendly reminder that some kind soul with knowledge of the > >> relevant kernel parts look into this... the error can easily be > >> reproduced. I just had it on a 7.4 system which did heavy reading from > >> an 8.2 server. When I mounted something on the server, the client got a > >> "Permission denied" reply. > >> > >> So, to recap the scenario: > >> > >> 7.4 NFS client > >> 8.2 NFS server > >> client mounts a fs from the server (via IPv4, might be interesting to > >> look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/151681, too, but > >> that is unrelated) > >> client does heavy i/o on the mounted fs > >> server does a mount (on its side, in this case it was from an md device) > >> > >> --> error: client gets back some NFS error (in this case "permission > >> denied") > >> > > This is a well-known behaviour of NFS server on FreeBSD when some file > > system is mounted on a server part. This happens because when mount(8) > > mounts something it sends the SIGHUP signal to mountd(8), it then re-reads > > exports(5) file and loads new settings into NFS server. Since mountd(8) > > flushes current settings, loads new settings in a step-by-step style, all > > these changes are happened in nonatomic way. As a result exports settings > > in the NFS server are incomplete in any point of time during configuration > > loading or reloading. > > > > This time window allows "denied" clients to access not allowed parts of > > exported file systems and "allowed" clients can get access denied errors. > > > > If you are interested in this topic, you can look on the kern/136865 > > and my messages related to this topic (information in [3] is outdated > > and in [4] is very outdated): > > > > 1. NFS exports atomic and on-the-fly atomic updates > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136865 > > > > 2. NFSE: new NFS exports support for FreeBSD > > http://nfse.sourceforge.net/ > > > > 3. NFS exports atomic and on-the-fly atomic updates > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-June/028782.html > > > > 4. Atomic updates of NFS export lists > > http://lists.freebsd.org/pipermail/freebsd-hackers/2006-April/016248.html > > > > 5. CFT: nfse compatible mode with mountd (NFS exports file) > > http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html > > > > --NzB8fVQJ5HfG6fxh Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mount.c.diff" --- mount.c.orig 2011-07-12 13:20:43.000000000 +0300 +++ mount.c 2011-07-15 13:31:45.000000000 +0300 @@ -233,8 +233,8 @@ restart_mountd(void) return; } /* We have mountd(8) PID in mountdpid varible, let's signal it. */ - if (kill(mountdpid, SIGHUP) == -1) - err(1, "signal mountd"); +/* if (kill(mountdpid, SIGHUP) == -1) + err(1, "signal mountd");*/ } int --NzB8fVQJ5HfG6fxh-- From owner-freebsd-fs@FreeBSD.ORG Fri Jul 15 10:45:34 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21EE9106566C for ; Fri, 15 Jul 2011 10:45:34 +0000 (UTC) (envelope-from Martin.Birgmeier@aon.at) Received: from email.aon.at (smtpout01.highway.telekom.at [195.3.96.112]) by mx1.freebsd.org (Postfix) with ESMTP id 537A38FC08 for ; Fri, 15 Jul 2011 10:45:32 +0000 (UTC) Received: (qmail 15360 invoked from network); 15 Jul 2011 10:45:30 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL503.highway.telekom.at X-Spam-Level: Received: from 188-23-47-138.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([188.23.47.138]) (envelope-sender ) by smarthub95.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 15 Jul 2011 10:45:30 -0000 Received: from atpcdvvc.xyzzy (atpcdvvc.xyzzy [IPv6:fec0:0:0:4d42::84]) by gandalf.xyzzy (8.14.4/8.14.4) with ESMTP id p6FAjTBO010203; Fri, 15 Jul 2011 12:45:29 +0200 (CEST) (envelope-from Martin.Birgmeier@aon.at) Message-ID: <4E201A49.5060700@aon.at> Date: Fri, 15 Jul 2011 12:45:29 +0200 From: Martin Birgmeier User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110708 Thunderbird/5.0 MIME-Version: 1.0 To: Andrey Simonenko References: <201107081310.p68DA3Nj019275@freefall.freebsd.org> <20110715101308.GB87688@pm513-1.comsys.ntu-kpi.kiev.ua> <4E20144C.70906@aon.at> <20110715103659.GA87865@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <20110715103659.GA87865@pm513-1.comsys.ntu-kpi.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to fail X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 10:45:34 -0000 This is indeed interesting - I did not know that the exports are handled in such a simple manner both with mount(8) and within the kernel. But this in fact means that there is a major design flaw. Thank you for enlightening me. Regards, Martin On 07/15/11 12:36, Andrey Simonenko wrote: > On Fri, Jul 15, 2011 at 12:19:56PM +0200, Martin Birgmeier wrote: >> I do not think what you write has to do with the error condition I >> describe, for two reasons: first, mountd is only consulted while doing >> mounts, and the client is not doing a mount, but rather only a file >> access on an already mounted file system; and second, this happens when >> I mount a file system on the server which is not exported and thus does >> not cause the exports list to be changed. > I completely understood the situation you have described. > > The mountd is responsible for NFSv2/3 MOUNT requests (all procedures MNT, > DUMP, UMNT, UNMNTALL, EXPORT), and it is responsible for loading NFS > export settings into the kernel part of NFS server. > > When one mounts any file system on the server, then the mount(8) utility > sends SIGHUP to mountd(8), see the src/sbin/mount/mount.c:restart_mountd() > function. > > When mountd(8) re-reads exports(5) file(s), it 1) flushes all current > settings and 2) loads all new settings one-by-one. So, mountd(8) reloads > all NFS export settings on each file system local mount, even if a file > system is being mounted is not NFS exported. If a NFSv2/3/4 client is > active on some NFS exported file system, then it will get "access denied" > error, NFS export settings on a server side are incomplete. > > If you do not believe me, then apply attached patch to src/sbin/mount/mount.c > and try to reproduce this error. > > ps: I send CC to freebsd-fs as a separate email, because for some reason > my messages could not be delivered to freebsd-fs during last week. > >> Regards, >> >> Martin >> >> On 07/15/11 12:13, Andrey Simonenko wrote: >>> On Fri, Jul 08, 2011 at 01:10:03PM +0000, Martin Birgmeier wrote: >>>> The following reply was made to PR kern/131342; it has been noted by GNATS. >>>> >>>> From: Martin Birgmeier >>>> To: bug-followup@FreeBSD.org >>>> Cc: >>>> Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to >>>> fail >>>> Date: Fri, 08 Jul 2011 15:00:03 +0200 >>>> >>>> This is a friendly reminder that some kind soul with knowledge of the >>>> relevant kernel parts look into this... the error can easily be >>>> reproduced. I just had it on a 7.4 system which did heavy reading from >>>> an 8.2 server. When I mounted something on the server, the client got a >>>> "Permission denied" reply. >>>> >>>> So, to recap the scenario: >>>> >>>> 7.4 NFS client >>>> 8.2 NFS server >>>> client mounts a fs from the server (via IPv4, might be interesting to >>>> look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/151681, too, but >>>> that is unrelated) >>>> client does heavy i/o on the mounted fs >>>> server does a mount (on its side, in this case it was from an md device) >>>> >>>> --> error: client gets back some NFS error (in this case "permission >>>> denied") >>>> >>> This is a well-known behaviour of NFS server on FreeBSD when some file >>> system is mounted on a server part. This happens because when mount(8) >>> mounts something it sends the SIGHUP signal to mountd(8), it then re-reads >>> exports(5) file and loads new settings into NFS server. Since mountd(8) >>> flushes current settings, loads new settings in a step-by-step style, all >>> these changes are happened in nonatomic way. As a result exports settings >>> in the NFS server are incomplete in any point of time during configuration >>> loading or reloading. >>> >>> This time window allows "denied" clients to access not allowed parts of >>> exported file systems and "allowed" clients can get access denied errors. >>> >>> If you are interested in this topic, you can look on the kern/136865 >>> and my messages related to this topic (information in [3] is outdated >>> and in [4] is very outdated): >>> >>> 1. NFS exports atomic and on-the-fly atomic updates >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136865 >>> >>> 2. NFSE: new NFS exports support for FreeBSD >>> http://nfse.sourceforge.net/ >>> >>> 3. NFS exports atomic and on-the-fly atomic updates >>> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-June/028782.html >>> >>> 4. Atomic updates of NFS export lists >>> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-April/016248.html >>> >>> 5. CFT: nfse compatible mode with mountd (NFS exports file) >>> http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html >>> >>> From owner-freebsd-fs@FreeBSD.ORG Fri Jul 15 12:30:44 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FD01065670 for ; Fri, 15 Jul 2011 12:30:44 +0000 (UTC) (envelope-from luke@digital-crocus.com) Received: from mail.digital-crocus.com (node2.digital-crocus.com [91.209.244.128]) by mx1.freebsd.org (Postfix) with ESMTP id E4A9F8FC18 for ; Fri, 15 Jul 2011 12:30:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dkselector; d=hybrid-logic.co.uk; h=Received:Received:Subject:From:To:Cc:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Spam-Score:X-Digital-Crocus-Maillimit:X-Authenticated-Sender:X-Complaints:X-Admin:X-Abuse; b=prkmMWgEIhbVtjY6Q//xMBPvum82ShlZLy/J9yMbalQUJlymw3OI+b44B294ttlKsxagej1LXC2H+RSfrDd07N8HPCunVW4r5Y8nmDV4wNC2QVtEKG/7KSbnyyh0yvS+; Received: from luke by mail.digital-crocus.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QhhWj-000JAw-Qw for freebsd-fs@freebsd.org; Fri, 15 Jul 2011 13:29:53 +0100 Received: from vlan111.pact.srf.ac.uk ([193.37.225.200] helo=[10.0.111.134]) by mail.digital-crocus.com with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QhhWe-000J2z-QH; Fri, 15 Jul 2011 13:29:53 +0100 From: Luke Marsden To: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Fri, 15 Jul 2011 13:30:49 +0100 Message-ID: <1310733049.26698.69.camel@behemoth> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Digital-Crocus-Maillimit: done X-Authenticated-Sender: luke X-Complaints: abuse@digital-crocus.com X-Admin: admin@digital-crocus.com X-Abuse: abuse@digital-crocus.com (Please include full headers in abuse reports) Cc: tech@hybrid-logic.co.uk Subject: Experiences with ZFS v28 - including deadlock X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 12:30:44 -0000 Hi all, Having just quite extensively tested the v28 patchset contained within http://mfsbsd.vx.sk/iso/mfsbsd-se-8.2-zfsv28-amd64.iso (updated 19.06.2011) I wanted to share my experiences in the hope that the issues I encountered can be fixed before 8.3 ;-) The biggest issue was a DEADLOCK which occurs quite reliably with a given sequence of events in short succession, on a chroot filesystem with many snapshots and a MySQL socket and nullfs mounts inside it: 1. Force unmount the nullfs mounts which are mounted on top of it 2. Close the MySQL socket in /tmp 3. Force unmount the actual filesystem (even if there are open FDs) 4. 'zfs rename' the filesystem into our 'trash' filesystem (which I understand consists of a clone, promote and destroy) The entire ZFS subsystem then hangs on any new I/O. Here is a procstat of the zfs rename process which hangs after the force unmount: 25674 100871 zfs initial thread mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 txg_wait_synced+0x85 dsl_sync_task_group_wait+0x128 dsl_sync_task_do+0x54 dsl_dir_rename+0x8f dsl_dataset_rename+0x272 zfsdev_ioctl+0xe6 devfs_ioctl_f+0x7b kern_ioctl +0x102 ioctl+0xfd syscallenter+0x1e5 syscall+0x4b Xfast_syscall+0xe2 Unfortunately it's not easy to reproduce, it only seems to happen in an environment which is under load with a lot of datasets and a lot of zfs operations happening concurrently on other datasets. I spent two days trying to reproduce it in self-contained test environments but had no luck, so I'm now reporting it anyway. There were two other issues which came up: 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=157728 - we worked around this with a semaphore on 'zfs list' and 'zfs recv' so they never ran simultaneously. 2. After an incremental receive, v28 seems to like to mount the filesystem even if it was unmounted at the start of the receive. (Notably, on previous versions of ZFS, this only happened for non-incremental receives where the filesystem was being created by the receive -- incremental receives correctly left the filesystem in the mount state it started in). This plays very badly when the filesystem then gets modified before we can force unmount it (which we do immediately), because in this case the next receive operation will fail with "filesystem has modifications" - which we handle, but it's expensive to do so on every incremental receive. I had a conversation with jhell on IRC about this and he had this to say: its happened twice before with ZFS basically a lock being held and never free'd something there is happening between the snapshots and datasets though. seems that it for some reason is able to destroy the dataset before it destroys all the snapshots properly then tries to do the renaming of the snapshots and leads to a lock not being free()'d or similar Maybe this can offer a hint for someone to go looking in the right direction to solve this? Thank you for working on ZFS in FreeBSD! v15 is working very well for us. -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Mobile: +447791750420 www.hybrid-cluster.com - Cloud web hosting platform From owner-freebsd-fs@FreeBSD.ORG Fri Jul 15 22:02:28 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50533106564A for ; Fri, 15 Jul 2011 22:02:28 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id CCE718FC0C for ; Fri, 15 Jul 2011 22:02:27 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 433AF154963; Sat, 16 Jul 2011 00:02:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5YSkXkVEN8U2; Sat, 16 Jul 2011 00:02:21 +0200 (CEST) Received: from [10.9.8.3] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id C7A1C15494D; Sat, 16 Jul 2011 00:02:20 +0200 (CEST) Message-ID: <4E20B8F3.5060603@FreeBSD.org> Date: Sat, 16 Jul 2011 00:02:27 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Luke Marsden References: <1310733049.26698.69.camel@behemoth> In-Reply-To: <1310733049.26698.69.camel@behemoth> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, tech@hybrid-logic.co.uk Subject: Re: Experiences with ZFS v28 - including deadlock X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 22:02:28 -0000 Hi Luke, regarding the incremental receive, does the mount happen even if using the "-u" option to the zfs receive command? The manpage for zfs (receive section) says: -u File system that is associated with the received stream is not mounted. Cheers, mm Dňa 15. 7. 2011 14:30, Luke Marsden wrote / napísal(a): > Hi all, > > Having just quite extensively tested the v28 patchset contained within > http://mfsbsd.vx.sk/iso/mfsbsd-se-8.2-zfsv28-amd64.iso (updated > 19.06.2011) I wanted to share my experiences in the hope that the issues > I encountered can be fixed before 8.3 ;-) > > The biggest issue was a DEADLOCK which occurs quite reliably with a > given sequence of events in short succession, on a chroot filesystem > with many snapshots and a MySQL socket and nullfs mounts inside it: > > 1. Force unmount the nullfs mounts which are mounted on top of it > 2. Close the MySQL socket in /tmp > 3. Force unmount the actual filesystem (even if there are open FDs) > 4. 'zfs rename' the filesystem into our 'trash' filesystem (which I > understand consists of a clone, promote and destroy) > > The entire ZFS subsystem then hangs on any new I/O. > > Here is a procstat of the zfs rename process which hangs after the force > unmount: > > 25674 100871 zfs initial thread mi_switch+0x176 > sleepq_wait+0x42 _cv_wait+0x129 txg_wait_synced+0x85 > dsl_sync_task_group_wait+0x128 dsl_sync_task_do+0x54 dsl_dir_rename+0x8f > dsl_dataset_rename+0x272 zfsdev_ioctl+0xe6 devfs_ioctl_f+0x7b kern_ioctl > +0x102 ioctl+0xfd syscallenter+0x1e5 syscall+0x4b Xfast_syscall+0xe2 > > Unfortunately it's not easy to reproduce, it only seems to happen in an > environment which is under load with a lot of datasets and a lot of zfs > operations happening concurrently on other datasets. I spent two days > trying to reproduce it in self-contained test environments but had no > luck, so I'm now reporting it anyway. > > There were two other issues which came up: > > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=157728 - we worked > around this with a semaphore on 'zfs list' and 'zfs recv' so > they never ran simultaneously. > 2. After an incremental receive, v28 seems to like to mount the > filesystem even if it was unmounted at the start of the receive. > (Notably, on previous versions of ZFS, this only happened for > non-incremental receives where the filesystem was being created > by the receive -- incremental receives correctly left the > filesystem in the mount state it started in). This plays very > badly when the filesystem then gets modified before we can force > unmount it (which we do immediately), because in this case the > next receive operation will fail with "filesystem has > modifications" - which we handle, but it's expensive to do so on > every incremental receive. > > I had a conversation with jhell on IRC about this and he had this to > say: > > its happened twice before with ZFS basically a lock being held > and never free'd > something there is happening between the snapshots and datasets > though. seems that it for some reason is able to destroy the dataset > before it destroys all the snapshots properly > then tries to do the renaming of the snapshots and leads to a > lock not being free()'d or similar > > Maybe this can offer a hint for someone to go looking in the right > direction to solve this? > > Thank you for working on ZFS in FreeBSD! v15 is working very well for > us. > -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Sat Jul 16 14:20:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFFFD106566C for ; Sat, 16 Jul 2011 14:20:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 967238FC1A for ; Sat, 16 Jul 2011 14:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6GEKAh3072416 for ; Sat, 16 Jul 2011 14:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6GEKAL2072415; Sat, 16 Jul 2011 14:20:10 GMT (envelope-from gnats) Date: Sat, 16 Jul 2011 14:20:10 GMT Message-Id: <201107161420.p6GEKAL2072415@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 14:20:10 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, mm@FreeBSD.org Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Sat, 16 Jul 2011 16:13:12 +0200 I have debugged this a little and have now more information. The snapshot is set for deferred destroy but the temporary clone does not get deleted, because of an extra hold: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c: #3558, zfs_ioc_recv(): end_err = dmu_recv_end(&drc); sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c: #1621, dmu_recv_end(): return (dmu_recv_existing_end(drc)); sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c: #1581, dmu_recv_existing_end(): (void) dsl_dataset_destroy(drc->drc_real_ds, dmu_recv_tag, B_FALSE); This dataset does not get destroyed , error EBUSY. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c: #1158, dsl_dataset_destroy(): dstg = dsl_sync_task_group_create(ds->ds_dir->dd_pool); dsl_sync_task_create(dstg, dsl_dataset_destroy_check, dsl_dataset_destroy_sync, &dsda, tag, 0); dsl_sync_task_create(dstg, dsl_dir_destroy_check, dsl_dir_destroy_sync, &dummy_ds, FTAG, 0); err = dsl_sync_task_group_wait(dstg); dsl_sync_task_group_destroy(dstg); dsl_sync_task_group_wait() calls: - dsl_dataset_destroy_check (returns 0) - dsl_dir_destroy_check (returns EBUSY, should return 0) <-- error comes from here sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c: #466, dsl_dir_destroy_check(): if (dmu_buf_refcount(dd->dd_dbuf) > 2) return (EBUSY); <--- EBUSY comes from here sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c: #2101 #pragma weak dmu_buf_refcount = dbuf_refcount uint64_t dbuf_refcount(dmu_buf_impl_t *db) { return (refcount_count(&db->db_holds)); } If we issue zfs list or zfs get (recursive or on the dataset) the db->db_holds for the clone has a value of 3, otherwise a value of 2. With 3, destroying the temporary clone fails and deferred destroy of the snapshot fails, too. Looks like a extra hold is placed on the temporary clone. -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Sat Jul 16 22:03:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE3E106566B for ; Sat, 16 Jul 2011 22:03:14 +0000 (UTC) (envelope-from jorgen.ness@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 413D48FC0A for ; Sat, 16 Jul 2011 22:03:13 +0000 (UTC) Received: by ywf7 with SMTP id 7so1139037ywf.13 for ; Sat, 16 Jul 2011 15:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=rejwceHugA0sjTTjUOfFXkLLVDHhQmm7JoGKcu7NJOM=; b=qGLTv/w7c8wyJRwNbs+c3ZC7XdQjEHRd/LA15TIYe6c43Fiw7kyEkotdkAQwA2x8rm NVq2Q9iChIXmTYBY3hAkTHIOPhTKb0ERBEddx2wsvG1gCBNiNuY/e9bXEg0AxlyWgDa6 XEm63NQHOVP08m9l+m3f4uTVPn9+c5p5fjTgk= MIME-Version: 1.0 Received: by 10.151.11.4 with SMTP id o4mr3765730ybi.99.1310852021672; Sat, 16 Jul 2011 14:33:41 -0700 (PDT) Received: by 10.151.99.15 with HTTP; Sat, 16 Jul 2011 14:33:41 -0700 (PDT) Date: Sat, 16 Jul 2011 23:33:41 +0200 Message-ID: From: =?ISO-8859-1?Q?J=F8rgen_Dovregubbe_N=E6ss?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFS v13 running vicious replacement loop. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 22:03:14 -0000 Hi. Im running freeNAS v.0.7.2 with zfs v3 and zpool v13. I was trying to upgrade my raidz1 from 1 TB drives to 2TB drives, replacing 1 drive at a time. here's the current layout: freenas:~# zpool status pool: guitar state: DEGRADED scrub: resilver completed after 0h0m with 0 errors on Sat Jul 16 17:19:48 2011 config: NAME STATE READ WRITE CKSUM guitar DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 replacing DEGRADED 0 25 4 ad4.nop ONLINE 0 0 0 88K resilvered 9203819577564534483 FAULTED 0 0 0 was /dev/ad4.nop ad6.nop ONLINE 0 0 0 96K resilvered ad8.nop ONLINE 0 0 0 100K resilvered ad10.nop ONLINE 0 0 0 96K resilvered ad16.nop ONLINE 0 0 0 124K resilvered ad18.nop ONLINE 0 0 0 116K resilvered spares da1 AVAIL errors: No known data errors Without taking ad4.nop offline, i turned the machine off, replaced the drive, and did a "zpool replace guitar ad4.nop ad4" It started replacing the drive, but got I/o write and read errors, so it restarted (happened like 30 times per minute). I have tried everything. zpool replace guitar ad4.nop /dev/da1 (can't replace because already being replaced) zpool offline guitar ad4.nop (no valid replicas) zpool offline guitar 9203819577564534483 (no valid replicas) zpool clear guitar ad4.nop zpool export / import (thus the 9203819577564534483, it said ad4.nop before= ) The spare was added later to try and put that in instead of ad4.nop, withou= t luck. The box only have 6 sata ports, so I am unable to connect the drive i was trying to replace ad4.nop with. I do have another computer that i could use as a temp server, but that one also has 6 sata ports. The next raidz1 will be with only 5 drives, and 1 spare ( so i dont have to meet this problem again) The problem now is, that i can't access the files that are on the NAS, thus being unable to do a backup of it. ( I can transfer like a coulple of GB, then the whole box gets unreachable (web, ssh ftp). Any Idea how to solve this? Best Regards J=F8rgen