From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 00:54:11 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 486FE106567E; Sun, 23 Sep 2012 00:54:11 +0000 (UTC) (envelope-from prvs=161333704c=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 A2F9F8FC1E; Sun, 23 Sep 2012 00:54:09 +0000 (UTC) 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 md50000185122.msg; Sun, 23 Sep 2012 01:53:55 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 23 Sep 2012 01:53:55 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=161333704c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <619BCDAEA81C4653B55E700EC31F9CEB@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , References: <505DE715.8020806@FreeBSD.org> Date: Sun, 23 Sep 2012 01:53:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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.6157 Cc: Subject: Re: allow to mount root from a pool not in zpool.cache 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, 23 Sep 2012 00:54:11 -0000 ----- Original Message ----- From: "Andriy Gapon" > Currently FreeBSD ZFS kernel code doesn't allow to mount root filesystem on a > pool that is not listed in zpool.cache as only pools from the cache are known to > ZFS at that time. > > This patch is an attempt to improve the behavior: > http://people.freebsd.org/~avg/spa_import_rootpool.diff > > This could be useful when importing pools that were exported from other systems. > There is a tunable vfs.zfs.rootpool.prefer_cached_config which is set to 1 by > default. 1 means just use a cached pool config if it's found in the cache, 0 > means to re-probe disks and read supposedly latest/actual config in any case. This sounds like a great idea, thanks for the work will look to test it over the coming weeks. 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 Sun Sep 23 01:04:51 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AD10106566B; Sun, 23 Sep 2012 01:04:51 +0000 (UTC) (envelope-from prvs=161333704c=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 DB8D28FC0A; Sun, 23 Sep 2012 01:04:49 +0000 (UTC) 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 md50000185296.msg; Sun, 23 Sep 2012 02:04:47 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 23 Sep 2012 02:04:47 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=161333704c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <80F518854AE34A759D9441AE1A60D2DC@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , References: <505DF1A3.1020809@FreeBSD.org> Date: Sun, 23 Sep 2012 02:04:39 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02EE_01CD992F.CA115AA0" 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.6157 Cc: freebsd-geom@FreeBSD.org Subject: Re: zfs zvol: set geom mediasize right at creation time 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, 23 Sep 2012 01:04:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02EE_01CD992F.CA115AA0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Andriy Gapon" > Please review the following patch. > > In addition to what the description says I almost by accident sneaked another > change into the patch. It's setting of stripesize to volblocksize. I think > that the change should make sense, but it is really a different change. > > > A side note: setting sectorsize to volblocksize seemed like an overkill and it > would certainly mess the existing zvols in use. Maybe there should be another > property like reportedblocksize or something. > > commit 1585e6cfb602c2a2647b9f802445bb174bc430a4 > Author: Andriy Gapon > Date: Wed Sep 19 20:49:28 2012 +0300 > > zvol: set mediasize in geom provider right upon its creation > > ... instead of deferring the action until first open. > Unlike upstream this has no benefit on FreeBSD. > We know that as soon as the provider is created it is going to be tasted > and thus opened. Initial mediasize of zero causes tasting failure > and subsequent retasting because of the size change. > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c > b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c > index d47d270..6e9e7a3 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c > @@ -475,6 +475,7 @@ zvol_create_minor(const char *name) > zvol_state_t *zv; > objset_t *os; > dmu_object_info_t doi; > + uint64_t volblocksize, volsize; > int error; > > ZFS_LOG(1, "Creating ZVOL %s...", name); > @@ -535,9 +536,20 @@ zvol_create_minor(const char *name) > zv = zs->zss_data = kmem_zalloc(sizeof (zvol_state_t), KM_SLEEP); > #else /* !sun */ > > + error = zap_lookup(os, ZVOL_ZAP_OBJ, "size", 8, 1, &volsize); > + if (error) { > + ASSERT(error == 0); > + dmu_objset_disown(os, zvol_tag); > + mutex_exit(&spa_namespace_lock); > + return (error); > + } > + > DROP_GIANT(); > g_topology_lock(); > zv = zvol_geom_create(name); > + zv->zv_volsize = volsize; > + zv->zv_provider->mediasize = zv->zv_volsize; > + > #endif /* !sun */ > > (void) strlcpy(zv->zv_name, name, MAXPATHLEN); > @@ -554,6 +566,7 @@ zvol_create_minor(const char *name) > error = dmu_object_info(os, ZVOL_OBJ, &doi); > ASSERT(error == 0); > zv->zv_volblocksize = doi.doi_data_block_size; > + zv->zv_provider->stripesize = zv->zv_volblocksize; > > if (spa_writeable(dmu_objset_spa(os))) { > if (zil_replay_disable) Do you know what the effect of the volblocksize change will have on a volume who's disk block size changes? e.g. via a quirk for a 4k disk being added I ask as we've testing a patch here which changes ashift to be based on stripesize instead of sectorsize but in its current form it has some odd side effects on pools which are boot pools. Said patch is attached for reference. 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. ------=_NextPart_000_02EE_01CD992F.CA115AA0 Content-Type: text/plain; format=flowed; name="zfs-ashift-fix.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfs-ashift-fix.txt" Changes zfs zpool initial / desired ashift to be based off stripesize=0A= instead of sectorsize making it compatible with drives marked with=0A= the 4k sector size quirk.=0A= =0A= Without the correct min block size BIO_DELETE requests passed to=0A= a large number of current SSD's via TRIM don't actually perform=0A= any LBA TRIM so its vital for the correct operation of TRIM to get=0A= the correct min block size.=0A= =0A= To do this we added the additional dashift (desired ashift) to=0A= vdev_open_func_t calls. This was needed as just updating ashift to=0A= be based off stripesize would mean that a devices reported minimum=0A= transfer size (ashift) could increase and that in turn would cause=0A= member devices to be unusable and hence break pools with error=0A= ZFS-8000-5E.=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h.orig = 2012-07-03 11:48:22.353483879 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h = 2012-07-03 11:59:17.195442033 +0000=0A= @@ -55,7 +55,7 @@=0A= /*=0A= * Virtual device operations=0A= */=0A= -typedef int vdev_open_func_t(vdev_t *vd, uint64_t *size, uint64_t = *ashift);=0A= +typedef int vdev_open_func_t(vdev_t *vd, uint64_t *size, uint64_t = *ashift, uint64_t *dashift);=0A= typedef void vdev_close_func_t(vdev_t *vd);=0A= typedef uint64_t vdev_asize_func_t(vdev_t *vd, uint64_t psize);=0A= typedef int vdev_io_start_func_t(zio_t *zio);=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c.orig = 2012-07-03 12:53:37.716867380 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c 2012-07-03 = 12:01:58.522455031 +0000=0A= @@ -1122,6 +1122,7 @@=0A= uint64_t osize =3D 0;=0A= uint64_t asize, psize;=0A= uint64_t ashift =3D 0;=0A= + uint64_t dashift =3D 0;=0A= =0A= ASSERT(vd->vdev_open_thread =3D=3D curthread ||=0A= spa_config_held(spa, SCL_STATE_ALL, RW_WRITER) =3D=3D = SCL_STATE_ALL);=0A= @@ -1151,7 +1152,7 @@=0A= return (ENXIO);=0A= }=0A= =0A= - error =3D vd->vdev_ops->vdev_op_open(vd, &osize, &ashift);=0A= + error =3D vd->vdev_ops->vdev_op_open(vd, &osize, &ashift, &dashift);=0A= =0A= /*=0A= * Reset the vdev_reopening flag so that we actually close=0A= @@ -1251,7 +1252,7 @@=0A= * For testing purposes, a higher ashift can be requested.=0A= */=0A= vd->vdev_asize =3D asize;=0A= - vd->vdev_ashift =3D MAX(ashift, vd->vdev_ashift);=0A= + vd->vdev_ashift =3D MAX(MAX(ashift, dashift), vd->vdev_ashift);=0A= } else {=0A= /*=0A= * Make sure the alignment requirement hasn't increased.=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_disk.c.orig = 2012-07-03 11:49:34.103219588 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_disk.c = 2012-07-03 12:51:44.521525471 +0000=0A= @@ -103,7 +103,7 @@=0A= }=0A= =0A= static int=0A= -vdev_disk_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift)=0A= +vdev_disk_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift, uint64_t = *dashift)=0A= {=0A= spa_t *spa =3D vd->vdev_spa;=0A= vdev_disk_t *dvd;=0A= @@ -284,7 +284,7 @@=0A= }=0A= =0A= /*=0A= - * Determine the device's minimum transfer size.=0A= + * Determine the device's minimum and desired transfer size.=0A= * If the ioctl isn't supported, assume DEV_BSIZE.=0A= */=0A= if (ldi_ioctl(dvd->vd_lh, DKIOCGMEDIAINFOEXT, (intptr_t)&dkmext,=0A= @@ -292,6 +292,7 @@=0A= dkmext.dki_pbsize =3D DEV_BSIZE;=0A= =0A= *ashift =3D highbit(MAX(dkmext.dki_pbsize, SPA_MINBLOCKSIZE)) - 1;=0A= + *dashift =3D *ashift;=0A= =0A= /*=0A= * Clear the nowritecache bit, so that on a vdev_reopen() we will=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c.orig = 2012-07-03 11:48:42.314740333 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c = 2012-07-03 11:57:22.579381320 +0000=0A= @@ -47,7 +47,7 @@=0A= }=0A= =0A= static int=0A= -vdev_file_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift)=0A= +vdev_file_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift, uint64_t = *dashift)=0A= {=0A= vdev_file_t *vf;=0A= vnode_t *vp;=0A= @@ -127,6 +127,7 @@=0A= =0A= *psize =3D vattr.va_size;=0A= *ashift =3D SPA_MINBLOCKSHIFT;=0A= + *dashift =3D SPA_MINBLOCKSHIFT;=0A= =0A= return (0);=0A= }=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c.orig = 2012-07-03 12:50:50.158161825 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c = 2012-07-03 12:52:01.408085155 +0000=0A= @@ -416,7 +416,7 @@=0A= }=0A= =0A= static int=0A= -vdev_geom_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift)=0A= +vdev_geom_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift, uint64_t = *dashift)=0A= {=0A= struct g_provider *pp;=0A= struct g_consumer *cp;=0A= @@ -502,9 +502,10 @@=0A= *psize =3D pp->mediasize;=0A= =0A= /*=0A= - * Determine the device's minimum transfer size.=0A= + * Determine the device's minimum and desired transfer size.=0A= */=0A= *ashift =3D highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1;=0A= + *dashift =3D highbit(MAX(pp->stripesize, SPA_MINBLOCKSIZE)) - 1;=0A= =0A= /*=0A= * Clear the nowritecache settings, so that on a vdev_reopen()=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c.orig = 2012-07-03 11:49:22.342245151 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c = 2012-07-03 11:58:02.161948585 +0000=0A= @@ -127,7 +127,7 @@=0A= }=0A= =0A= static int=0A= -vdev_mirror_open(vdev_t *vd, uint64_t *asize, uint64_t *ashift)=0A= +vdev_mirror_open(vdev_t *vd, uint64_t *asize, uint64_t *ashift, = uint64_t *dashift)=0A= {=0A= int numerrors =3D 0;=0A= int lasterror =3D 0;=0A= @@ -150,6 +150,7 @@=0A= =0A= *asize =3D MIN(*asize - 1, cvd->vdev_asize - 1) + 1;=0A= *ashift =3D MAX(*ashift, cvd->vdev_ashift);=0A= + *dashift =3D *ashift;=0A= }=0A= =0A= if (numerrors =3D=3D vd->vdev_children) {=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_missing.c.orig = 2012-07-03 11:49:10.545275865 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_missing.c = 2012-07-03 11:58:07.670470640 +0000=0A= @@ -40,7 +40,7 @@=0A= =0A= /* ARGSUSED */=0A= static int=0A= -vdev_missing_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift)=0A= +vdev_missing_open(vdev_t *vd, uint64_t *psize, uint64_t *ashift, = uint64_t *dashift)=0A= {=0A= /*=0A= * Really this should just fail. But then the root vdev will be in the=0A= @@ -50,6 +50,7 @@=0A= */=0A= *psize =3D 0;=0A= *ashift =3D 0;=0A= + *dashift =3D 0;=0A= return (0);=0A= }=0A= =0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c.orig = 2012-07-03 11:49:03.675875505 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c = 2012-07-03 11:58:15.334806334 +0000=0A= @@ -1447,7 +1447,7 @@=0A= }=0A= =0A= static int=0A= -vdev_raidz_open(vdev_t *vd, uint64_t *asize, uint64_t *ashift)=0A= +vdev_raidz_open(vdev_t *vd, uint64_t *asize, uint64_t *ashift, uint64_t = *dashift)=0A= {=0A= vdev_t *cvd;=0A= uint64_t nparity =3D vd->vdev_nparity;=0A= @@ -1476,6 +1476,7 @@=0A= =0A= *asize =3D MIN(*asize - 1, cvd->vdev_asize - 1) + 1;=0A= *ashift =3D MAX(*ashift, cvd->vdev_ashift);=0A= + *dashift =3D *ashift;=0A= }=0A= =0A= *asize *=3D vd->vdev_children;=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_root.c.orig = 2012-07-03 11:49:27.901760380 +0000=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_root.c = 2012-07-03 11:58:19.704427068 +0000=0A= @@ -50,7 +50,7 @@=0A= }=0A= =0A= static int=0A= -vdev_root_open(vdev_t *vd, uint64_t *asize, uint64_t *ashift)=0A= +vdev_root_open(vdev_t *vd, uint64_t *asize, uint64_t *ashift, uint64_t = *dashift)=0A= {=0A= int lasterror =3D 0;=0A= int numerrors =3D 0;=0A= @@ -78,6 +78,7 @@=0A= =0A= *asize =3D 0;=0A= *ashift =3D 0;=0A= + *dashift =3D 0;=0A= =0A= return (0);=0A= }=0A= ------=_NextPart_000_02EE_01CD992F.CA115AA0-- From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 04:59:57 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A39DE106566C; Sun, 23 Sep 2012 04:59:57 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 732138FC14; Sun, 23 Sep 2012 04:59:57 +0000 (UTC) Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q8N4xuU3070517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Sep 2012 22:59:56 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: "Justin T. Gibbs" In-Reply-To: <505DE715.8020806@FreeBSD.org> Date: Sat, 22 Sep 2012 22:59:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <505DE715.8020806@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1498) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [192.168.0.4]); Sat, 22 Sep 2012 22:59:56 -0600 (MDT) Cc: freebsd-fs@freebsd.org Subject: Re: zfs: allow to mount root from a pool not in zpool.cache 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, 23 Sep 2012 04:59:57 -0000 On Sep 22, 2012, at 10:28 AM, Andriy Gapon wrote: >=20 > Currently FreeBSD ZFS kernel code doesn't allow to mount root = filesystem on a > pool that is not listed in zpool.cache as only pools from the cache = are known to > ZFS at that time. I've for some time been of the opinion that FreeBSD should only use the cache file for ZFS pools created from non-GEOM objects (i.e. files). GEOM tasting should be used to make the kernel aware of all pools whether they be imported on the system, partial, or foreign. Even for pools created by files, the user land utilities should do nothing more than ask the kernel to "taste them". This would remove code duplicated in user land for this task (code that must be re-executed in kernel space for validation reasons anyway) and also help solve problems we've encountered at Spectra with races in fault event processing, spare management, and device arrival and departures. So I'm excited by your work in this area and would encourage you to "think larger" than just trying to integrate root pool discovery with GEOM. Spectra may even be able to help in this work sometime in the near future. -- Justin From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 12:34:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63DEA106567B; Sun, 23 Sep 2012 12:34:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id A34C08FC1E; Sun, 23 Sep 2012 12:33:59 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so6892399lbb.13 for ; Sun, 23 Sep 2012 05:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Yt/igrYH/e7k0e+89CIJa5hTDgtuHm+Gb/QnCz7ZGgw=; b=bvp0eKTlNNaLHwjU2UaxYIZCbMR657sKYuzs1pBHDovVYWdxVRdAt2DqMdttMP/KvL ReLl8I/YkKwh/6XjtUtDHXsIzBAGHGQz9TH3JM3w8Yx/l4/YATbT5dEj3j1px4Lfn7c0 J0VbujqRvQy0EC8K6S6zUL3UCU+zPrW8TuOZpGyE/h/erExgmUEsHZzDmoxZLIuHQ3ve H32SXXREK7IH7HXgRSt6bOfCw8l625cPNICLzEx8TZjf8eewyFTgxkfb4dUR4X4c3tFg GybaAfMh5Gj681sMB/ootmjiMMRSR+U7/rkGaT6B67tpWgRrAHvwFj23QX8G1nj7C6xU mm1w== Received: by 10.152.104.77 with SMTP id gc13mr8413590lab.31.1348403638134; Sun, 23 Sep 2012 05:33:58 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id d1sm3550533lbh.7.2012.09.23.05.33.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Sep 2012 05:33:57 -0700 (PDT) Sender: Alexander Motin Message-ID: <505F01B2.3080709@FreeBSD.org> Date: Sun, 23 Sep 2012 15:33:54 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <505DE566.2080307@FreeBSD.org> In-Reply-To: <505DE566.2080307@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: lszfs command for loader 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, 23 Sep 2012 12:34:00 -0000 On 22.09.2012 19:20, Andriy Gapon wrote: > Please find a patch that implements lszfs loader command. > The command can list child filesystems of a specified filesystem (including root > dataset). > The command is really simplistic, a list goes directly to console, so there is > no filtering of hidden filesystem names etc. > > The command is intended to facilitate recovery on systems that use "Boot > Environments" approach for boot/root filesystem. > > http://people.freebsd.org/~avg/lszfs.diff That is good for the beginning, but I believe it is not right to add ZFS-specific commands when it is possible to avoid it. I would prefer to see lsdev report ZFS file systems same as it reports disk partitions or ZFS pools. I am going to work in that part. Also I would like to see lsdev output refactored to be formal enough to use these data in loader menu. After some look on forth code I see no big problem to pass data there. All we need to do is to extend device API of libstand with some method replacing dv_print() with something more alike to readdir(). -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 16:08:53 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BB11065674 for ; Sun, 23 Sep 2012 16:08:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8E03D8FC0C for ; Sun, 23 Sep 2012 16:08:51 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q8NG8xum073710; Sun, 23 Sep 2012 19:08:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q8NG8lSH098805; Sun, 23 Sep 2012 19:08:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q8NG8llU098804; Sun, 23 Sep 2012 19:08:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 23 Sep 2012 19:08:47 +0300 From: Konstantin Belousov To: Rick Macklem Message-ID: <20120923160847.GN37286@deviant.kiev.zoral.com.ua> References: <20120921080516.GC37286@deviant.kiev.zoral.com.ua> <1697573610.1030942.1348267121541.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PrbR2RMKSe7tzlp9" Content-Disposition: inline In-Reply-To: <1697573610.1030942.1348267121541.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FS List Subject: Re: testing/review of atomic export update patch 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, 23 Sep 2012 16:08:53 -0000 --PrbR2RMKSe7tzlp9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 06:38:41PM -0400, Rick Macklem wrote: > Konstantin Belousov wrote: > > On Thu, Sep 20, 2012 at 05:55:26PM -0400, Rick Macklem wrote: > > > Konstantin Belousov wrote: > > > > On Tue, Sep 18, 2012 at 09:34:54AM -0400, Rick Macklem wrote: > > > > > Konstantin Belousov wrote: > > > > > > On Mon, Sep 17, 2012 at 05:32:44PM -0400, Rick Macklem wrote: > > > > > > > Konstantin Belousov wrote: > > > > > > > > On Sun, Sep 16, 2012 at 05:41:25PM -0400, Rick Macklem > > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > There is a simple patch at: > > > > > > > > > http://people.freebsd.org/~rmacklem/atomic-export.patch > > > > > > > > > that can be applied to a kernel + mountd, so that the > > > > > > > > > new > > > > > > > > > nfsd can be suspended by mountd while the exports are > > > > > > > > > being > > > > > > > > > reloaded. It adds a new "-S" flag to mountd to enable > > > > > > > > > this. > > > > > > > > > (This avoids the long standing bug where clients receive > > > > > > > > > ESTALE > > > > > > > > > replies to RPCs while mountd is reloading exports.) > > > > > > > > > > > > > > > > This looks simple, but also somewhat worrisome. What would > > > > > > > > happen > > > > > > > > if the mountd crashes after nfsd suspension is requested, > > > > > > > > but > > > > > > > > before > > > > > > > > resume was performed ? > > > > > > > > > > > > > > > > Might be, mountd should check for suspended nfsd on start > > > > > > > > and > > > > > > > > unsuspend > > > > > > > > it, if some flag is specified ? > > > > > > > Well, I think that happens with the patch as it stands. > > > > > > > > > > > > > > suspend is done if the "-S" option is specified, but that is > > > > > > > a > > > > > > > no op > > > > > > > if it is already suspended. The resume is done no matter > > > > > > > what > > > > > > > flags > > > > > > > are provided, so mountd will always try and do a "resume". > > > > > > > --> get_exportlist() is always called when mountd is started > > > > > > > up > > > > > > > and > > > > > > > it does the resume unconditionally when it completes. > > > > > > > If mountd repeatedly crashes before completing > > > > > > > get_exportlist() > > > > > > > when it is started up, the exports will be all messed > > > > > > > up, so > > > > > > > having the nfsd threads suspended doesn't seem so bad > > > > > > > for > > > > > > > this > > > > > > > case (which hopefully never happens;-). > > > > > > > > > > > > > > Both suspend and resume are just no ops for unpatched > > > > > > > kernels. > > > > > > > > > > > > > > Maybe the comment in front of "resume" should explicitly > > > > > > > explain > > > > > > > this, instead of saying resume is harmless to do under all > > > > > > > conditions? > > > > > > > > > > > > > > Thanks for looking at it, rick > > > > > > I see. > > > > > > > > > > > > My another note is that there is no any protection against > > > > > > parallel > > > > > > instances of suspend/resume happen. For instance, one thread > > > > > > could > > > > > > set > > > > > > suspend_nfsd =3D 1 and be descheduled, while another executes > > > > > > resume > > > > > > code sequence meantime. Then it would see suspend_nfsd !=3D 0, > > > > > > while > > > > > > nfsv4rootfs_lock not held, and tries to unlock it. It seems > > > > > > that > > > > > > nfsv4_unlock would silently exit. The suspending thread > > > > > > resumes, > > > > > > and obtains the lock. You end up with suspend_nfsd =3D=3D 0 but > > > > > > lock > > > > > > held. > > > > > Yes. I had assumed that mountd would be the only thing using > > > > > these > > > > > syscalls > > > > > and it is single threaded. (The syscalls can only be done by > > > > > root > > > > > for the > > > > > obvious reasons.;-) > > > > > > > > > > Maybe the following untested version of the syscalls would be > > > > > better, since > > > > > they would allow multiple concurrent calls to either suspend or > > > > > resume. > > > > > (There would still be an indeterminate case if one thread called > > > > > resume > > > > > concurrently with another few calling suspend, but that is > > > > > unavoidable, > > > > > I think?) > > > > > > > > > > Again, thanks for the comments, rick > > > > > --- untested version of syscalls --- > > > > > } else if ((uap->flag & NFSSVC_SUSPENDNFSD) !=3D 0) { > > > > > NFSLOCKV4ROOTMUTEX(); > > > > > if (suspend_nfsd =3D=3D 0) { > > > > > /* Lock out all nfsd threads */ > > > > > igotlock =3D 0; > > > > > while (igotlock =3D=3D 0 && suspend_nfsd =3D=3D 0) { > > > > > igotlock =3D nfsv4_lock(&nfsv4rootfs_lock, 1, > > > > > NULL, NFSV4ROOTLOCKMUTEXPTR, NULL); > > > > > } > > > > > suspend_nfsd =3D 1; > > > > > } > > > > > NFSUNLOCKV4ROOTMUTEX(); > > > > > error =3D 0; > > > > > } else if ((uap->flag & NFSSVC_RESUMENFSD) !=3D 0) { > > > > > NFSLOCKV4ROOTMUTEX(); > > > > > if (suspend_nfsd !=3D 0) { > > > > > nfsv4_unlock(&nfsv4rootfs_lock, 0); > > > > > suspend_nfsd =3D 0; > > > > > } > > > > > NFSUNLOCKV4ROOTMUTEX(); > > > > > error =3D 0; > > > > > } > > > > > > > > From the cursory look, this variant is an improvement, mostly by > > > > taking > > > > the interlock before testing suspend_nfsd, and using the while > > > > loop. > > > > > > > > Is it possible to also make the sleep for the lock interruptible ? > > > > So that blocked mountd could be killed by a signal ? > > > Well, it would require some coding. An extra argument to > > > nfsv4_lock() > > > to indicate to do so and then either the caller would have to check > > > for a pending termination signal when it returns 0 (indicates didn't > > > get > > > lock) or a new return value to indicate EINTR. The latter would > > > require > > > all the calls to it to be changed to recognize the new 3rd return > > > case. > > > Because there are a lot of these calls, I'd tend towards just having > > > the > > > caller check for a pending signal. > > > > > > Not sure if it would make much difference though. The only time it > > > would get stuck in nfsv4_lock() is if the nfsd threads are all > > > wedged > > > and in that case having mountd wedged too probably doesn't make much > > > difference, since the NFS service is toast in that case anyhow. > > > > > > If you think it is worth doing, I can add that. I basically see this > > > as a "stop-gap" fix until such time as something like nfse is done, > > > but since I haven't the time to look at nfse right now, I have no > > > idea when/if that might happen. > >=20 > > Ok, please go ahead with the patch. Having the patch even in its > > current > > form is obviously better then not to have it. If the wedged mountd > > appears to be annoying enough for me, I would do the change. > >=20 > > Thanks. > Oops, I spoke too soon. When I took a look at the code, I realized that > having nfsv4_lock() return when a pending signal interrupts the msleep() > isn't easy. As such, I think I'll leave it out of the patch for now. >=20 > For those who find these things interesting, the reason the above is > hard is the funny intentional semantics that nfsv4_lock() implements. > Most of the time, the nfsd threads can concurrently handle the NFSv4 > state structures, using a mutex to serialize access to the lists and > never sleeping while doing so. However, there are a few case (mainly > delegation recall) where sleeping and knowing that no other thread > is modifying the lists is necessary. >=20 > As such, nfsv4_lock() will be called by potentially many nfsd threads > (up to 200+) wanting this exclusive sleep lock. However, it is coded > so that only the first one that wakes up after the shared locks (I call > it a ref count in the code) have been released, gets the exclusive > lock. The rest of the threads wake up after the first thread releases > the exclusive lock, but simply return without getting the lock. > This avoids up to 200+ threads getting the exclusive lock in turn and > then going "oh, I don't need it since that other thread already got > the work done" so it releases the exclusive lock and gets a shared one. > (It also implements the exclusive lock as having priority over the shared > lock request, so that nfsv4_lock() won't wait indefinitely for the > exclusive lock.) >=20 > The above is done by having the first thread that wakes up once the > shared locks are released clear the "want an exclusive lock" flag > as it acquires it. >=20 > If a call were to return due to a signal, it wouldn't know if it > should clear the "want an exclusive lock" flag or not, since it > wouldn't know if other threads currently want it or not. My take is that the thread which got EINTR from msleep() shall not clear the flag. It shall not get the lock anyway. >=20 > This could probably be fixed by adding a count of how many threads > are currently sleeping, waiting for the "want an exclusive flag", > but that's too scary for me to do, unless it really is needed. > (As you might have guessed, it's pretty easy to break this in > subtle ways and I'm a chicken;-) BTW, nfsv4_lock/unlock desperately need assertion that the mutex is locked on entry. --PrbR2RMKSe7tzlp9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBfNA8ACgkQC3+MBN1Mb4jt7ACfQF8T8mGYITcgjY8xZ3AMa4IC baIAoI4aUZ+bsFElAdjwcjhvfey2cLPW =u6Ci -----END PGP SIGNATURE----- --PrbR2RMKSe7tzlp9-- From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 19:53:49 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5839C106566B; Sun, 23 Sep 2012 19:53:49 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8FE8FC0A; Sun, 23 Sep 2012 19:53:48 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id BAE75F94; Sun, 23 Sep 2012 21:52:49 +0200 (CEST) Date: Sun, 23 Sep 2012 21:53:58 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20120923195357.GO1454@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/DkgDsqJFFamjKX0" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: ZFS TRIM support committed to HEAD. 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, 23 Sep 2012 19:53:49 -0000 --/DkgDsqJFFamjKX0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FYI, I just committed TRIM support to ZFS, especially useful for SSD-only pools. This is something I implemented long time ago, but was now motivated to get back to it and commit it finally by some great fixes and improvements from the zfsonlinux project (made by Etienne Dechamps). Note that this functionality is turned off by default for now. To turn it on you need to add vfs.zfs.trim_disable=3D0 to /boot/loader.conf. You can see some statistics under kstat.zfs.misc.zio_trim sysctl. Big thanks to multiplay.co.uk for sponsoring this work! BTW. If you find this useful, so tell me about it during EuroBSDcon 2012 in a month that will be held this year in Warsaw, Poland: http://eurobsdcon.org :) On Sun, Sep 23, 2012 at 07:40:58PM +0000, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Sun Sep 23 19:40:58 2012 > New Revision: 240868 > URL: http://svn.freebsd.org/changeset/base/240868 >=20 > Log: > Add TRIM support. > =20 > The code builds a map of regions that were freed. On every write the > code consults the map and eventually removes ranges that were freed > before, but are now overwritten. > =20 > Freed blocks are not TRIMed immediately. There is a tunable that defines > how many txg we should wait with TRIMming freed blocks (64 by default). > =20 > There is a low priority thread that TRIMs ranges when the time comes. > During TRIM we keep in-flight ranges on a list to detect colliding > writes - we have to delay writes that collide with in-flight TRIMs in > case something will be reordered and write will reached the disk before > the TRIM. We don't have to do the same for in-flight writes, as > colliding writes just remove ranges to TRIM. > =20 > Sponsored by: multiplay.co.uk > =20 > This work includes some important fixes and some improvements obtained > from the zfsonlinux project, including TRIMming entire vdevs on pool > create/add/attach and on pool import for spare and cache vdevs. > =20 > Obtained from: zfsonlinux > Submitted by: Etienne Dechamps --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --/DkgDsqJFFamjKX0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBfaNUACgkQForvXbEpPzQ4GwCfeesqQ5wYR5lL1UjQ195iiggV DAYAoMlf2im9PN669pzrCLUysbdg5uey =8JhV -----END PGP SIGNATURE----- --/DkgDsqJFFamjKX0-- From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 21:25:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD23106566C; Sun, 23 Sep 2012 21:25:08 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id EF37C8FC08; Sun, 23 Sep 2012 21:25:07 +0000 (UTC) Received: from rbpbp.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q8NLOxDc074772; Sun, 23 Sep 2012 22:24:59 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20120923195357.GO1454@garage.freebsd.pl> Date: Sun, 23 Sep 2012 22:24:53 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> References: <20120923195357.GO1454@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 23 Sep 2012 21:25:08 -0000 Hi, On 23 Sep 2012, at 20:53, Pawel Jakub Dawidek wrote: > FYI, I just committed TRIM support to ZFS, especially useful for > SSD-only pools. [etc] Is any of this applicable to -STABLE or 8.x? -- Bob Bishop rb@gid.co.uk From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 22:25:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98DAD1065673; Sun, 23 Sep 2012 22:25:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8768FC16; Sun, 23 Sep 2012 22:25:04 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 04DB7FDF; Mon, 24 Sep 2012 00:24:05 +0200 (CEST) Date: Mon, 24 Sep 2012 00:25:20 +0200 From: Pawel Jakub Dawidek To: Bob Bishop Message-ID: <20120923222520.GS1454@garage.freebsd.pl> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VgNP6wxEowREGVu+" Content-Disposition: inline In-Reply-To: <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 23 Sep 2012 22:25:05 -0000 --VgNP6wxEowREGVu+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 23, 2012 at 10:24:53PM +0100, Bob Bishop wrote: > Hi, >=20 > On 23 Sep 2012, at 20:53, Pawel Jakub Dawidek wrote: >=20 > > FYI, I just committed TRIM support to ZFS, especially useful for > > SSD-only pools. [etc] >=20 > Is any of this applicable to -STABLE or 8.x? I have a patch against stable/8, but not stable/9: http://people.freebsd.org/~pjd/patches/zfstrim8.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --VgNP6wxEowREGVu+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBfjFAACgkQForvXbEpPzSKygCfQNkwOTbW5kBRNGPX/3Fb5cDd 6U8An2pmUU+HJ5gBsxfKOwV3tNw6+l5E =9kFR -----END PGP SIGNATURE----- --VgNP6wxEowREGVu+-- From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 22:46:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20773106566C; Sun, 23 Sep 2012 22:46:28 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 95E3F8FC14; Sun, 23 Sep 2012 22:46:27 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so7241283vcb.13 for ; Sun, 23 Sep 2012 15:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vE0KXjWBU/yNb1XVYUfMUKTy/ZvDU6Crgwww6e1njp8=; b=L4b8JS6t20Ly2+cE7NuDDytJWLf5YFrDAIULLztvrq/m9I7BApABDQzWNUypmQBf5d VaaOA7b5AV23lpH2Ef1WBgxvqflYcxoFJ2tEid/qHKuT4FqOgIEK7gT2ag8ulnS5U7Pi X0ArW03gHPCn3H2INeAmih0zF08NdktTva4emftXDcRBwcETQq/tXV75qOPRq3bVD4Vr M62NpjdmC8iWWHvzh8Wvs+9TZ97DF/iIpN0RI2kG3oEmRc7yAijmbKgKgfcuCjkCqWzu U5T1DslFggGm/8QzIUX97l2+u1PhGCPjauoDgl+NqNPf3Yybrdtcwk0kuV5dC/aECcw+ zvTg== MIME-Version: 1.0 Received: by 10.221.13.78 with SMTP id pl14mr6422164vcb.7.1348439948997; Sun, 23 Sep 2012 15:39:08 -0700 (PDT) Received: by 10.220.34.6 with HTTP; Sun, 23 Sep 2012 15:39:08 -0700 (PDT) In-Reply-To: <20120923222520.GS1454@garage.freebsd.pl> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> Date: Mon, 24 Sep 2012 01:39:08 +0300 Message-ID: From: George Kontostanos To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Bob Bishop , freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 23 Sep 2012 22:46:28 -0000 On Mon, Sep 24, 2012 at 1:25 AM, Pawel Jakub Dawidek wrote: > On Sun, Sep 23, 2012 at 10:24:53PM +0100, Bob Bishop wrote: >> Hi, >> >> On 23 Sep 2012, at 20:53, Pawel Jakub Dawidek wrote: >> >> > FYI, I just committed TRIM support to ZFS, especially useful for >> > SSD-only pools. [etc] >> >> Is any of this applicable to -STABLE or 8.x? > > I have a patch against stable/8, but not stable/9: > > http://people.freebsd.org/~pjd/patches/zfstrim8.patch > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://tupytaj.pl This sounds great. I guess we will have to wait for MFC, probably after 9.1-RELEASE, right? -- George Kontostanos --- http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 23:45:30 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA9BB106564A for ; Sun, 23 Sep 2012 23:45:30 +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 5BCAE8FC0C for ; Sun, 23 Sep 2012 23:45:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAIadX1CDaFvO/2dsb2JhbAA9AQcWhXW5L4IgAQEFIwRSGw4KAgINGQJZBhGGE4F0C6VvkXyBIYl7FguEd4ESA5VlgRWPDoMDIoEcCRkb X-IronPort-AV: E=Sophos;i="4.80,472,1344225600"; d="scan'208";a="180303361" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 23 Sep 2012 19:45:28 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B9089B4047; Sun, 23 Sep 2012 19:45:28 -0400 (EDT) Date: Sun, 23 Sep 2012 19:45:28 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <1745669351.1062583.1348443928746.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120923160847.GN37286@deviant.kiev.zoral.com.ua> 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 (Linux)/6.0.10_GA_2692) Cc: FS List Subject: Re: testing/review of atomic export update patch 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, 23 Sep 2012 23:45:30 -0000 Konstantin Belousov wrote: > On Fri, Sep 21, 2012 at 06:38:41PM -0400, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Thu, Sep 20, 2012 at 05:55:26PM -0400, Rick Macklem wrote: > > > > Konstantin Belousov wrote: > > > > > On Tue, Sep 18, 2012 at 09:34:54AM -0400, Rick Macklem wrote: > > > > > > Konstantin Belousov wrote: > > > > > > > On Mon, Sep 17, 2012 at 05:32:44PM -0400, Rick Macklem > > > > > > > wrote: > > > > > > > > Konstantin Belousov wrote: > > > > > > > > > On Sun, Sep 16, 2012 at 05:41:25PM -0400, Rick Macklem > > > > > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > There is a simple patch at: > > > > > > > > > > http://people.freebsd.org/~rmacklem/atomic-export.patch > > > > > > > > > > that can be applied to a kernel + mountd, so that > > > > > > > > > > the > > > > > > > > > > new > > > > > > > > > > nfsd can be suspended by mountd while the exports > > > > > > > > > > are > > > > > > > > > > being > > > > > > > > > > reloaded. It adds a new "-S" flag to mountd to > > > > > > > > > > enable > > > > > > > > > > this. > > > > > > > > > > (This avoids the long standing bug where clients > > > > > > > > > > receive > > > > > > > > > > ESTALE > > > > > > > > > > replies to RPCs while mountd is reloading exports.) > > > > > > > > > > > > > > > > > > This looks simple, but also somewhat worrisome. What > > > > > > > > > would > > > > > > > > > happen > > > > > > > > > if the mountd crashes after nfsd suspension is > > > > > > > > > requested, > > > > > > > > > but > > > > > > > > > before > > > > > > > > > resume was performed ? > > > > > > > > > > > > > > > > > > Might be, mountd should check for suspended nfsd on > > > > > > > > > start > > > > > > > > > and > > > > > > > > > unsuspend > > > > > > > > > it, if some flag is specified ? > > > > > > > > Well, I think that happens with the patch as it stands. > > > > > > > > > > > > > > > > suspend is done if the "-S" option is specified, but > > > > > > > > that is > > > > > > > > a > > > > > > > > no op > > > > > > > > if it is already suspended. The resume is done no matter > > > > > > > > what > > > > > > > > flags > > > > > > > > are provided, so mountd will always try and do a > > > > > > > > "resume". > > > > > > > > --> get_exportlist() is always called when mountd is > > > > > > > > started > > > > > > > > up > > > > > > > > and > > > > > > > > it does the resume unconditionally when it > > > > > > > > completes. > > > > > > > > If mountd repeatedly crashes before completing > > > > > > > > get_exportlist() > > > > > > > > when it is started up, the exports will be all > > > > > > > > messed > > > > > > > > up, so > > > > > > > > having the nfsd threads suspended doesn't seem so > > > > > > > > bad > > > > > > > > for > > > > > > > > this > > > > > > > > case (which hopefully never happens;-). > > > > > > > > > > > > > > > > Both suspend and resume are just no ops for unpatched > > > > > > > > kernels. > > > > > > > > > > > > > > > > Maybe the comment in front of "resume" should explicitly > > > > > > > > explain > > > > > > > > this, instead of saying resume is harmless to do under > > > > > > > > all > > > > > > > > conditions? > > > > > > > > > > > > > > > > Thanks for looking at it, rick > > > > > > > I see. > > > > > > > > > > > > > > My another note is that there is no any protection against > > > > > > > parallel > > > > > > > instances of suspend/resume happen. For instance, one > > > > > > > thread > > > > > > > could > > > > > > > set > > > > > > > suspend_nfsd = 1 and be descheduled, while another > > > > > > > executes > > > > > > > resume > > > > > > > code sequence meantime. Then it would see suspend_nfsd != > > > > > > > 0, > > > > > > > while > > > > > > > nfsv4rootfs_lock not held, and tries to unlock it. It > > > > > > > seems > > > > > > > that > > > > > > > nfsv4_unlock would silently exit. The suspending thread > > > > > > > resumes, > > > > > > > and obtains the lock. You end up with suspend_nfsd == 0 > > > > > > > but > > > > > > > lock > > > > > > > held. > > > > > > Yes. I had assumed that mountd would be the only thing using > > > > > > these > > > > > > syscalls > > > > > > and it is single threaded. (The syscalls can only be done by > > > > > > root > > > > > > for the > > > > > > obvious reasons.;-) > > > > > > > > > > > > Maybe the following untested version of the syscalls would > > > > > > be > > > > > > better, since > > > > > > they would allow multiple concurrent calls to either suspend > > > > > > or > > > > > > resume. > > > > > > (There would still be an indeterminate case if one thread > > > > > > called > > > > > > resume > > > > > > concurrently with another few calling suspend, but that is > > > > > > unavoidable, > > > > > > I think?) > > > > > > > > > > > > Again, thanks for the comments, rick > > > > > > --- untested version of syscalls --- > > > > > > } else if ((uap->flag & NFSSVC_SUSPENDNFSD) != 0) { > > > > > > NFSLOCKV4ROOTMUTEX(); > > > > > > if (suspend_nfsd == 0) { > > > > > > /* Lock out all nfsd threads */ > > > > > > igotlock = 0; > > > > > > while (igotlock == 0 && suspend_nfsd == 0) { > > > > > > igotlock = nfsv4_lock(&nfsv4rootfs_lock, 1, > > > > > > NULL, NFSV4ROOTLOCKMUTEXPTR, NULL); > > > > > > } > > > > > > suspend_nfsd = 1; > > > > > > } > > > > > > NFSUNLOCKV4ROOTMUTEX(); > > > > > > error = 0; > > > > > > } else if ((uap->flag & NFSSVC_RESUMENFSD) != 0) { > > > > > > NFSLOCKV4ROOTMUTEX(); > > > > > > if (suspend_nfsd != 0) { > > > > > > nfsv4_unlock(&nfsv4rootfs_lock, 0); > > > > > > suspend_nfsd = 0; > > > > > > } > > > > > > NFSUNLOCKV4ROOTMUTEX(); > > > > > > error = 0; > > > > > > } > > > > > > > > > > From the cursory look, this variant is an improvement, mostly > > > > > by > > > > > taking > > > > > the interlock before testing suspend_nfsd, and using the while > > > > > loop. > > > > > > > > > > Is it possible to also make the sleep for the lock > > > > > interruptible ? > > > > > So that blocked mountd could be killed by a signal ? > > > > Well, it would require some coding. An extra argument to > > > > nfsv4_lock() > > > > to indicate to do so and then either the caller would have to > > > > check > > > > for a pending termination signal when it returns 0 (indicates > > > > didn't > > > > get > > > > lock) or a new return value to indicate EINTR. The latter would > > > > require > > > > all the calls to it to be changed to recognize the new 3rd > > > > return > > > > case. > > > > Because there are a lot of these calls, I'd tend towards just > > > > having > > > > the > > > > caller check for a pending signal. > > > > > > > > Not sure if it would make much difference though. The only time > > > > it > > > > would get stuck in nfsv4_lock() is if the nfsd threads are all > > > > wedged > > > > and in that case having mountd wedged too probably doesn't make > > > > much > > > > difference, since the NFS service is toast in that case anyhow. > > > > > > > > If you think it is worth doing, I can add that. I basically see > > > > this > > > > as a "stop-gap" fix until such time as something like nfse is > > > > done, > > > > but since I haven't the time to look at nfse right now, I have > > > > no > > > > idea when/if that might happen. > > > > > > Ok, please go ahead with the patch. Having the patch even in its > > > current > > > form is obviously better then not to have it. If the wedged mountd > > > appears to be annoying enough for me, I would do the change. > > > > > > Thanks. > > Oops, I spoke too soon. When I took a look at the code, I realized > > that > > having nfsv4_lock() return when a pending signal interrupts the > > msleep() > > isn't easy. As such, I think I'll leave it out of the patch for now. > > > > For those who find these things interesting, the reason the above is > > hard is the funny intentional semantics that nfsv4_lock() > > implements. > > Most of the time, the nfsd threads can concurrently handle the NFSv4 > > state structures, using a mutex to serialize access to the lists and > > never sleeping while doing so. However, there are a few case (mainly > > delegation recall) where sleeping and knowing that no other thread > > is modifying the lists is necessary. > > > > As such, nfsv4_lock() will be called by potentially many nfsd > > threads > > (up to 200+) wanting this exclusive sleep lock. However, it is coded > > so that only the first one that wakes up after the shared locks (I > > call > > it a ref count in the code) have been released, gets the exclusive > > lock. The rest of the threads wake up after the first thread > > releases > > the exclusive lock, but simply return without getting the lock. > > This avoids up to 200+ threads getting the exclusive lock in turn > > and > > then going "oh, I don't need it since that other thread already got > > the work done" so it releases the exclusive lock and gets a shared > > one. > > (It also implements the exclusive lock as having priority over the > > shared > > lock request, so that nfsv4_lock() won't wait indefinitely for the > > exclusive lock.) > > > > The above is done by having the first thread that wakes up once the > > shared locks are released clear the "want an exclusive lock" flag > > as it acquires it. > > > > If a call were to return due to a signal, it wouldn't know if it > > should clear the "want an exclusive lock" flag or not, since it > > wouldn't know if other threads currently want it or not. > My take is that the thread which got EINTR from msleep() shall not > clear > the flag. It shall not get the lock anyway. > The problem is that the call will have set this flag (NFSv4LOCK_LOCKWANTED) before it did the msleep(). If no other thread currently msleep()ing on this lock also set it, then exiting without clearing it will leave it bogusly set. This means that other callers (ones that call with iwantlock == 0) will get stuck in the function. I know it sounds weird that threads call nfsv4_lock() when they don't want the lock, but they do so to block while any other thread that does want the lock gets/releases it to avoid starving the thread(s) that do want the lock. > > > > This could probably be fixed by adding a count of how many threads > > are currently sleeping, waiting for the "want an exclusive flag", > > but that's too scary for me to do, unless it really is needed. > > (As you might have guessed, it's pretty easy to break this in > > subtle ways and I'm a chicken;-) > > BTW, nfsv4_lock/unlock desperately need assertion that the mutex is > locked > on entry. Yep, I can do that, rick From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 00:20:44 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A559C1065670; Mon, 24 Sep 2012 00:20:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 70B928FC25; Mon, 24 Sep 2012 00:20:44 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 3E1CE23F6D9; Sun, 23 Sep 2012 20:20:43 -0400 (EDT) Date: Sun, 23 Sep 2012 20:20:41 -0400 From: Glen Barber To: Pawel Jakub Dawidek Message-ID: <20120924002041.GA1303@glenbarber.us> References: <20120923195357.GO1454@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <20120923195357.GO1454@garage.freebsd.pl> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 00:20:44 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Pawel, On Sun, Sep 23, 2012 at 09:53:58PM +0200, Pawel Jakub Dawidek wrote: > FYI, I just committed TRIM support to ZFS, especially useful for > SSD-only pools. This is something I implemented long time ago, but was > now motivated to get back to it and commit it finally by some great > fixes and improvements from the zfsonlinux project (made by Etienne > Dechamps). >=20 Great! Thanks for this. Any chance you can document the following sysctls? root@kaos:/root # sysctl -d kstat.zfs.misc.zio_trim kstat.zfs.misc.zio_trim:=20 kstat.zfs.misc.zio_trim.zio_trim_bytes:=20 kstat.zfs.misc.zio_trim.zio_trim_success:=20 kstat.zfs.misc.zio_trim.zio_trim_unsupported:=20 kstat.zfs.misc.zio_trim.zio_trim_failed:=20 Glen --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQX6dZAAoJEFJPDDeguUajQMkH/3HRGT3sDGaxprhVzQvNE/ji TYvpqdIwAUTZsEagDC0FRbnZjOrb+/wU7PuBx6ttqD5Ce6NfrK+9+f+o3D6LZnzD BVXx3vw9BhwWITYX6L8k8DsKsgNsqqvTZgpxYmKOCzjb/xYUB9eQS4i+mkJ8qE0q d/32bRB80jrve5fu/9/nv2fwf1T5RCj1ekzLxIKMWcx0hKwPoYWmc+k0+cCw7N9g FMvmR8eWbDAlCQxUGXc0ot2sg3nG0gomj6lqWMm+jmukHx+NTl9Xtf3/zmJtOmoJ G6DraUO7T6l4cCo2aTtG5K4NHQ+Dxq4EUDgYs9axJhZWaIoSwxP0IJ9TAobc9/M= =xxsj -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 01:22:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26966106564A; Mon, 24 Sep 2012 01:22:58 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id EF69C8FC08; Mon, 24 Sep 2012 01:22:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=ivnLZXWSd0/TEFk/8/MZlCZSE1fcBLQWlWCpqJgGybM=; b=RmIuSl0GY5/XgCA9iZ3njqUzSZqH1ZGVo9qwsnDueudcHuIZb82hiWsVj5y8+u7/5jaTIzxcLHGB4XuQWeX7a1mIT5AsxahCn8fmybVpM08Am4I5SyddiC8czshMYbxw; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TFxNu-0008V9-8E; Sun, 23 Sep 2012 20:22:55 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1348449768-3100-3099/5/117; Mon, 24 Sep 2012 01:22:48 +0000 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-current@freebsd.org, Pawel Jakub Dawidek References: <20120923195357.GO1454@garage.freebsd.pl> Date: Sun, 23 Sep 2012 20:22:45 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120923195357.GO1454@garage.freebsd.pl> User-Agent: Opera Mail/12.02 (Win32) X-SA-Report: ALL_TRUSTED=-1, KHOP_THREADED=-0.5 X-SA-Score: -1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 01:22:58 -0000 Is this making it TRIM aware globally -- even on your cache and log devices? From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 03:44:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AD7C1065670; Mon, 24 Sep 2012 03:44:31 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 837398FC12; Mon, 24 Sep 2012 03:44:30 +0000 (UTC) Received: by qafi29 with SMTP id i29so2107358qaf.13 for ; Sun, 23 Sep 2012 20:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ll2/sW6A+oW3KV5NrJ1m8nos45nFfx3g5J9F/ux01Ms=; b=uHtO/7qTQsPhWixlnGHvhiSIkU4vH6O8o57Fvr4KQgMFhn2wd68NjUTxj/B0x/ZqrF ZirTB1sw10TIkCjMuYz6Of+xgoxBJYC+vqsZ63/OOXazDkxfMtck35mHny10RyFmKayP 0HOjBGbUz8S7EBRDCY52JP7oU/6ETGlolmNyV7nMJQd3ZapsY6nzabXJ3jr9ojZtJFoF otl6tnG6H+AcOL3koa1g6b598hJdeZJECgPLULZJoFNsei3yz3hrRnUQVyKBQU2Wm/nD u9rX5taP01XCvCeDwFzNn427wzOUgiCZgJGO24pEozxjoJtKT9z4sRPAsWZ4EcrbRXAf hIYg== MIME-Version: 1.0 Received: by 10.224.181.205 with SMTP id bz13mr29366633qab.76.1348458269528; Sun, 23 Sep 2012 20:44:29 -0700 (PDT) Received: by 10.49.1.202 with HTTP; Sun, 23 Sep 2012 20:44:29 -0700 (PDT) In-Reply-To: <20120923195357.GO1454@garage.freebsd.pl> References: <20120923195357.GO1454@garage.freebsd.pl> Date: Mon, 24 Sep 2012 11:44:29 +0800 Message-ID: From: Marcelo Araujo To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 03:44:31 -0000 2012/9/24 Pawel Jakub Dawidek > FYI, I just committed TRIM support to ZFS, especially useful for > SSD-only pools. This is something I implemented long time ago, but was > now motivated to get back to it and commit it finally by some great > fixes and improvements from the zfsonlinux project (made by Etienne > Dechamps). > > Thank you so much to bring it up to us. -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 06:02:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 585D11065673 for ; Mon, 24 Sep 2012 06:02:42 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id D7A0F8FC14 for ; Mon, 24 Sep 2012 06:02:41 +0000 (UTC) Received: (qmail 62165 invoked by uid 0); 24 Sep 2012 06:02:35 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 24 Sep 2012 06:02:35 -0000 Received: (qmail 62154 invoked by uid 90); 24 Sep 2012 06:02:35 -0000 Received: from unknown (HELO toasty.sporklab.com) (spork@96.57.144.66) by smtp.bway.net with ESMTPA; 24 Sep 2012 06:02:35 -0000 References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> In-Reply-To: <20120923222520.GS1454@garage.freebsd.pl> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 Message-Id: <58743599-C986-4735-A588-AEFAAEE5766A@bway.net> Content-Transfer-Encoding: quoted-printable From: Charles Sprickman Date: Mon, 24 Sep 2012 02:02:34 -0400 To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org, Bob Bishop , freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 06:02:42 -0000 On Sep 23, 2012, at 6:25 PM, Pawel Jakub Dawidek wrote: > On Sun, Sep 23, 2012 at 10:24:53PM +0100, Bob Bishop wrote: >> Hi, >>=20 >> On 23 Sep 2012, at 20:53, Pawel Jakub Dawidek wrote: >>=20 >>> FYI, I just committed TRIM support to ZFS, especially useful for >>> SSD-only pools. [etc] >>=20 >> Is any of this applicable to -STABLE or 8.x? >=20 > I have a patch against stable/8, but not stable/9: >=20 > http://people.freebsd.org/~pjd/patches/zfstrim8.patch Are you aware of anyone that will be trying this in production, and if=20= so, will you be able to give us list denizens any feedback on it? Thanks so much for porting this=85 Charles >=20 > --=20 > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://tupytaj.pl From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 08:18:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF1CE106564A; Mon, 24 Sep 2012 08:18:18 +0000 (UTC) (envelope-from prvs=1614b6a669=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 34C268FC12; Mon, 24 Sep 2012 08:18:17 +0000 (UTC) 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 md50000204898.msg; Mon, 24 Sep 2012 09:18:10 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 24 Sep 2012 09:18:10 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1614b6a669=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Charles Sprickman" , "Pawel Jakub Dawidek" References: <20120923195357.GO1454@garage.freebsd.pl><1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk><20120923222520.GS1454@garage.freebsd.pl> <58743599-C986-4735-A588-AEFAAEE5766A@bway.net> Date: Mon, 24 Sep 2012 09:18:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit 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.6157 Cc: freebsd-fs@freebsd.org, Bob Bishop , freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 08:18:19 -0000 ----- Original Message ----- From: "Charles Sprickman" > Are you aware of anyone that will be trying this in production, and if > so, will you be able to give us list denizens any feedback on it? Yes we've been using it in production for a few months now, but only on single disk pools so not RAIDZ as yet, although we have tested it on such a pool. > Thanks so much for porting this… It's not a port this is new code not in any other ZFS implementation, so a FreeBSD first :) 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 Mon Sep 24 11:07:21 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56BC0106564A for ; Mon, 24 Sep 2012 11:07:21 +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 400DF8FC1D for ; Mon, 24 Sep 2012 11:07:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8OB7L7D085933 for ; Mon, 24 Sep 2012 11:07:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8OB7Kpe085931 for freebsd-fs@FreeBSD.org; Mon, 24 Sep 2012 11:07:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Sep 2012 11:07:20 GMT Message-Id: <201209241107.q8OB7Kpe085931@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, 24 Sep 2012 11:07:21 -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/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o kern/170914 fs [zfs] [patch] Import patchs related with issues 3090 a o kern/170912 fs [zfs] [patch] unnecessarily setting DS_FLAG_INCONSISTE o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/170238 fs [zfs] [panic] Panic when deleting data o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167066 fs [zfs] ZVOLs not appearing in /dev/zvol o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo p kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " p kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o 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/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 289 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 11:35:29 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 776121065670 for ; Mon, 24 Sep 2012 11:35:29 +0000 (UTC) (envelope-from attila.bogar@linguamatics.com) Received: from mail.linguamatics.com (mail.linguamatics.com [188.39.80.203]) by mx1.freebsd.org (Postfix) with ESMTP id E89218FC17 for ; Mon, 24 Sep 2012 11:35:28 +0000 (UTC) Received: from [10.252.10.232] (random.linguamatics.com [10.252.10.232]) by mail.linguamatics.com (Postfix) with ESMTPSA id 3966FEFB450; Mon, 24 Sep 2012 12:29:14 +0100 (BST) Message-ID: <5060440B.2020009@linguamatics.com> Date: Mon, 24 Sep 2012 12:29:15 +0100 From: =?UTF-8?B?QXR0aWxhIEJvZ8Ohcg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Rick Macklem References: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS: rpcsec_gss with Linux clients 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, 24 Sep 2012 11:35:29 -0000 Hi Rick, On 02/09/12 00:57, Rick Macklem wrote: > This certainly sounds bogus. I can see an argument for 2 TCP > connections for trunking, but since a security context should only be > destroyed when the client is done with it, doing a DESTROY doesn't > make sense? (There is something in the RPC header called a "handle". > It identifies the security context, and it would be nice to check the > wireshark trace to see if it the same as the one being used on the > other connection?) The Linux guys say this is a bug in Linux: http://www.spinics.net/lists/linux-nfs/msg32466.html I'm going to open a bug with Red Hat and test the upstream linux kernel + nfs-utils against this bug. As per their message it's also interesting why the rpcsec destroy mic evaluates to GSS_S_DEFECTIVE_TOKEN. This is the 2nd root of the original problem. > That would indicate the encrypted checksum isn't correct. It > might be using an algorithm only supported by the newer RPCSEC_GSS_V3? If I check the trace with wireshark 1.4.6 it reports rpc malformed packet. However if I check the trace with the newest 1.8.2 it's OK (could be a bug in wireshark, though). Anyway it says rpc version 2 and gss version 1. > I've attached a small patch with disables setting client->cl_state to > CLIENT_STALE for this case, which you could try, to see if it helps? Yep, it works perfectly. Confirmed. Please go ahead to commit and merge to stable. Attila -- Attila Bogár Systems Administrator Linguamatics - Cambridge, UK http://www.linguamatics.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 11:35:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E3821065672; Mon, 24 Sep 2012 11:35:31 +0000 (UTC) (envelope-from prvs=1614b6a669=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 9703B8FC18; Mon, 24 Sep 2012 11:35:30 +0000 (UTC) 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 md50000206744.msg; Mon, 24 Sep 2012 12:35:27 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 24 Sep 2012 12:35:27 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1614b6a669=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <6B400C472FB24A7C94EF1AFB0DF6ABF1@multiplay.co.uk> From: "Steven Hartland" To: "Charles Sprickman" , "Pawel Jakub Dawidek" References: <20120923195357.GO1454@garage.freebsd.pl><1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk><20120923222520.GS1454@garage.freebsd.pl> <58743599-C986-4735-A588-AEFAAEE5766A@bway.net> Date: Mon, 24 Sep 2012 12:35:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 11:35:31 -0000 ----- Original Message ----- From: "Charles Sprickman" >> I have a patch against stable/8, but not stable/9: >> >> http://people.freebsd.org/~pjd/patches/zfstrim8.patch > > Are you aware of anyone that will be trying this in production, and if > so, will you be able to give us list denizens any feedback on it? We've been using a prior version of this patch in production for a few months now on single and mirrored data disks, no problems. We've done very basic testing on RAIDZ, RAIDZ2 & RAIDZ3 no problems with the version we had, but this version includes a number of important fixes for RAIDZ contributed by the zfsonlinux guys. We applied the patch to a 8.3-RELEASE based install with additional patches including patches to provide TRIM support for CAM da devices via SATA pass-through including full support for security and identify commands in camcontrol. If anyone would like those as we can provide. 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 Mon Sep 24 12:38:52 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 346241065672 for ; Mon, 24 Sep 2012 12:38:52 +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 E0F468FC0A for ; Mon, 24 Sep 2012 12:38:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKpTYFCDaFvO/2dsb2JhbABFhgu5OoIgAQEBAwEBAiAEUgUWBxECAg0ZAiovBogSBgulR5IzgSGPE4ESA5M4gi2JN4ZsgwOBew X-IronPort-AV: E=Sophos;i="4.80,475,1344225600"; d="scan'208";a="182962344" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 24 Sep 2012 08:38:19 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 782A0B4031; Mon, 24 Sep 2012 08:38:19 -0400 (EDT) Date: Mon, 24 Sep 2012 08:38:19 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Attila_Bog=C3=A1r?= Message-ID: <1411662865.1073866.1348490299472.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <5060440B.2020009@linguamatics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS: rpcsec_gss with Linux clients 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, 24 Sep 2012 12:38:52 -0000 Attila Bogar wrote: > Hi Rick, >=20 > On 02/09/12 00:57, Rick Macklem wrote: >=20 >=20 > This certainly sounds bogus. I can see an argument for 2 TCP > connections for trunking, but since a security context should only be > destroyed when the client is done with it, doing a DESTROY doesn't > make sense? (There is something in the RPC header called a "handle". > It identifies the security context, and it would be nice to check the > wireshark trace to see if it the same as the one being used on the > other connection?) The Linux guys say this is a bug in Linux: > http://www.spinics.net/lists/linux-nfs/msg32466.html >=20 > I'm going to open a bug with Red Hat and test the upstream linux > kernel + nfs-utils against this bug. >=20 > As per their message it's also interesting why the rpcsec destroy mic > evaluates to GSS_S_DEFECTIVE_TOKEN. > This is the 2nd root of the original problem. >=20 > That would indicate the encrypted checksum isn't correct. It > might be using an algorithm only supported by the newer RPCSEC_GSS_V3? > If I check the trace with wireshark 1.4.6 it reports rpc malformed > packet. > However if I check the trace with the newest 1.8.2 it's OK (could be a > bug in wireshark, though). > Anyway it says rpc version 2 and gss version 1. >=20 >=20 >=20 > I've attached a small patch with disables setting client->cl_state to > CLIENT_STALE for this case, which you could try, to see if it helps? > Yep, it works perfectly. Confirmed. Please go ahead to commit and > merge to stable. >=20 Ok, thanks for testing it. I am waiting for a review from dfr@, but will get it committed soon. Have a good week, rick > Attila > -- > Attila Bog=C3=A1r > Systems Administrator > Linguamatics - Cambridge, UK http://www.linguamatics.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 13:20:38 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2F29106566B; Mon, 24 Sep 2012 13:20:38 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 935F58FC19; Mon, 24 Sep 2012 13:20:38 +0000 (UTC) Received: from roberto-aw.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 71D6D15048; Mon, 24 Sep 2012 15:20:36 +0200 (CEST) Date: Mon, 24 Sep 2012 15:20:31 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org, Charles Sprickman , freebsd-fs@freebsd.org Message-ID: <20120924132030.GA79156@roberto-aw.eurocontrol.fr> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <58743599-C986-4735-A588-AEFAAEE5766A@bway.net> <6B400C472FB24A7C94EF1AFB0DF6ABF1@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B400C472FB24A7C94EF1AFB0DF6ABF1@multiplay.co.uk> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 13:20:39 -0000 According to Steven Hartland: > We applied the patch to a 8.3-RELEASE based install with additional patches > including patches to provide TRIM support for CAM da devices via SATA > pass-through including full support for security and identify commands in > camcontrol. > > If anyone would like those as we can provide. That would be indeed very nice. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 13:55:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 843F1106566C; Mon, 24 Sep 2012 13:55:33 +0000 (UTC) (envelope-from prvs=1614b6a669=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 E2D9A8FC08; Mon, 24 Sep 2012 13:55:32 +0000 (UTC) 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 md50000208211.msg; Mon, 24 Sep 2012 14:55:30 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 24 Sep 2012 14:55:30 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1614b6a669=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <0BCB8A9018D84321BF1EF8F821BB2447@multiplay.co.uk> From: "Steven Hartland" To: "Ollivier Robert" , , "Charles Sprickman" , References: <20120923195357.GO1454@garage.freebsd.pl><1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk><20120923222520.GS1454@garage.freebsd.pl><58743599-C986-4735-A588-AEFAAEE5766A@bway.net><6B400C472FB24A7C94EF1AFB0DF6ABF1@multiplay.co.uk> <20120924132030.GA79156@roberto-aw.eurocontrol.fr> Date: Mon, 24 Sep 2012 14:55:27 +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.6157 Cc: Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 13:55:33 -0000 ----- Original Message ----- From: "Ollivier Robert" > According to Steven Hartland: >> We applied the patch to a 8.3-RELEASE based install with additional patches >> including patches to provide TRIM support for CAM da devices via SATA >> pass-through including full support for security and identify commands in >> camcontrol. >> >> If anyone would like those as we can provide. > > That would be indeed very nice. Our current patchset minus the zfstrim one can be found here:- http://blog.multiplay.co.uk/dropzone/freebsd/zfs-trim-patchset83.tbz Of course you'll also need pjd's zfs trim patch set. It expects to be extracted in /usr/src, where it will create a patches subdir. If you then put the zfs trim patch in the same dir and run ./patches/apply.sh you should be good. There's a fare few patches in there, as I've split the various parts into their individual components so its easier to track and submit. The patches include some back ported code that's already committed as well as other little fixes which also have been committed. Notes at the top of each patch file detail what it does and if its been committed. The one to watch is zfs-ashift-fix.patch as that changes how ashift is calculated for a drive (makes it compatible with QUIRKS) but could well cause issues if you booting from a ZFS tank which has a member disk that changes stripsize. If you don't want to risk that, just delete it. It should however be noted that at least on sandforce based disks if your deletes aren't 4k aligned the trim requests will be ignored by the drive, which is what triggered us to create that patch as well as the ssd_quirks.patch 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 Mon Sep 24 14:17:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2538F106566C; Mon, 24 Sep 2012 14:17:18 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 7370F8FC0A; Mon, 24 Sep 2012 14:17:18 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q8OEHHl1002802; Mon, 24 Sep 2012 15:17:17 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20120923222520.GS1454@garage.freebsd.pl> Date: Mon, 24 Sep 2012 15:17:11 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 14:17:19 -0000 Hi, On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: > I have a patch against stable/8, but not stable/9: > > http://people.freebsd.org/~pjd/patches/zfstrim8.patch Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm getting: kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 kstat.zfs.misc.zio_trim.zio_trim_success: 0 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 which doesn't look like it's working. The SSDs are: ad4: 114473MB at ata2-master UDMA100 SATA 3Gb/s ad6: 114473MB at ata3-master UDMA100 SATA 3Gb/s Any suggestions? Thanks -- Bob Bishop rb@gid.co.uk From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 15:55:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A30AD106566B; Mon, 24 Sep 2012 15:55:24 +0000 (UTC) (envelope-from prvs=1614b6a669=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 D6D228FC0C; Mon, 24 Sep 2012 15:55:23 +0000 (UTC) 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 md50000209363.msg; Mon, 24 Sep 2012 16:55:21 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 24 Sep 2012 16:55:21 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1614b6a669=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> From: "Steven Hartland" To: "Bob Bishop" , "Pawel Jakub Dawidek" References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> Date: Mon, 24 Sep 2012 16:55:20 +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.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 15:55:24 -0000 ----- Original Message ----- From: "Bob Bishop" To: "Pawel Jakub Dawidek" Cc: ; ; "Steven Hartland" Sent: Monday, September 24, 2012 3:17 PM Subject: Re: ZFS TRIM support committed to HEAD. > Hi, > > On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: > >> I have a patch against stable/8, but not stable/9: >> >> http://people.freebsd.org/~pjd/patches/zfstrim8.patch > > Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm getting: > > kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 > kstat.zfs.misc.zio_trim.zio_trim_success: 0 > kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 > kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 > > which doesn't look like it's working. The SSDs are: > > ad4: 114473MB at ata2-master UDMA100 SATA 3Gb/s > ad6: 114473MB at ata3-master UDMA100 SATA 3Gb/s > > Any suggestions? Thanks Don't think ad supports TRIM, switch to ada (ahci) and you should be good. Although I'm surprised your seeing that many reported failures as it should have disabled it on a pool level after the first few failures. Is it still increasing? 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 Mon Sep 24 16:07:16 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7555E106564A; Mon, 24 Sep 2012 16:07:16 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7058FC08; Mon, 24 Sep 2012 16:07:15 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q8OG7DqH005996; Mon, 24 Sep 2012 17:07:13 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Bob Bishop X-Priority: 3 In-Reply-To: <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> Date: Mon, 24 Sep 2012 17:07:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07C554A3-5957-4664-8E0F-D7C6885C5EAF@gid.co.uk> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 16:07:16 -0000 Hi, On 24 Sep 2012, at 16:55, Steven Hartland wrote: > ----- Original Message ----- From: "Bob Bishop" > To: "Pawel Jakub Dawidek" > Cc: ; ; "Steven = Hartland" > Sent: Monday, September 24, 2012 3:17 PM > Subject: Re: ZFS TRIM support committed to HEAD. >=20 >=20 >> Hi, >> On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: >>> I have a patch against stable/8, but not stable/9: >>> http://people.freebsd.org/~pjd/patches/zfstrim8.patch >> Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm = getting: >> kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 >> kstat.zfs.misc.zio_trim.zio_trim_success: 0 >> kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 >> kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 >> which doesn't look like it's working. The SSDs are: >> ad4: 114473MB at ata2-master UDMA100 = SATA 3Gb/s >> ad6: 114473MB at ata3-master UDMA100 = SATA 3Gb/s >> Any suggestions? Thanks >=20 > Don't think ad supports TRIM, switch to ada (ahci) and you should be = good. >=20 > Although I'm surprised your seeing that many reported failures as it = should > have disabled it on a pool level after the first few failures. >=20 > Is it still increasing? Yes I'll try switching to ahci -- Bob Bishop rb@gid.co.uk From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 16:16:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 797BC106564A; Mon, 24 Sep 2012 16:16:43 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6068FC12; Mon, 24 Sep 2012 16:16:43 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 10F47265; Mon, 24 Sep 2012 18:15:38 +0200 (CEST) Date: Mon, 24 Sep 2012 18:16:55 +0200 From: Pawel Jakub Dawidek To: Steven Hartland Message-ID: <20120924161654.GA1413@garage.freebsd.pl> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, Bob Bishop , freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 16:16:43 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 24, 2012 at 04:55:20PM +0100, Steven Hartland wrote: > ----- Original Message -----=20 > From: "Bob Bishop" > To: "Pawel Jakub Dawidek" > Cc: ; ; "Steven Hart= land" > Sent: Monday, September 24, 2012 3:17 PM > Subject: Re: ZFS TRIM support committed to HEAD. >=20 >=20 > > Hi, > >=20 > > On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: > >=20 > >> I have a patch against stable/8, but not stable/9: > >>=20 > >> http://people.freebsd.org/~pjd/patches/zfstrim8.patch > >=20 > > Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm ge= tting: > >=20 > > kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 > > kstat.zfs.misc.zio_trim.zio_trim_success: 0 > > kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 > > kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 > >=20 > > which doesn't look like it's working. The SSDs are: > >=20 > > ad4: 114473MB at ata2-master UDMA100 SATA = 3Gb/s > > ad6: 114473MB at ata3-master UDMA100 SATA = 3Gb/s > >=20 > > Any suggestions? Thanks >=20 > Don't think ad supports TRIM, switch to ada (ahci) and you should be good. >=20 > Although I'm surprised your seeing that many reported failures as it shou= ld > have disabled it on a pool level after the first few failures. >=20 > Is it still increasing? Note that 'failed' count is increasing, not the 'unsupported' count. We disable TRIM automatically if we get EOPNOTSUPP and ATA is returning some other error(s). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBgh3YACgkQForvXbEpPzS7qgCg0x79vuGo2JZOIJbhCoZWaOyl vj8AnijIdfW+bQjm9+99NUvNCVMmUWnQ =1+ig -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 16:53:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF9CF106566B; Mon, 24 Sep 2012 16:53:25 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 726558FC08; Mon, 24 Sep 2012 16:53:25 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q8OGrO8l007333; Mon, 24 Sep 2012 17:53:24 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Bob Bishop X-Priority: 3 In-Reply-To: <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> Date: Mon, 24 Sep 2012 17:53:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EC5B55F-E969-4663-A753-1115D96F125C@gid.co.uk> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 16:53:26 -0000 Hi, On 24 Sep 2012, at 16:55, Steven Hartland wrote: > Don't think ad supports TRIM, switch to ada (ahci) and you should be = good. Switched to AHCI and now looks more plausible: kstat.zfs.misc.zio_trim.zio_trim_bytes: 2173466624 kstat.zfs.misc.zio_trim.zio_trim_success: 13244 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 0 I'll report back if anything unpleasant happens. Thanks to all for this. dmesg below FTR -- Bob Bishop rb@gid.co.uk Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-STABLE #0: Mon Sep 24 14:00:52 BST 2012 rb@seagoon.gid.co.uk:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1821.67-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x106ca Family =3D 6 Model =3D 1c = Stepping =3D 10 = Features=3D0xbfebfbff = Features2=3D0x40e31d AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 4080594944 (3891 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP/HT): APIC ID: 3 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20c0-0x20c7 mem = 0xf0200000-0xf027ffff,0xe0000000-0xefffffff,0xf0100000-0xf01fffff irq 16 = at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 8188k stolen memory pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pci1: on pcib1 re0: port = 0x1000-0x10ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at = device 0.0 on pci1 re0: Using 1 MSI-X message re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 38:60:77:30:09:63 re0: [ITHREAD] pcib2: at device 28.1 on pci0 pci2: on pcib2 pcib3: at device 28.2 on pci0 pci3: on pcib3 pcib4: at device 28.3 on pci0 pci4: on pcib4 uhci0: port 0x2080-0x209f irq = 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup =3D 0x2f00 usbus0 on uhci0 uhci1: port 0x2060-0x207f irq = 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup =3D 0x2f00 usbus1 on uhci1 uhci2: port 0x2040-0x205f irq = 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup =3D 0x2f00 usbus2 on uhci2 uhci3: port 0x2020-0x203f irq = 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup =3D 0x2f00 usbus3 on uhci3 ehci0: mem = 0xf0284400-0xf02847ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4 on ehci0 pcib5: at device 30.0 on pci0 pci5: on pcib5 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port = 0x20b8-0x20bf,0x20cc-0x20cf,0x20b0-0x20b7,0x20c8-0x20cb,0x20a0-0x20af = mem 0xf0284000-0xf02843ff irq 18 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_hpet0: iomem 0xfed00000-0xfed03fff on = acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 p4tcc0: on cpu0 p4tcc1: on cpu1 p4tcc2: on cpu2 p4tcc3: on cpu3 ZFS filesystem version 5 ZFS storage pool version 28 RTC BIOS diagnostic error 80 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based = forwarding disabled, default to deny, logging disabled usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic3: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered usbd_set_config_index: could not read device status: USB_ERR_SHORT_XFER Root mount waiting for: usbus4 ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:2:0:-1: Attached to scbus2 Trying to mount root from zfs:m1 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0=20 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not = present - tray closed) cd0 at umass-sim0 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present = - tray closed= From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 17:03:48 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C464E1065670; Mon, 24 Sep 2012 17:03:48 +0000 (UTC) (envelope-from prvs=1614b6a669=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 008A08FC0C; Mon, 24 Sep 2012 17:03:47 +0000 (UTC) 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 md50000210140.msg; Mon, 24 Sep 2012 18:03:45 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 24 Sep 2012 18:03:45 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1614b6a669=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Pawel Jakub Dawidek" References: <20120923195357.GO1454@garage.freebsd.pl><1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk><20120923222520.GS1454@garage.freebsd.pl><20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> <20120924161654.GA1413@garage.freebsd.pl> Date: Mon, 24 Sep 2012 18:03:45 +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.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 17:03:48 -0000 ----- Original Message ----- From: "Pawel Jakub Dawidek" >> Although I'm surprised your seeing that many reported failures as it should >> have disabled it on a pool level after the first few failures. >> >> Is it still increasing? > > Note that 'failed' count is increasing, not the 'unsupported' count. > We disable TRIM automatically if we get EOPNOTSUPP and ATA is returning > some other error(s). Ahh yes looks like ATA supports BIO_DELETE via ATA_CFA_ERASE if the drive announces ATA_PROTO_CFA, so I can only assume this is failing when it shouldn't. Might be nice to investigate what's happening and fix, but as ATA is being replaced by CAM ATA not sure its worth it? 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 Mon Sep 24 20:39:37 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B5B106564A; Mon, 24 Sep 2012 20:39:37 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 67E508FC12; Mon, 24 Sep 2012 20:39:36 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q8OKdXG8018302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Sep 2012 15:39:35 -0500 Received: from dtwin (10.14.152.52) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 24 Sep 2012 15:39:04 -0500 From: Sender: Devin Teske To: "'Alexander Motin'" , "'Andriy Gapon'" References: <505DE566.2080307@FreeBSD.org> <505F01B2.3080709@FreeBSD.org> In-Reply-To: <505F01B2.3080709@FreeBSD.org> Date: Mon, 24 Sep 2012 13:39:06 -0700 Message-ID: <187201cd9a94$a4f0e360$eed2aa20$@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQImCUAFrw21aQP/w38sDIsucXrxhAKCRju4ltUDHTA= Content-Language: en-us X-Originating-IP: [10.14.152.52] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-24_04:2012-09-24, 2012-09-24, 1970-01-01 signatures=0 Cc: freebsd-fs@FreeBSD.org, Devin Teske Subject: RE: lszfs command for loader 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, 24 Sep 2012 20:39:37 -0000 > -----Original Message----- > From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] > On Behalf Of Alexander Motin > Sent: Sunday, September 23, 2012 5:34 AM > To: Andriy Gapon > Cc: freebsd-fs@FreeBSD.org > Subject: Re: lszfs command for loader > > On 22.09.2012 19:20, Andriy Gapon wrote: > > Please find a patch that implements lszfs loader command. > > The command can list child filesystems of a specified filesystem (including root > > dataset). > > The command is really simplistic, a list goes directly to console, so there is > > no filtering of hidden filesystem names etc. > > > > The command is intended to facilitate recovery on systems that use "Boot > > Environments" approach for boot/root filesystem. > > > > http://people.freebsd.org/~avg/lszfs.diff > > That is good for the beginning, but I believe it is not right to add > ZFS-specific commands when it is possible to avoid it. I would prefer to > see lsdev report ZFS file systems same as it reports disk partitions or > ZFS pools. I am going to work in that part. Also I would like to see > lsdev output refactored to be formal enough to use these data in loader > menu. After some look on forth code I see no big problem to pass data > there. All we need to do is to extend device API of libstand with some > method replacing dv_print() with something more alike to readdir(). > As avg and mav already know, I'm working on my next major enhancement to the aforementioned Forth code, this time adding support for submenus and dynamically initializing menuitems. I'm slowly feeding test-code to avg for these enhancements. Please note that I am not on -fs so any work in this area, I would appreciate a CC so that I'm kept in the loop. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 22:46:10 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F29521065672 for ; Mon, 24 Sep 2012 22:46:09 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D73728FC14 for ; Mon, 24 Sep 2012 22:46:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8OMk9Qj033186 for ; Mon, 24 Sep 2012 22:46:09 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8OMk9ad033185 for freebsd-fs@freebsd.org; Mon, 24 Sep 2012 22:46:09 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 25 Sep 2012 00:46:07 +0200 From: Baptiste Daroussin To: freebsd-fs@FreeBSD.org Message-ID: <20120924224606.GE79077@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SNIs70sCzqvszXB4" Content-Disposition: inline In-Reply-To: <505DB4E6.8030407@smeets.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ ...cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1407 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, 24 Sep 2012 22:46:10 -0000 --SNIs70sCzqvszXB4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have the exact same problem making: tinderbox and poudriere highly unusable. This is really problematic because pointyhat also rely on nullfs and zfs, which means we can't upgrade the building nodes if we need to for example. regards, Bapt --SNIs70sCzqvszXB4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBg4q4ACgkQ8kTtMUmk6Exp7gCeNBbrKm9J39kHMW2bX1RiI/fk zjQAn1xSV7UZqhoBWzOEw9q6Jbv/f6Z1 =d4O0 -----END PGP SIGNATURE----- --SNIs70sCzqvszXB4-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 23:14:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1ADB1065672; Mon, 24 Sep 2012 23:14:37 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 742738FC15; Mon, 24 Sep 2012 23:14:37 +0000 (UTC) Received: from rbpbp.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q8ONEUil020227; Tue, 25 Sep 2012 00:14:30 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Bob Bishop X-Priority: 3 In-Reply-To: <2EC5B55F-E969-4663-A753-1115D96F125C@gid.co.uk> Date: Tue, 25 Sep 2012 00:14:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48D1FE59-C687-4D95-B4BF-7BC85F8B8F0A@gid.co.uk> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> <2EC5B55F-E969-4663-A753-1115D96F125C@gid.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 24 Sep 2012 23:14:38 -0000 Hi, Still seems to be working OK, but: seagoon# zpool status pool: m1 state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are = unaffected. action: Determine if the device needs to be replaced, and clear the = errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scan: scrub repaired 0 in 0h2m with 0 errors on Mon Sep 24 23:52:08 = 2012 config: NAME STATE READ WRITE CKSUM m1 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk1 ONLINE 109M 0 0 gpt/disk0 ONLINE 109M 0 0 errors: No known data errors seagoon# sysctl -a |grep _trim kstat.zfs.misc.zio_trim.zio_trim_bytes: 228731904 kstat.zfs.misc.zio_trim.zio_trim_success: 19406 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 0 seagoon#=20 No device errors logged in messages, and scrub comes up clean as you can = see. The read error count is increasing, but otherwise everything = appears to work OK. -- Bob Bishop rb@gid.co.uk From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 00:38:59 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49D0C106566C; Tue, 25 Sep 2012 00:38:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8FBC8FC12; Tue, 25 Sep 2012 00:38:58 +0000 (UTC) Received: by vbmv11 with SMTP id v11so8599547vbm.13 for ; Mon, 24 Sep 2012 17:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G4cw9SJL7Z3Bt3dz/uXXrz94kwRf8hL3GKPBdUY5dVc=; b=Eg7xOBLGpQqjeot9ltpX26AhUetLtQzie0FcIEsOBy5xdsvfZ7Nv3/T7D10McgomLx 6TWUmbkNRuVcRrFQmGCZLSs8Ia++pgIJskOeyTtxNMsKpHu97N0vcBS/mM8j+VndWAuh sGswcR3IGAZvuu8CaOMmxCWa3Aou7xt+ybSuVSpW4wIvGLkk3XKYJeDjCQDamZJN0Kdu BWPDPTFYl5RlqgyGuWNfw2GQfJw6pgvltW3yeoYOvnGhjKlsJS/KpP7hpfvANG6U+/ik sNzX8txiF2cwkYXBtZs02sUBmvi6Oeq51n1can5X/qSzikR3pXx85sy+dThqp4jeD2Bd qmLw== MIME-Version: 1.0 Received: by 10.52.36.76 with SMTP id o12mr6763270vdj.40.1348533538044; Mon, 24 Sep 2012 17:38:58 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Mon, 24 Sep 2012 17:38:57 -0700 (PDT) In-Reply-To: References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> <20120924161654.GA1413@garage.freebsd.pl> Date: Mon, 24 Sep 2012 20:38:57 -0400 Message-ID: From: Ryan Stone To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 25 Sep 2012 00:38:59 -0000 On Mon, Sep 24, 2012 at 1:03 PM, Steven Hartland wrote: > Ahh yes looks like ATA supports BIO_DELETE via ATA_CFA_ERASE if the drive > announces ATA_PROTO_CFA, so I can only assume this is failing when it > shouldn't. > > Might be nice to investigate what's happening and fix, but as ATA is > being replaced by CAM ATA not sure its worth it? I believe that the code that you are looking at refers to a old command that is only implemented by CompactFlash cards. The ad(4) driver does not currently support the TRIM command. I have an internal patch that implements it for FreeBSD 8.2; if there's interest I could try to dig it out. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 01:55:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49F07106564A; Tue, 25 Sep 2012 01:55:23 +0000 (UTC) (envelope-from prvs=161529b2c5=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 7941C8FC0C; Tue, 25 Sep 2012 01:55:22 +0000 (UTC) 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 md50000215752.msg; Tue, 25 Sep 2012 02:55:19 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 25 Sep 2012 02:55:19 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=161529b2c5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Ryan Stone" References: <20120923195357.GO1454@garage.freebsd.pl><1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk><20120923222520.GS1454@garage.freebsd.pl><20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk><20120924161654.GA1413@garage.freebsd.pl> Date: Tue, 25 Sep 2012 02:55:21 +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.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 25 Sep 2012 01:55:23 -0000 ----- Original Message ----- From: "Ryan Stone" >> Ahh yes looks like ATA supports BIO_DELETE via ATA_CFA_ERASE if the drive >> announces ATA_PROTO_CFA, so I can only assume this is failing when it >> shouldn't. >> >> Might be nice to investigate what's happening and fix, but as ATA is >> being replaced by CAM ATA not sure its worth it? > > I believe that the code that you are looking at refers to a old > command that is only implemented by CompactFlash cards. The ad(4) > driver does not currently support the TRIM command. I have an > internal patch that implements it for FreeBSD 8.2; if there's interest > I could try to dig it out. It may well be but that's the only code in ad driver that I can see which sets DISKFLAG_CAN_DELETE and without that geom_disk should trigger EOPNOTSUPP and hence go into the unsupported not the fail case. 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 Sep 25 05:40:01 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35127106564A; Tue, 25 Sep 2012 05:40:01 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id E413F8FC08; Tue, 25 Sep 2012 05:40:00 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 0D187405; Tue, 25 Sep 2012 07:39:01 +0200 (CEST) Date: Tue, 25 Sep 2012 07:40:23 +0200 From: Pawel Jakub Dawidek To: Bob Bishop Message-ID: <20120925054023.GK1413@garage.freebsd.pl> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> <2EC5B55F-E969-4663-A753-1115D96F125C@gid.co.uk> <48D1FE59-C687-4D95-B4BF-7BC85F8B8F0A@gid.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uuKVzAmB+c+zQlhu" Content-Disposition: inline In-Reply-To: <48D1FE59-C687-4D95-B4BF-7BC85F8B8F0A@gid.co.uk> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 25 Sep 2012 05:40:01 -0000 --uuKVzAmB+c+zQlhu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2012 at 12:14:24AM +0100, Bob Bishop wrote: > Hi, >=20 > Still seems to be working OK, but: >=20 > seagoon# zpool status > pool: m1 > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scan: scrub repaired 0 in 0h2m with 0 errors on Mon Sep 24 23:52:08 2012 > config: >=20 > NAME STATE READ WRITE CKSUM > m1 ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/disk1 ONLINE 109M 0 0 > gpt/disk0 ONLINE 109M 0 0 >=20 > errors: No known data errors > seagoon# sysctl -a |grep _trim > kstat.zfs.misc.zio_trim.zio_trim_bytes: 228731904 > kstat.zfs.misc.zio_trim.zio_trim_success: 19406 > kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 > kstat.zfs.misc.zio_trim.zio_trim_failed: 0 > seagoon#=20 >=20 > No device errors logged in messages, and scrub comes up clean as you can = see. The read error count is increasing, but otherwise everything appears t= o work OK. Are you sure your world and kernel are in sync? I remember seeing similar problem when my userland was updated. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --uuKVzAmB+c+zQlhu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBhQ8YACgkQForvXbEpPzQCxACg9un8BZh6++nHBs5MYYGMo4YU VPwAoLjUTYIuLjl7GIBI4ep+bqSifFAl =pqRl -----END PGP SIGNATURE----- --uuKVzAmB+c+zQlhu-- From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 07:30:48 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1501D106564A; Tue, 25 Sep 2012 07:30:48 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id C43E18FC0C; Tue, 25 Sep 2012 07:30:47 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c56d:b4e7:bb34:8fd2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 04F2A4AC2D; Tue, 25 Sep 2012 11:30:45 +0400 (MSK) Date: Tue, 25 Sep 2012 11:30:43 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1952493143.20120925113043@serebryakov.spb.ru> To: Pawel Jakub Dawidek In-Reply-To: <20120923195357.GO1454@garage.freebsd.pl> References: <20120923195357.GO1454@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS TRIM support committed to HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 07:30:48 -0000 Hello, Pawel. You wrote 23 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2012 =D0=B3.,= 23:53:58: PJD> FYI, I just committed TRIM support to ZFS, especially useful for PJD> SSD-only pools. This is something I implemented long time ago, but was PJD> now motivated to get back to it and commit it finally by some great PJD> fixes and improvements from the zfsonlinux project (made by Etienne PJD> Dechamps). It is amazing! Solaris doesn't have it! Thanks for your great work! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 09:08:50 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08086106567C; Tue, 25 Sep 2012 09:08:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 53BA78FC0A; Tue, 25 Sep 2012 09:08:47 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q8P98qkQ045749; Tue, 25 Sep 2012 12:08:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q8P98edU040512; Tue, 25 Sep 2012 12:08:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q8P98eRd040511; Tue, 25 Sep 2012 12:08:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Sep 2012 12:08:40 +0300 From: Konstantin Belousov To: Baptiste Daroussin Message-ID: <20120925090840.GD35915@deviant.kiev.zoral.com.ua> References: <505DB4E6.8030407@smeets.im> <20120924224606.GE79077@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mSxgbZZZvrAyzONB" Content-Disposition: inline In-Reply-To: <20120924224606.GE79077@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ ...cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1407 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, 25 Sep 2012 09:08:50 -0000 --mSxgbZZZvrAyzONB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2012 at 12:46:07AM +0200, Baptiste Daroussin wrote: > Hi, >=20 > I have the exact same problem making: tinderbox and poudriere highly > unusable. > > This is really problematic because pointyhat also rely on nullfs and > zfs, which means we can't upgrade the building nodes if we need to for > example. > > regards, Bapt This is zfs bug. Filesystems shall not call getnewvnode() while holding internal locks. At least not the locks which are needed during reclaim. Nullfs changes amplified the probability of the problematic situation, since now nullfs vnodes are indeed cached instead of being recreated on each access, so the overall count of used vnodes could be twice as high. You might try to increase the kern.maxvnodes to reduce the probability of the recursive calls into vnlnru() from getnewvnode(). But for real, bug needs to be fixed in zfs. --mSxgbZZZvrAyzONB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBhdJgACgkQC3+MBN1Mb4hRygCfUgeh70w08J1a8gv3NRA84KUU R50AoM5Kh0P1nAzzDlC6YfPA8ds+2Bz0 =VXTg -----END PGP SIGNATURE----- --mSxgbZZZvrAyzONB-- From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 09:32:04 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34A90106566B; Tue, 25 Sep 2012 09:32:04 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id A53E18FC0A; Tue, 25 Sep 2012 09:32:03 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q8P9W2eK035942; Tue, 25 Sep 2012 10:32:02 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20120925054023.GK1413@garage.freebsd.pl> Date: Tue, 25 Sep 2012 10:31:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <363B4492-ADD1-42F1-80DA-BC9DAD21EBA2@gid.co.uk> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> <2EC5B55F-E969-4663-A753-1115D96F125C@gid.co.uk> <48D1FE59-C687-4D95-B4BF-7BC85F8B8F0A@gid.co.uk> <20120925054023.GK1413@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 25 Sep 2012 09:32:04 -0000 On 25 Sep 2012, at 06:40, Pawel Jakub Dawidek wrote: > On Tue, Sep 25, 2012 at 12:14:24AM +0100, Bob Bishop wrote: >> Hi, >>=20 >> Still seems to be working OK, but: >>=20 >> seagoon# zpool status >> pool: m1 >> state: ONLINE >> status: One or more devices has experienced an unrecoverable error. = An >> attempt was made to correct the error. Applications are = unaffected. >> action: Determine if the device needs to be replaced, and clear the = errors >> using 'zpool clear' or replace the device with 'zpool replace'. >> see: http://www.sun.com/msg/ZFS-8000-9P >> scan: scrub repaired 0 in 0h2m with 0 errors on Mon Sep 24 23:52:08 = 2012 >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> m1 ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> gpt/disk1 ONLINE 109M 0 0 >> gpt/disk0 ONLINE 109M 0 0 >>=20 >> errors: No known data errors >> seagoon# sysctl -a |grep _trim >> kstat.zfs.misc.zio_trim.zio_trim_bytes: 228731904 >> kstat.zfs.misc.zio_trim.zio_trim_success: 19406 >> kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 >> kstat.zfs.misc.zio_trim.zio_trim_failed: 0 >> seagoon#=20 >>=20 >> No device errors logged in messages, and scrub comes up clean as you = can see. The read error count is increasing, but otherwise everything = appears to work OK. >=20 > Are you sure your world and kernel are in sync? I remember seeing > similar problem when my userland was updated. I'm sure they are not. Buildworld time... > --=20 > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://tupytaj.pl -- Bob Bishop rb@gid.co.uk From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 16:13:52 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8329D106564A; Tue, 25 Sep 2012 16:13:52 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id EFA5B8FC0C; Tue, 25 Sep 2012 16:13:51 +0000 (UTC) Received: from rbpbp.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q8PGDnbk046413; Tue, 25 Sep 2012 17:13:50 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20120925054023.GK1413@garage.freebsd.pl> Date: Tue, 25 Sep 2012 17:13:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BB3A40C-AFE4-473D-9BB1-61704CE2D472@gid.co.uk> References: <20120923195357.GO1454@garage.freebsd.pl> <1735E492-3C3C-491A-82E2-884E976B4BC4@gid.co.uk> <20120923222520.GS1454@garage.freebsd.pl> <20CC6F2BF08D47ED802318697542A15D@multiplay.co.uk> <2EC5B55F-E969-4663-A753-1115D96F125C@gid.co.uk> <48D1FE59-C687-4D95-B4BF-7BC85F8B8F0A@gid.co.uk> <20120925054023.GK1413@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 25 Sep 2012 16:13:52 -0000 On 25 Sep 2012, at 06:40, Pawel Jakub Dawidek wrote: > On Tue, Sep 25, 2012 at 12:14:24AM +0100, Bob Bishop wrote: >> Hi, >>=20 >> Still seems to be working OK, but: >>=20 >> seagoon# zpool status >> pool: m1 >> state: ONLINE >> status: One or more devices has experienced an unrecoverable error. = An >> attempt was made to correct the error. Applications are = unaffected. >> action: Determine if the device needs to be replaced, and clear the = errors >> using 'zpool clear' or replace the device with 'zpool replace'. >> see: http://www.sun.com/msg/ZFS-8000-9P >> scan: scrub repaired 0 in 0h2m with 0 errors on Mon Sep 24 23:52:08 = 2012 >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> m1 ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> gpt/disk1 ONLINE 109M 0 0 >> gpt/disk0 ONLINE 109M 0 0 >>=20 >> errors: No known data errors >> seagoon# sysctl -a |grep _trim >> kstat.zfs.misc.zio_trim.zio_trim_bytes: 228731904 >> kstat.zfs.misc.zio_trim.zio_trim_success: 19406 >> kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 >> kstat.zfs.misc.zio_trim.zio_trim_failed: 0 >> seagoon#=20 >>=20 >> No device errors logged in messages, and scrub comes up clean as you = can see. The read error count is increasing, but otherwise everything = appears to work OK. >=20 > Are you sure your world and kernel are in sync? I remember seeing > similar problem when my userland was updated. Building world up to date fixes the problem. Good catch. > --=20 > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://tupytaj.pl -- Bob Bishop rb@gid.co.uk From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 16:24:36 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0285A106564A; Tue, 25 Sep 2012 16:24:36 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id BA8358FC17; Tue, 25 Sep 2012 16:24:35 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 99C0A589; Tue, 25 Sep 2012 18:23:28 +0200 (CEST) Date: Tue, 25 Sep 2012 18:24:53 +0200 From: Pawel Jakub Dawidek To: Glen Barber Message-ID: <20120925162453.GA1391@garage.freebsd.pl> References: <20120923195357.GO1454@garage.freebsd.pl> <20120924002041.GA1303@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <20120924002041.GA1303@glenbarber.us> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 25 Sep 2012 16:24:36 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 23, 2012 at 08:20:41PM -0400, Glen Barber wrote: > Hi Pawel, >=20 > On Sun, Sep 23, 2012 at 09:53:58PM +0200, Pawel Jakub Dawidek wrote: > > FYI, I just committed TRIM support to ZFS, especially useful for > > SSD-only pools. This is something I implemented long time ago, but was > > now motivated to get back to it and commit it finally by some great > > fixes and improvements from the zfsonlinux project (made by Etienne > > Dechamps). > >=20 >=20 > Great! Thanks for this. >=20 > Any chance you can document the following sysctls? None od the kstat sysctls are documented, they emulate kstat framework =66rom Solaris. We would need to modify a lot of vendor code to document those in 'sysctl -d' output. It still would be good to have them documented even elsewhere, eventhough most are rather self-explanatory. > root@kaos:/root # sysctl -d kstat.zfs.misc.zio_trim > kstat.zfs.misc.zio_trim:=20 > kstat.zfs.misc.zio_trim.zio_trim_bytes:=20 > kstat.zfs.misc.zio_trim.zio_trim_success:=20 > kstat.zfs.misc.zio_trim.zio_trim_unsupported:=20 > kstat.zfs.misc.zio_trim.zio_trim_failed:=20 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBh2tUACgkQForvXbEpPzSGHQCff2BiCYiBxb3jN2V9j/OVEWjP d0AAn3n6Xp3mWAo5mp7S/4OAQ2DMClv5 =Bv69 -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 18:29:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C9571065680; Tue, 25 Sep 2012 18:29:26 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E8E678FC1B; Tue, 25 Sep 2012 18:29:23 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q8PIPhU7004070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 20:25:43 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5061F6E9.6030104@omnilan.de> Date: Tue, 25 Sep 2012 20:24:41 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: attilio@freebsd.org References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5956BD299507D7C8FB9E48CE" Cc: Peter Holm , bdrewery@freebsd.org, FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions 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, 25 Sep 2012 18:29:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5956BD299507D7C8FB9E48CE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Attilio Rao am 21.09.2012 02:22 (localtime): > On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao wrot= e: >> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao wr= ote: >>> 2012/7/4 Attilio Rao : >>>> 2012/6/29 Attilio Rao : >>>>> As already published several times, according to the following plan= : >>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >>>>> >>>> I still haven't heard from Vivien or Edward, anyway as NTFS is >>>> basically only used RO these days (also the mount_ntfs code just >>>> permits RO mounting) I stripped all the uncomplete/bogus write suppo= rt >>>> with the following patch: >>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch >>>> >>>> This is an attempt to make the code smaller and possibly just focus = on >>>> the locking that really matter (as read-only filesystem). >>>> On some points of the patch I'm a bit less sure as we could easily >>>> take into account also write for things like vaccess() arguments, an= d >>>> make easier to re-add correct write support at some point in the >>>> future, but still force RO, even if the approach used in the patch i= s >>>> more correct IMHO. >>>> As an added bonus this patch cleans some dirty code in the mount >>>> operation and fixes a bug as vfs_mountedfrom() is called before real= >>>> mounting is completed and can still fail. >>> A quick update on this. >>> It looks like NTFS won't be completed for this GSoC thus I seriously >>> need to find an alternative to not loose the NTFS support entirely. >>> >>> I tried to look into the NTFS implementation right now and it is >>> really a poor support. As Peter has also verified, it can deadlock in= >>> no-time, it compeltely violates VFS rules, etc. IMHO it deserves a >>> complete rewrite if we would still support in-kernel NTFS. I also >>> tried to look at the NetBSD implementation. Their code is someway >>> similar to our, but they used very complicated (and very dirty) code >>> to do the locking. Even if I don't know well enough NetBSD VFS, I hav= e >>> the impression not all the races are correctly handled. Definitively,= >>> not something I would like to port. >>> >>> Considering all that the only viable option would be meaning an >>> userland filesystem implementation. My preferred choice would be to >>> import PUFFS and librefuse on top of it but honestly it requires a lo= t >>> of time to be completed, time which I don't currently have as in 2 >>> months Giant must be gone by the VFS. >>> >>> I then decided to switch to gnn's rewamp of FUSE patches. You can fin= d >>> his initial e-mail here: >>> http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html >>> >>> I've precisely got the second version of George's patch and created >>> this dolphin branch: >>> svn://svn.freebsd.org/base/projects/fuse >>> >>> I'm fixing low hanging fruit for the moment (see r238411 for example)= >>> and I still have to make a throughful review. >>> However my idea is to commit the support once: >>> - ntfs-3g is well stress-tested and proves to be bug-free >>> - there is no major/big technical issue pending after the reviews >> In the last weeks Peter, Florian, Gustau and I have been working in >> stabilizing fuse support. In the specific, Peter has worked hard on >> producing several utilities to nit stress-test fuse and in particular >> ntfs, Florian has improved fuse related ports (as explained later) and= >> Gustau has done sparse testing. I feel moderately satisfied by the >> level of stability of fuse now to propose to wider usage, in >> particular given the huge amount of complaints I'm hearing around >> about occasional fuse users. >> >> The final target of the project is to completely import into base the >> content of fusefs-kmod starting from earlier posted patches by George.= >> So far, we took care only of importing in the fuse branch the kernel >> part, so that fusefs-kmod userland part is still needed to be >> installed from ports, but I was studying the mount_fusefs licensing >> before to process with the import for the userland bits of it. >> >> The fixing has been happening here: >> svn://svn.freebsd.org/base/projects/fuse/ >> >> which is essentially an HEAD branch + fuse kernel components. In order= >> to get fuse, please compile a kernel from this branch with FUSE option= >> or simply build and load fuse module. >> Alternatively, a kernel patch that should work with HEAD@240684 is her= e: >> http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch >> >> I guess the patch can easilly apply to all FreeBSD branches, really, >> but it is not tested to anything else different then -CURRENT. >> >> As said you still need currently to build fusefs-kmod port. However >> you need these further patches, to be put in the fusefs-kmod/files/ >> directory:: >> http://www.freebsd.org/~attilio/fuse_import/patch-Makefile >> http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_= fusefs2.c >> >> They both disable the old kernel building/linking and import new >> functionality to let the new kernel support work well in presence of >> many consumers. >> >> In addition to fusefs-kmod, Bryan and Florian have also updated >> fusefs-lib and fusefs-ntfs ports. For instance, please refer to this >> e-mail: >> http://lists.freebsd.org/pipermail/freebsd-ports/2012-August/077950.ht= ml >> >> Even if this work is someway independent by the fusefs-kmod import, I >> warmly suggest to all of you to use their patches (and this what we >> have been testing so far too. > So, after Bryan and Florian ports update, I've also committed userland > part of fusefs-kmod and now the project branch fully mirrors > functionality of fusefs-kmod. The code in projects/fuse, infact, will > also install mount_fusefs as part of the fuse support. > > You can use the branch directly or this patch against -CURRENT at 24075= 2: > http://www.freebsd.org/~attilio/fuse_import/fuse_240752.patch Hello, first, many thanks for your effort bringing fusefs support into base with decent stability!!! I tried to compile RELENG_9_1 with your patch, but failed figuring out why compiling world stops with this error: src/sbin/mount_fusefs/mount_fusefs.c:319: error: void value not ignored as it ought to be *** [mount_fusefs.o] Error code 1 Thanks for any hint. -Harry --------------enig5956BD299507D7C8FB9E48CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlBh9u4ACgkQLDqVQ9VXb8gpAwCfb5VoWs1KCpoaAowEGEmXaYyo FGAAnRAqlgLO5GN46sxm63FoIcinBDX2 =ZOwb -----END PGP SIGNATURE----- --------------enig5956BD299507D7C8FB9E48CE-- From owner-freebsd-fs@FreeBSD.ORG Tue Sep 25 20:08:55 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF71106566B; Tue, 25 Sep 2012 20:08:55 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 659028FC1F; Tue, 25 Sep 2012 20:08:55 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 476CD28426; Tue, 25 Sep 2012 22:02:57 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6B45E28423; Tue, 25 Sep 2012 22:02:56 +0200 (CEST) Message-ID: <50620DEF.404@quip.cz> Date: Tue, 25 Sep 2012 22:02:55 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20120923195357.GO1454@garage.freebsd.pl> <20120924002041.GA1303@glenbarber.us> <20120925162453.GA1391@garage.freebsd.pl> In-Reply-To: <20120925162453.GA1391@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Glen Barber , freebsd-current@FreeBSD.org Subject: Re: ZFS TRIM support committed to HEAD. 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, 25 Sep 2012 20:08:55 -0000 Pawel Jakub Dawidek wrote: > On Sun, Sep 23, 2012 at 08:20:41PM -0400, Glen Barber wrote: >> Hi Pawel, [...] >> Great! Thanks for this. >> >> Any chance you can document the following sysctls? > > None od the kstat sysctls are documented, they emulate kstat framework > from Solaris. We would need to modify a lot of vendor code to document > those in 'sysctl -d' output. It still would be good to have them > documented even elsewhere, eventhough most are rather self-explanatory. There were some "sysctl documentation" project on the net (maybe som GSoC, I am not sure). Most sysctl's are self-explanatory - unfortunately only for knowledgeable developers or authors of the code. And sometimes even a short description (sysctl -d) is not enough. It explains meaning of some counter, but not the condition where / by what this counter is triggered. I think some public page on FreeBSD Wiki bould be good starting place for documenting all useful sysctls, their meaning, tips for tuning, what one can gain or lose by changing them etc. >> root@kaos:/root # sysctl -d kstat.zfs.misc.zio_trim >> kstat.zfs.misc.zio_trim: >> kstat.zfs.misc.zio_trim.zio_trim_bytes: >> kstat.zfs.misc.zio_trim.zio_trim_success: >> kstat.zfs.misc.zio_trim.zio_trim_unsupported: >> kstat.zfs.misc.zio_trim.zio_trim_failed: Miroslav Lachman From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 11:03:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 293BE1065670; Wed, 26 Sep 2012 11:03:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7D88FC12; Wed, 26 Sep 2012 11:03:03 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q8QB3utb023943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 13:03:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5062E0DE.70805@omnilan.de> Date: Wed, 26 Sep 2012 13:02:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: attilio@freebsd.org References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> <5061F6E9.6030104@omnilan.de> In-Reply-To: <5061F6E9.6030104@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26067994D3CAF391E3655218" Cc: Peter Holm , bdrewery@freebsd.org, FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions 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, 26 Sep 2012 11:03:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26067994D3CAF391E3655218 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 25.09.2012 20:24 (localtime): > schrieb Attilio Rao am 21.09.2012 02:22 (localtime): >> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao wro= te: >>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao w= rote: >>>> 2012/7/4 Attilio Rao : >>>>> 2012/6/29 Attilio Rao : >>>>>> As already published several times, according to the following pla= n: >>>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >>>>>> >>>>> I still haven't heard from Vivien or Edward, anyway as NTFS is >>>>> basically only used RO these days (also the mount_ntfs code just >>>>> permits RO mounting) I stripped all the uncomplete/bogus write supp= ort >>>>> with the following patch: >>>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch >>>>> >>>>> This is an attempt to make the code smaller and possibly just focus= on >>>>> the locking that really matter (as read-only filesystem). >>>>> On some points of the patch I'm a bit less sure as we could easily >>>>> take into account also write for things like vaccess() arguments, a= nd >>>>> make easier to re-add correct write support at some point in the >>>>> future, but still force RO, even if the approach used in the patch = is >>>>> more correct IMHO. >>>>> As an added bonus this patch cleans some dirty code in the mount >>>>> operation and fixes a bug as vfs_mountedfrom() is called before rea= l >>>>> mounting is completed and can still fail. >>>> A quick update on this. >>>> It looks like NTFS won't be completed for this GSoC thus I seriously= >>>> need to find an alternative to not loose the NTFS support entirely. >>>> >>>> I tried to look into the NTFS implementation right now and it is >>>> really a poor support. As Peter has also verified, it can deadlock i= n >>>> no-time, it compeltely violates VFS rules, etc. IMHO it deserves a >>>> complete rewrite if we would still support in-kernel NTFS. I also >>>> tried to look at the NetBSD implementation. Their code is someway >>>> similar to our, but they used very complicated (and very dirty) code= >>>> to do the locking. Even if I don't know well enough NetBSD VFS, I ha= ve >>>> the impression not all the races are correctly handled. Definitively= , >>>> not something I would like to port. >>>> >>>> Considering all that the only viable option would be meaning an >>>> userland filesystem implementation. My preferred choice would be to >>>> import PUFFS and librefuse on top of it but honestly it requires a l= ot >>>> of time to be completed, time which I don't currently have as in 2 >>>> months Giant must be gone by the VFS. >>>> >>>> I then decided to switch to gnn's rewamp of FUSE patches. You can fi= nd >>>> his initial e-mail here: >>>> http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html= >>>> >>>> I've precisely got the second version of George's patch and created >>>> this dolphin branch: >>>> svn://svn.freebsd.org/base/projects/fuse >>>> >>>> I'm fixing low hanging fruit for the moment (see r238411 for example= ) >>>> and I still have to make a throughful review. >>>> However my idea is to commit the support once: >>>> - ntfs-3g is well stress-tested and proves to be bug-free >>>> - there is no major/big technical issue pending after the reviews >>> In the last weeks Peter, Florian, Gustau and I have been working in >>> stabilizing fuse support. In the specific, Peter has worked hard on >>> producing several utilities to nit stress-test fuse and in particular= >>> ntfs, Florian has improved fuse related ports (as explained later) an= d >>> Gustau has done sparse testing. I feel moderately satisfied by the >>> level of stability of fuse now to propose to wider usage, in >>> particular given the huge amount of complaints I'm hearing around >>> about occasional fuse users. >>> >>> The final target of the project is to completely import into base the= >>> content of fusefs-kmod starting from earlier posted patches by George= =2E >>> So far, we took care only of importing in the fuse branch the kernel >>> part, so that fusefs-kmod userland part is still needed to be >>> installed from ports, but I was studying the mount_fusefs licensing >>> before to process with the import for the userland bits of it. >>> >>> The fixing has been happening here: >>> svn://svn.freebsd.org/base/projects/fuse/ >>> >>> which is essentially an HEAD branch + fuse kernel components. In orde= r >>> to get fuse, please compile a kernel from this branch with FUSE optio= n >>> or simply build and load fuse module. >>> Alternatively, a kernel patch that should work with HEAD@240684 is he= re: >>> http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch >>> >>> I guess the patch can easilly apply to all FreeBSD branches, really, >>> but it is not tested to anything else different then -CURRENT. >>> >>> As said you still need currently to build fusefs-kmod port. However >>> you need these further patches, to be put in the fusefs-kmod/files/ >>> directory:: >>> http://www.freebsd.org/~attilio/fuse_import/patch-Makefile >>> http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount= _fusefs2.c >>> >>> They both disable the old kernel building/linking and import new >>> functionality to let the new kernel support work well in presence of >>> many consumers. >>> >>> In addition to fusefs-kmod, Bryan and Florian have also updated >>> fusefs-lib and fusefs-ntfs ports. For instance, please refer to this >>> e-mail: >>> http://lists.freebsd.org/pipermail/freebsd-ports/2012-August/077950.h= tml >>> >>> Even if this work is someway independent by the fusefs-kmod import, I= >>> warmly suggest to all of you to use their patches (and this what we >>> have been testing so far too. >> So, after Bryan and Florian ports update, I've also committed userland= >> part of fusefs-kmod and now the project branch fully mirrors >> functionality of fusefs-kmod. The code in projects/fuse, infact, will >> also install mount_fusefs as part of the fuse support. >> >> You can use the branch directly or this patch against -CURRENT at 2407= 52: >> http://www.freebsd.org/~attilio/fuse_import/fuse_240752.patch > Hello, > > first, many thanks for your effort bringing fusefs support into base > with decent stability!!! > I tried to compile RELENG_9_1 with your patch, but failed figuring out > why compiling world stops with this error: > > src/sbin/mount_fusefs/mount_fusefs.c:319: error: void value not ignored= > as it ought to be > *** [mount_fusefs.o] Error code 1 Reason is sbin/mount/getmntopts.c, where checkpath() is void, which changed to int in r230226 8 monthas ago in head. Log: Change checkpath() to not exit on error. This is a prerequisite for fixing the mount(8) "failok" option. Some questions: Is this planned to be mfc'd and if so, how can one know? And another svn-dummie question: How can I get the committ as a diff? cvs= web provided an esay click if I remember correctly. Thanks, -Harry --------------enig26067994D3CAF391E3655218 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlBi4OMACgkQLDqVQ9VXb8jdSQCbBH3R3wQwRWu0M9XR9PxILRPt oKQAoMGB5IVIx7Ukuk/DSP8vXwp/W29B =sgvs -----END PGP SIGNATURE----- --------------enig26067994D3CAF391E3655218-- From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 11:38:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E54E21065670 for ; Wed, 26 Sep 2012 11:38:43 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93AD78FC0C for ; Wed, 26 Sep 2012 11:38:43 +0000 (UTC) Received: by vbmv11 with SMTP id v11so623627vbm.13 for ; Wed, 26 Sep 2012 04:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nKrcLzjHJHbfwCTm9C+WrUuB3L0JlIB4ka71QC1lVdc=; b=Pq4rJIxEgKyOi4ejTc0yVqsYzM8wYVph1ThMrwF4MajopP2rxWmpQ/hdiHwJlMH4As znKd+9OX5o63fthwFvxn03rJyMFuLp+JhSTtDPsEMBAwH85BKIv52T+Pd98W8mETW8wB uJk/mR0gN3D641lgSpkJeMsErJ+l3MEMjEufQnUdieTjMnSgcWwgNL853Kd3Zy9bAVg5 aBJzk3UC0htD6Vct7/uM7z6Ikip9fcB1PoHOuyGwRUjwtd5rmIlcBVziziAoxc1vGzk6 cPx8ipjaQTCa/Xw4ZLIved6BcoCW5XLsPbecv6pSsgw8hMFDvStFk9mzH7rwtC6mzd60 2Qig== MIME-Version: 1.0 Received: by 10.220.149.6 with SMTP id r6mr85582vcv.53.1348659522273; Wed, 26 Sep 2012 04:38:42 -0700 (PDT) Received: by 10.58.54.137 with HTTP; Wed, 26 Sep 2012 04:38:42 -0700 (PDT) In-Reply-To: References: <20120917121925.GQ37286@deviant.kiev.zoral.com.ua> <20120917183654.GA13273@x2.osted.lan> <20120918084924.GY37286@deviant.kiev.zoral.com.ua> Date: Wed, 26 Sep 2012 07:38:42 -0400 Message-ID: From: "b. f." To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Problems after recent nullfs,vfs changes in 10.0-CURRENT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 11:38:44 -0000 On 9/18/12, b. f. wrote: > The following deals with some problems exposed by r240283-5, > particularly (but not only) when used with changes to tmpfs that were > first proposed by kib@ on 21 June 2010 on this list, in a thread > entitled "Tmpfs elimination of double copy": > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=20463+0+archive/2010/freebsd-fs/20100627.freebsd-fs > > On 9/18/12, Konstantin Belousov wrote: >> On Mon, Sep 17, 2012 at 08:36:54PM +0200, Peter Holm wrote: >>> On Mon, Sep 17, 2012 at 03:19:25PM +0300, Konstantin Belousov wrote: >>> > Please mail fs@, possibly Cc:-ing me. >>> > >>> > On Mon, Sep 17, 2012 at 03:04:46AM -0400, b. f. wrote: >>> > > The recent nullfs or vfs changes (r240283-5) have exposed some >>> > > problems with my tinderbox. In this tinderbox, I've been using >>> > > recent >>> > > versions of -CURRENT with Gleb's tmpfs rbtree patch: >>> > > >>> > > http://people.freebsd.org/~gleb/tmpfs-nrbtree.1.patch >>> > > >>> > > and a merged version of your tmpfs single-buffer patch: >>> > > >>> > > http://people.freebsd.org/~kib/misc/tmpfs.12.patch >>> > > >>> > > The tinderbox performs builds in a tmpfs filesystem that is nullfs >>> > > grafted to a ufs filesystem. After r240283-5, builds of >>> > > ports/lang/ocaml failed when a cp(1) of an executable failed with >>> > > ETXTBSY. After reverting r240285, the builds of ocaml succeeded. >>> > > >>> > > I've attached logs of the failed and successful builds. Can you >>> > > guess >>> > > whether the problem is solely due to the recent nullfs and vfs >>> > > changes, or to some defect in Gleb's proposed changes, or to a >>> > > problem >>> > > with your proposed tmpfs change, or my merging of it? What further >>> > > changes or tests would you suggest to help find the source of the >>> > > problem? >>> > > >>> > > I've attached a diff of the relevant changes to the system sources >>> > > used in the tinderbox, and logs of the successful (*.log) and >>> > > unsuccessful (*.log.error) ocaml builds. >>> > >>> > Please show me the mount -v output, and specify which filesystems >>> > are used where. > > The following is a typical layout for one run of the tinderbox (which > is in /home/shared/freebsd/tinderbox): > > /dev/ufs/d1root on / (ufs, local, noatime, writes: sync 13 async 25, > reads: sync 553 async 42, fsid 8aabfa4d68614a9f) > devfs on /dev (devfs, local, fsid 00ff007171000000) > tmpfs on /tmp (tmpfs, local, nosuid, fsid 01ff008787000000) > /dev/ufs/d1var on /var (ufs, local, noatime, journaled soft-updates, > writes: sync 15 async 269, reads: sync 664 async 12, fsid > a5abfa4d331091c9) > /dev/ufs/d1usr on /usr (ufs, local, noatime, journaled soft-updates, > writes: sync 2 async 0, reads: sync 765 async 12, fsid > b4abfa4d94c0f782) > /dev/ufs/d1usrlocal on /usr/local (ufs, local, noatime, journaled > soft-updates, writes: sync 32 async 298, reads: sync 2867 async 106, > fsid c4abfa4d96ab4351) > /dev/ufs/d1home on /home (ufs, local, noatime, journaled soft-updates, > writes: sync 16 async 123, reads: sync 2065 async 268, fsid > ceabfa4d9bb85870) > > the filesystem used for the port builds: > > /tmp/tinderbox/7.4-amd64-u1 on > /home/shared/freebsd/tinderbox/7.4-amd64-u1 (nullfs, local, fsid > 03ff002929000000) > /home/shared/freebsd/ports/head on > /home/shared/freebsd/tinderbox/7.4-amd64-u1/a/ports (nullfs, local, > read-only, fsid 04ff002929000000) > /home/shared/freebsd/tinderbox/jails/7.4-amd64/src on > /home/shared/freebsd/tinderbox/7.4-amd64-u1/usr/src (nullfs, local, > read-only, fsid 05ff002929000000) > devfs on /home/shared/freebsd/tinderbox/7.4-amd64-u1/dev (devfs, > local, fsid 06ff007171000000) > /home/shared/freebsd/distfiles on > /home/shared/freebsd/tinderbox/7.4-amd64-u1/distcache (nullfs, local, > fsid 07ff002929000000) > linprocfs on /home/shared/freebsd/tinderbox/7.4-amd64-u1/compat/linux/proc > (linprocfs, local, fsid 08ff00b5b5000000) > procfs on /home/shared/freebsd/tinderbox/7.4-amd64-u1/proc (procfs, > local, fsid 09ff000202000000) > >>> > >>> > The issue almost definitely is the held reference on the vm object. >>> > Lets remove Gleb' patches from the picture at all. >>> > >>> > After rethinking VV_TEXT handling both for nullfs and tmpfs (patched), >>> > I see two issues ATM: >>> > >>> > 1. VV_TEXT may be set either on the lower vnode, or on the nullfs >>> > vnode. >>> > So if you executed a file from nullfs alias, lower vnode does not get >>> > VV_TEXT set, and executable can still be opened for write. >>> > >>> > 2. For tmpfs, the hack I added to clear VV_TEXT if swap vm object >>> > reference >>> > count == 1, is not called often enough. This allows to VV_TEXT to >>> > leak, >>> > esp. >>> > because nullfs after r240283 is not eager to reclaim its vnodes. >>> > >>> > I updated my branch with tmpfs patches with the following changes: >>> > >>> > 1. nullfs now bypasses the VV_TEXT set and clear operations to the >>> > lower >>> > vnode. >>> > >>> > 2. the tmpfs_clear_text() hack is removed, instead >>> > vm_object_deallocate() >>> > clears VV_TEXT on the tmpfs vnode if reference count goes to 1. >>> > >>> > Updated patch is at >>> > http://people.freebsd.org/~kib/misc/tmpfs.13.patch >>> > I tested it very lightly, so to say. >>> >>> I see the problem on a pristine r240611. Test scenario included. >>> >>> + mdconfig -a -t swap -s 1g -u 5 >>> + bsdlabel -w md5 auto >>> + newfs -U md5a >>> + mount /dev/md5a /mnt2 >>> + chmod 777 /mnt2 >>> + mount >>> + grep /mnt >>> + grep -q tmpfs >>> + mount -t tmpfs tmpfs /mnt >>> + chmod 777 /mnt >>> + mkdir /mnt2/mp >>> + mount -t nullfs /mnt /mnt2/mp >>> + cp /usr/bin/true /mnt2/mp/true >>> + /mnt/true >>> + >>> + rm -f /mnt/true >>> + cp /usr/bin/true /mnt2/mp/true >>> + /mnt2/mp/true >>> + >>> ./nullfs12.sh: cannot create /mnt2/mp/true: Text file busy >>> + echo FAIL 2 >>> FAIL 2 >>> + mount >>> + egrep 'tmpfs|nullfs|/mnt |/mnt2 ' >>> /dev/md5a on /mnt2 (ufs, local, soft-updates) >>> tmpfs on /mnt (tmpfs, NFS exported, local) >>> /mnt on /mnt2/mp (nullfs, local) >>> + rm -f /mnt2/mp/true >> >> Yes, this is very close if not identical to the only test which I >> performed >> with the tmpfs.13.patch. >> > > I can no longer reproduce the port build failures on r240651 amd64 > after applying your tmpfs.13.patch, and I haven't encountered any > other obvious problems in the short time that I've been using it. I > did not rerun Peter Holm's nullfs12.sh test, since you had already > subjected your patch to a similar test. > After further experiments, it appears that there are still some problems with tmpfs.13.patch and the recent vfs/nullfs changes. If I use: sysctl debug.iosize_max_clamp=0 I observe build failures with some ports, when various utilities fail with EIO. For example textproc/libxml2: "... /bin/sh ../../libtool --tag=CC --mode=link cc -O2 -pipe -fno-strict-aliasing -std=gnu89 -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -L/usr/local/lib -pthread -o tree1 tree1.o ../../libxml2.la -lz -L/usr/local/lib -liconv -lm eval: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error eval: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error ../../libtool: printf: Input/output error gmake[3]: Leaving directory `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc/examples' gmake[3]: Entering directory `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc' gmake[3]: Nothing to be done for `all-am'. gmake[3]: Leaving directory `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc' gmake[2]: Leaving directory `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc' Making all in example gmake[2]: Entering directory `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/example' cc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -I./include -D_REENTRANT -I/usr/local/include -I/usr/local/include -O2 -pipe -fno-strict-aliasing -std=gnu89 -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -MT gjobread.o -MD -MP -MF .deps/gjobread.Tpo -c -o gjobread.o gjobread.c mv -f .deps/gjobread.Tpo .deps/gjobread.Po /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe -fno-strict-aliasing -std=gnu89 -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -L/usr/local/lib -pthread -o gjobread gjobread.o ../libxml2.la -lz -L/usr/local/lib -liconv -lm eval: printf: Input/output error ../libtool: printf: Input/output error ../libtool: printf: Input/output error gmake[2]: *** [gjobread] Error 1 gmake[2]: Leaving directory `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/example' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8' gmake: *** [all] Error 2 *** Error code 1 Stop in /a/ports/textproc/libxml2." or x11/libxcb: "... ===> Registering installation for libxcb-1.7 /usr/bin/tr: Input/output error /usr/bin/tr: Input/output error /usr/bin/tr: Input/output error ================================================================ ======================================== ===> Building package for libxcb-1.7 Deleting libxcb-1.7 === Checking filesystem state /buildscript: tr: Input/output error /buildscript: tr: Input/output error ..." There seems to be a temporal element to these failures, as they occur often, but not always. So far I have not been able to produce them with the default debug.iosize_max_clamp=1, or with debug.iosize_max_clamp=0 but without tmpfs.13.patch. And they didn't occur before the recent vfs/nullfs changes with timpfs.12.patch, regardless of the debug.iosize_max_clamp setting. Regards, b. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 13:53:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFA891065670; Wed, 26 Sep 2012 13:53:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A34078FC1D; Wed, 26 Sep 2012 13:53:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0648CB9B2; Wed, 26 Sep 2012 09:53:31 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Wed, 26 Sep 2012 09:41:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <505DEF5F.8060401@FreeBSD.org> In-Reply-To: <505DEF5F.8060401@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209260941.29016.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 26 Sep 2012 09:53:31 -0400 (EDT) Cc: Andriy Gapon Subject: Re: zfsboot and zfsloader: normalization of filesystem names 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, 26 Sep 2012 13:53:31 -0000 On Saturday, September 22, 2012 1:03:27 pm Andriy Gapon wrote: > > Currently zfsboot uses the following format to specify a ZFS filesystem name in > a full file path: > poolname:filesystem/name:/path/to/file > ZFS loader uses this format: > zfs:poolname/filesystemname:/path/to/file > > The following patchset: > http://people.freebsd.org/~avg/zfs-boot-naming.diff > unifies the naming. > zfsboot format will be: poolname/filesystemname:/path/to/file > Note that it is still different from zfsloader - "zfs:" prefix is missing. This > is because unlike the loader zfsboot supports only ZFS filesystem, so the prefix > is redundant. But I can still add support for it if there is a popular request. I think this idea sounds sound. You could easily let zfsboot support both by just having it skip over a 'zfs:' prefix if it sees one. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 14:22:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89D59106566C for ; Wed, 26 Sep 2012 14:22:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D054E8FC0A for ; Wed, 26 Sep 2012 14:22:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q8QEMlO9002448; Wed, 26 Sep 2012 17:22:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q8QEMZ2x096935; Wed, 26 Sep 2012 17:22:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q8QEMZ4m096934; Wed, 26 Sep 2012 17:22:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Sep 2012 17:22:35 +0300 From: Konstantin Belousov To: bf1783@gmail.com Message-ID: <20120926142235.GN35915@deviant.kiev.zoral.com.ua> References: <20120917121925.GQ37286@deviant.kiev.zoral.com.ua> <20120917183654.GA13273@x2.osted.lan> <20120918084924.GY37286@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CQDko/0aYvuiEzgn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: Problems after recent nullfs,vfs changes in 10.0-CURRENT 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, 26 Sep 2012 14:22:43 -0000 --CQDko/0aYvuiEzgn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 26, 2012 at 07:38:42AM -0400, b. f. wrote: > After further experiments, it appears that there are still some > problems with tmpfs.13.patch and the recent vfs/nullfs changes. If I > use: >=20 > sysctl debug.iosize_max_clamp=3D0 >=20 > I observe build failures with some ports, when various utilities fail > with EIO. For example textproc/libxml2: >=20 > "... > /bin/sh ../../libtool --tag=3DCC --mode=3Dlink cc -O2 -pipe > -fno-strict-aliasing -std=3Dgnu89 -pedantic -W -Wformat -Wunused > -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat > -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow > -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return > -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline > -Wredundant-decls -L/usr/local/lib -pthread -o tree1 tree1.o > ../../libxml2.la -lz -L/usr/local/lib -liconv -lm > eval: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > eval: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > ../../libtool: printf: Input/output error > gmake[3]: Leaving directory > `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc/examples' > gmake[3]: Entering directory > `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc' > gmake[3]: Nothing to be done for `all-am'. > gmake[3]: Leaving directory > `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc' > gmake[2]: Leaving directory > `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/doc' > Making all in example > gmake[2]: Entering directory > `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/example' > cc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -I./include > -D_REENTRANT -I/usr/local/include -I/usr/local/include -O2 -pipe > -fno-strict-aliasing -std=3Dgnu89 -pedantic -W -Wformat -Wunused > -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat > -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow > -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return > -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline > -Wredundant-decls -MT gjobread.o -MD -MP -MF .deps/gjobread.Tpo -c -o > gjobread.o gjobread.c > mv -f .deps/gjobread.Tpo .deps/gjobread.Po > /bin/sh ../libtool --tag=3DCC --mode=3Dlink cc -O2 -pipe > -fno-strict-aliasing -std=3Dgnu89 -pedantic -W -Wformat -Wunused > -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat > -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow > -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return > -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline > -Wredundant-decls -L/usr/local/lib -pthread -o gjobread gjobread.o > ../libxml2.la -lz -L/usr/local/lib -liconv -lm > eval: printf: Input/output error > ../libtool: printf: Input/output error > ../libtool: printf: Input/output error > gmake[2]: *** [gjobread] Error 1 > gmake[2]: Leaving directory > `/work/a/ports/textproc/libxml2/work/libxml2-2.7.8/example' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/work/a/ports/textproc/libxml2/work/libxml2-= 2.7.8' > gmake: *** [all] Error 2 > *** Error code 1 >=20 > Stop in /a/ports/textproc/libxml2." >=20 > or x11/libxcb: >=20 > "... > =3D=3D=3D> Registering installation for libxcb-1.7 > /usr/bin/tr: Input/output error > /usr/bin/tr: Input/output error > /usr/bin/tr: Input/output error > =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=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=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D> Building package for libxcb-1.7 > Deleting libxcb-1.7 >=20 > =3D=3D=3D Checking filesystem state > /buildscript: tr: Input/output error > /buildscript: tr: Input/output error > ..." >=20 > There seems to be a temporal element to these failures, as they occur > often, but not always. So far I have not been able to produce them > with the default debug.iosize_max_clamp=3D1, or with > debug.iosize_max_clamp=3D0 but without tmpfs.13.patch. And they didn't > occur before the recent vfs/nullfs changes with timpfs.12.patch, > regardless of the debug.iosize_max_clamp setting. >=20 > Regards, > b. This is very strange. Run the build under ktrace -i and provide me with the fragment of the kdump output around the failure. --CQDko/0aYvuiEzgn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBjD6sACgkQC3+MBN1Mb4jKfwCghmRKR3ro0mzFLDQin8XGPGvw /akAnjC74C3nv+7paVhQCYzBZrqCS4wb =Y1tP -----END PGP SIGNATURE----- --CQDko/0aYvuiEzgn-- From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 14:37:09 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B44C8106564A for ; Wed, 26 Sep 2012 14:37:09 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 30E908FC1A for ; Wed, 26 Sep 2012 14:37:08 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id q8QEb0Qg029601 for ; Wed, 26 Sep 2012 17:37:00 +0300 (EEST) Message-ID: <20120926173700.29600@relay.ibs.dn.ua> Date: Wed, 26 Sep 2012 17:37:00 +0300 From: Zeus Panchenko To: cc: Organization: I.B.S. LLC X-Mailer: MH-E 8.2; GNU Mailutils 2.99.97; GNU Emacs 23.4.1 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ Subject: how to access ZFS snapshot via iSCSI X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 14:37:09 -0000 hi all, please, may somebody advice, can I access ZFS snapshot via iSCSI? I do can get access to ZFS filesystem and zvol, but how to access ZFS snapshot? I am trying that via istgt, in istgt.conf I put: [LogicalUnit4] Comment "ZVOL 500Gb to test" TargetName zvol-totest Mapping PortalGroup1 InitiatorGroup1 AuthMethod Auto AuthGroup AuthGroup1 UseDigest Auto UnitType Disk QueueDepth 64 LUN0 Storage /dev/zvol/storage/win/zvol-totest Auto and I can mount it and use when I put [LogicalUnit5] Comment "snapshot of ZVOL 500Gb totest" TargetName zvol-totest-snapshot Mapping PortalGroup1 InitiatorGroup1 AuthMethod Auto AuthGroup AuthGroup1 UseDigest Auto UnitType Disk QueueDepth 64 LUN0 Storage /dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11 Auto and trying to restart istgt, I'm getting: LU4 HDD UNIT LU4: LUN0 file=/dev/zvol/storage/win/zvol-totest, size=536870912000 LU4: LUN0 1048576000 blocks, 512 bytes/block LU4: LUN0 500.0GB storage for iqn.2007-09.jp.ne.peach.istgt:zvol-totest LU4: LUN0 serial 10000004 LU4: LUN0 read cache enabled, write cache enabled LU4: LUN0 command queuing enabled, depth 64 LU5 HDD UNIT LU5: LUN0 file=/dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11, size=536870912000 LU5: LUN0 1048576000 blocks, 512 bytes/block istgt_lu_disk.c: 642:istgt_lu_disk_init: ***ERROR*** LU5: LUN0: open error(errno=17) istgt_lu.c:2091:istgt_lu_init_unit: ***ERROR*** LU5: lu_disk_init() failed istgt_lu.c:2166:istgt_lu_init: ***ERROR*** LU5: lu_init_unit() failed istgt.c:2799:main: ***ERROR*** istgt_lu_init() failed /usr/local/etc/rc.d/istgt: WARNING: failed to start istgt where am I wrong? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 16:11:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E94F61065679 for ; Wed, 26 Sep 2012 16:11:10 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 285278FC1C for ; Wed, 26 Sep 2012 16:11:09 +0000 (UTC) Received: (qmail 62739 invoked by uid 89); 26 Sep 2012 16:11:03 -0000 Received: by simscan 1.4.0 ppid: 62734, pid: 62736, t: 0.0367s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15406 Received: from unknown (HELO suse2.ip-tech.ch) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 26 Sep 2012 16:11:03 -0000 Date: Wed, 26 Sep 2012 18:10:59 +0200 From: Rainer Duffner To: freebsd-fs@freebsd.org Message-ID: <20120926181059.58756815@suse2.ip-tech.ch> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FreeBSD 9.0 NFS client to Smart OS NFS server: intermittently slow 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, 26 Sep 2012 16:11:11 -0000 Hi, we've got a problem with a FreeBSD 9.0 NFS Client to a SmartOS server[1] via Gigabit-Ethernet. First, while the transfers where going over a lagg(4) interface, they were abysmally slow (something like 1MB/s). We've removed the lagg(4) interface and it's now just bce(4) and it can write with about 20MB/s. We have a Windows2008-server that mounts both the NFS-export and a Samba-share that the server also exports and the Windows-server can write with 50MB/s to the NFS-export and upto 112MB/s to the Samba-share. So, I don't think it's an issue with the SmartOS server I tried both NFS v3 and NFSv4, but it doesn't make any significant difference. Can this be fixed by "just" upgrading to 9.1? It's FreeBSD 9.0 AMD64 running on HP DL3x0 G7 hardware. The client is running some sort of Python Web-App where people upload (larger) files - and the uploads usually "stall" the web-app if the NFS-transfer is too slow. [1] It's a stand-alone SmartOS installation booted from an USB-stick. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 16:35:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AA04106566C for ; Wed, 26 Sep 2012 16:35:31 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5EAE68FC12 for ; Wed, 26 Sep 2012 16:35:31 +0000 (UTC) Received: by ieak10 with SMTP id k10so2746767iea.13 for ; Wed, 26 Sep 2012 09:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kg5ZVmocPn5rl/kTiYqpf4mhdUFY0NW7+ktCkNIzFmA=; b=iPj1nIurmJO/YXEw6oLlBTx2ODpGxsTHWC+KXwZybCStRSs6znH6JlFx4fVZfWTKL9 Ed1oxBXdforqg93Ckan1qUNKqAlsv0UKNgtUhZ1t0rdjzPlADvHRgaiPb4S8+Uhb4FJC /vcZbdELKaRkL/qe+KJppjyte19JXeiNWmqWyYA+KVe7duJIQUH/LmelusUuV4dwIV/5 07hVq+jog5hLwX3wkI9wDnwAqP7uvvKm7HrHsQ5y4P1y9ZeyFWffN0arHMoHmt1kOWze 4/C+BQSh9hyIHwuRqfb7Arfu8O0HY+b6S5p1sCu6a2yIs/Z9yCUr6Vq/hI3OFTL3LNG0 7Fog== Received: by 10.50.220.129 with SMTP id pw1mr1444806igc.47.1348677330923; Wed, 26 Sep 2012 09:35:30 -0700 (PDT) Received: from [192.168.0.120] ([173.157.79.63]) by mx.google.com with ESMTPS id ua2sm3026333igb.7.2012.09.26.09.35.29 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 09:35:30 -0700 (PDT) Message-ID: <50632ED0.2050901@gmail.com> Date: Wed, 26 Sep 2012 11:35:28 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <505DEF5F.8060401@FreeBSD.org> <201209260941.29016.jhb@freebsd.org> In-Reply-To: <201209260941.29016.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: zfsboot and zfsloader: normalization of filesystem names 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, 26 Sep 2012 16:35:31 -0000 On 9/26/2012 8:41 AM, John Baldwin wrote: > On Saturday, September 22, 2012 1:03:27 pm Andriy Gapon wrote: >> >> Currently zfsboot uses the following format to specify a ZFS filesystem name in >> a full file path: >> poolname:filesystem/name:/path/to/file >> ZFS loader uses this format: >> zfs:poolname/filesystemname:/path/to/file >> >> The following patchset: >> http://people.freebsd.org/~avg/zfs-boot-naming.diff >> unifies the naming. >> zfsboot format will be: poolname/filesystemname:/path/to/file >> Note that it is still different from zfsloader - "zfs:" prefix is missing. This >> is because unlike the loader zfsboot supports only ZFS filesystem, so the prefix >> is redundant. But I can still add support for it if there is a popular request. > > I think this idea sounds sound. You could easily let zfsboot support both by just > having it skip over a 'zfs:' prefix if it sees one. > My $0.02 -- Keep "zfs:" in for consistency's sake. -- Chuck Burns From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 19:50:14 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 203831065673 for ; Wed, 26 Sep 2012 19:50:14 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id E05748FC08 for ; Wed, 26 Sep 2012 19:50:13 +0000 (UTC) Received: by padbi1 with SMTP id bi1so801154pad.13 for ; Wed, 26 Sep 2012 12:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ObKzzcD/LbwOf2s/yrMmeXBZpIoO2vqm0egkG1iuxHQ=; b=TuJfgfNuXJgWdYhs97K/CHIkVsEPsevWyVSw0DMynnN8LCtU/pKuBOVkdq47ac3qf0 5Uyu7pxQe+fJsUZ3Qax8sCVVkB+iR0MXy+K2/I+87enFIoz8/Gv0SnosX5ld8xY8eRCx 5QhtGtQkN4M1mKiOnOMc0Y0RQTrauvafBDmAs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ObKzzcD/LbwOf2s/yrMmeXBZpIoO2vqm0egkG1iuxHQ=; b=cL1uMvdQj9/VveDAvEVXkznf22EZfGZVxhXkkxdMO3Iw1pCjvnHMdNKAy/S1sEK6ry aMX1jtWEzn+rFhdH3EpFYDdHUXdKEoTjvq1Ma1CdTFO8bRoU9t0y4mBX387etvcP3ftB ukJwgBvGjyZUX9Cni+ZApTQiPwFJF61Dgvny8t89pWB5hS7aG9LFE0J1sy/C78yJ8Xh0 cBKpT5o6t4Ar+fANy6eC6bc9xO9mW2smNxXzWqisLVJMtv+2P/Gtl98f9xm4CpFUiRyB wJjdg6E+WbCNFOuZDu9lKKqWdLTnz3WzS2xkeoxeWk73/movpwgizy2Bbfj3i9cs1Q4K x/gA== MIME-Version: 1.0 Received: by 10.68.191.168 with SMTP id gz8mr1131963pbc.128.1348689013418; Wed, 26 Sep 2012 12:50:13 -0700 (PDT) Received: by 10.68.25.69 with HTTP; Wed, 26 Sep 2012 12:50:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Sep 2012 12:50:13 -0700 Message-ID: From: Tim Gustafson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlXpGQR7PIsQOfide5g71p1Frn4D+d+Az/PNf4FkEvJv3wcKmrntQVOKBvWTh9FDmUYBjhv Subject: Re: Exporting ZFS File System to Multiple Subnets 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, 26 Sep 2012 19:50:14 -0000 > And it seems that ZFS somehow > gets in the way of /etc/exports for ZFS file systems, so that if I > turn off sharenfs ("zfs inherit sharenfs tank/export; zfs inherit > sharenfs tank/projects") it actually blocks the export lines in > /etc/exports from being mounted. So, this was incorrect. Something else was going on that was preventing the exports in /etc/exports from working; after a few reboots, with sharenfs set to "inherited" for all file systems, we are able to specify exports in /etc/exports again. -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 22:51:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30901106567E for ; Wed, 26 Sep 2012 22:51:19 +0000 (UTC) (envelope-from gezeala@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05C578FC16 for ; Wed, 26 Sep 2012 22:51:18 +0000 (UTC) Received: by dadz9 with SMTP id z9so250960dad.13 for ; Wed, 26 Sep 2012 15:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Oy5NODXsKZBw4eQ9q0e12vPfHRehQKG7NiKaZMK6t8=; b=z36aEdPaH/hnmxt6UGmSYnRyo4VdBf8xJ3tZDa3NFOhxUBechPG/t0jxBlvUcOn4w1 HzAQfwUBwGgDuNFkydpydqbOAPRh6JTHjCSu93wlFlqz0d+DijO4qXq27ysMj3lnu5m5 qtkSr00JQnxLrbRtvejDCgNLoMGcyr6ZKGSearD9ls0CssnWE859VKmaHfy6i4lecvNB JM3ivMf3aqJcdcwC4BjuGUAYSf30FFKftaiEbwvz33oH/xM9mwiFrj4cupxTkTMKTIaw +GMAYm+ZE1NfsRjk/6LWCDaEfK51l/jABuur/NRrhyLmMZJ+AIHem3spodaDiz1qRVWh IyhQ== Received: by 10.68.232.163 with SMTP id tp3mr6386974pbc.44.1348699878205; Wed, 26 Sep 2012 15:51:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.69 with HTTP; Wed, 26 Sep 2012 15:50:37 -0700 (PDT) In-Reply-To: <20120926173700.29600@relay.ibs.dn.ua> References: <20120926173700.29600@relay.ibs.dn.ua> From: =?ISO-8859-1?Q?Gezeala_M=2E_Bacu=F1o_II?= Date: Wed, 26 Sep 2012 15:50:37 -0700 Message-ID: To: Zeus Panchenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI 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, 26 Sep 2012 22:51:19 -0000 On Wed, Sep 26, 2012 at 7:37 AM, Zeus Panchenko wrote: > hi all, > > please, may somebody advice, can I access ZFS snapshot via iSCSI? > > I do can get access to ZFS filesystem and zvol, but how to access ZFS snapshot? > > I am trying that via istgt, in istgt.conf I put: > > [LogicalUnit4] > Comment "ZVOL 500Gb to test" > TargetName zvol-totest > Mapping PortalGroup1 InitiatorGroup1 > AuthMethod Auto > AuthGroup AuthGroup1 > UseDigest Auto > UnitType Disk > QueueDepth 64 > LUN0 Storage /dev/zvol/storage/win/zvol-totest Auto > > and I can mount it and use > > when I put > > [LogicalUnit5] > Comment "snapshot of ZVOL 500Gb totest" > TargetName zvol-totest-snapshot > Mapping PortalGroup1 InitiatorGroup1 > AuthMethod Auto > AuthGroup AuthGroup1 > UseDigest Auto > UnitType Disk > QueueDepth 64 > LUN0 Storage /dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11 Auto > > and trying to restart istgt, I'm getting: > > LU4 HDD UNIT > LU4: LUN0 file=/dev/zvol/storage/win/zvol-totest, size=536870912000 > LU4: LUN0 1048576000 blocks, 512 bytes/block > LU4: LUN0 500.0GB storage for iqn.2007-09.jp.ne.peach.istgt:zvol-totest > LU4: LUN0 serial 10000004 > LU4: LUN0 read cache enabled, write cache enabled > LU4: LUN0 command queuing enabled, depth 64 > LU5 HDD UNIT > LU5: LUN0 file=/dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11, size=536870912000 > LU5: LUN0 1048576000 blocks, 512 bytes/block > istgt_lu_disk.c: 642:istgt_lu_disk_init: ***ERROR*** LU5: LUN0: open error(errno=17) > istgt_lu.c:2091:istgt_lu_init_unit: ***ERROR*** LU5: lu_disk_init() failed > istgt_lu.c:2166:istgt_lu_init: ***ERROR*** LU5: lu_init_unit() failed > istgt.c:2799:main: ***ERROR*** istgt_lu_init() failed > /usr/local/etc/rc.d/istgt: WARNING: failed to start istgt > > > where am I wrong? > > -- > Zeus V. Panchenko jid:zeus@im.ibs.dn.ua > IT Dpt., I.B.S. LLC GMT+2 (EET) > _______________________________________________ > 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 should clone the snapshot first: zfs clone dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11 dev/zvol/storage/win/zvol-totest-clone then on istgt.conf > [LogicalUnit5] > Comment "snapshot of ZVOL 500Gb totest" > TargetName zvol-totest-snapshot > Mapping PortalGroup1 InitiatorGroup1 > AuthMethod Auto > AuthGroup AuthGroup1 > UseDigest Auto > UnitType Disk > QueueDepth 64 LUN0 Storage dev/zvol/storage/win/zvol-totest-clone Auto From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 23:55:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5BA31065670 for ; Wed, 26 Sep 2012 23:55:23 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7CA8FC14 for ; Wed, 26 Sep 2012 23:55:22 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id q8QNtJQN063372; Thu, 27 Sep 2012 02:55:20 +0300 (EEST) Message-ID: <20120927025519.63369@relay.ibs.dn.ua> Date: Thu, 27 Sep 2012 02:55:19 +0300 From: Zeus Panchenko To: "=?us-ascii?Q?=3D=3FISO-8859-1=3FQ=3FGezeala=5FM=3D2E=5FBacu=3DF1o=5FII?= =?us-ascii?Q?=3F=3D?=" In-reply-to: Your message of Wed, 26 Sep 2012 15:50:37 -0700 References: <20120926173700.29600@relay.ibs.dn.ua> Organization: I.B.S. LLC X-Mailer: MH-E 8.2; GNU Mailutils 2.99.97; GNU Emacs 23.4.1 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 23:55:23 -0000 Gezeala M. Bacu=C3=B1o II wrote: >=20 > you should clone the snapshot first: > zfs clone dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11 > dev/zvol/storage/win/zvol-totest-clone >=20 does it mean, I have no way to give access to the very snapshot, as if I manipulate the snapshot locally by cp/mv/cmp e.t.c. commands? may I do that with zfs rather than with zvol? --=20 Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Thu Sep 27 03:22:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24BAA106566B for ; Thu, 27 Sep 2012 03:22:24 +0000 (UTC) (envelope-from gezeala@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id EBB818FC08 for ; Thu, 27 Sep 2012 03:22:23 +0000 (UTC) Received: by padbi1 with SMTP id bi1so1060090pad.13 for ; Wed, 26 Sep 2012 20:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=HqH1/1a4GkIhEaPxYzUgms1Ggxn+A4IJJtXB+Dq6YFM=; b=d2ZIunOaW9QUhH2brRbkTazlZivw47OICS+VWkwLST15lumQL2Jb7N3FJ8uO1MU7J7 +F4BcM2skmN5KBdunABhIaiUVZ1jfQNilRDGfQWQmGyyo+7Cv4dmosQMG4s5UB0Rvmpz vwBYRT1AN4VQmjJvWLqbAAWFGPiPthPxdfj+yuQQ2vePDwBFogEK6uGLqD1ff2uyU2MD kmk4MxmQR4TlCojkE+BQ6kIgHR7gRopjHL3HcKCnXdIGEatugNV0OgOE1TB/IQNowo5h LJEU7I2Fg8bWBuwYTutdn6RXQMEoKxSi9yCZuzFvzwE0CE/7/LXIJLoud4F89RrFt7Pl HITg== Received: by 10.68.232.163 with SMTP id tp3mr7861495pbc.44.1348716143125; Wed, 26 Sep 2012 20:22:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.69 with HTTP; Wed, 26 Sep 2012 20:21:42 -0700 (PDT) In-Reply-To: <20120927025519.63369@relay.ibs.dn.ua> References: <20120926173700.29600@relay.ibs.dn.ua> <20120927025519.63369@relay.ibs.dn.ua> From: =?ISO-8859-1?Q?Gezeala_M=2E_Bacu=F1o_II?= Date: Wed, 26 Sep 2012 20:21:42 -0700 Message-ID: To: Zeus Panchenko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI 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, 27 Sep 2012 03:22:24 -0000 On Wed, Sep 26, 2012 at 4:55 PM, Zeus Panchenko wrote: > Gezeala M. Bacu=F1o II wrote: >> >> you should clone the snapshot first: >> zfs clone dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11 >> dev/zvol/storage/win/zvol-totest-clone >> > > does it mean, I have no way to give access to the very snapshot, as if I > manipulate the snapshot locally by cp/mv/cmp e.t.c. commands? > > may I do that with zfs rather than with zvol? > > -- > Zeus V. Panchenko jid:zeus@im.ibs.dn.ua > IT Dpt., I.B.S. LLC GMT+2 (EET) The recommended way of accessing snapshots is by cloning it. or cd /your-pool/your-fs-with-snapshot/.zfs/snapshot ls -ls If your filesystem or volume has snapshots you should see them. Take note that everything is read-only. From owner-freebsd-fs@FreeBSD.ORG Thu Sep 27 06:01:35 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2717E106566C for ; Thu, 27 Sep 2012 06:01:35 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD1C8FC12 for ; Thu, 27 Sep 2012 06:01:34 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id q8R61VuN084405; Thu, 27 Sep 2012 09:01:32 +0300 (EEST) Message-ID: <20120927090131.84403@relay.ibs.dn.ua> Date: Thu, 27 Sep 2012 09:01:31 +0300 From: Zeus Panchenko To: "=?us-ascii?Q?=3D=3FISO-8859-1=3FQ=3FGezeala=5FM=3D2E=5FBacu=3DF1o=5FII?= =?us-ascii?Q?=3F=3D?=" In-reply-to: Your message of Wed, 26 Sep 2012 20:21:42 -0700 References: <20120926173700.29600@relay.ibs.dn.ua> <20120927025519.63369@relay.ibs.dn.ua> Organization: I.B.S. LLC X-Mailer: MH-E 8.2; GNU Mailutils 2.99.97; GNU Emacs 23.4.1 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 06:01:35 -0000 Gezeala M. Bacu=C3=B1o II wrote: > > > > does it mean, I have no way to give access to the very snapshot, as if I > > manipulate the snapshot locally by cp/mv/cmp e.t.c. commands? > > > > may I do that with zfs rather than with zvol? >=20 > The recommended way of accessing snapshots is by cloning it. > or > cd /your-pool/your-fs-with-snapshot/.zfs/snapshot > ls -ls >=20 > If your filesystem or volume has snapshots you should see them. Take > note that everything is read-only. >=20 I do can access snapshots locally, what am I asking about is can I give access to snapshots via network? via iSCSI, NFS or SAMBA ... since attempt to share snapshot via iSCSI leads to the error messages I have posted in the first post --=20 Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Thu Sep 27 08:06:29 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB90A1065673 for ; Thu, 27 Sep 2012 08:06:29 +0000 (UTC) (envelope-from nowakpl@platinum.linux.pl) Received: from platinum.linux.pl (platinum.edu.pl [81.161.192.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBCC8FC1A for ; Thu, 27 Sep 2012 08:06:28 +0000 (UTC) Received: by platinum.linux.pl (Postfix, from userid 87) id 3F87047DCB; Thu, 27 Sep 2012 09:56:22 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on platinum.linux.pl X-Spam-Level: X-Spam-Status: No, score=-1.4 required=3.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.3.2 Received: from [172.19.191.4] (c38-073.client.duna.pl [83.151.38.73]) by platinum.linux.pl (Postfix) with ESMTPA id E11BC47DC9 for ; Thu, 27 Sep 2012 09:56:19 +0200 (CEST) Message-ID: <5064069C.8040407@platinum.linux.pl> Date: Thu, 27 Sep 2012 09:56:12 +0200 From: Adam Nowacki User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120926173700.29600@relay.ibs.dn.ua> In-Reply-To: <20120926173700.29600@relay.ibs.dn.ua> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: how to access ZFS snapshot via iSCSI 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, 27 Sep 2012 08:06:30 -0000 On 2012-09-26 16:37, Zeus Panchenko wrote: > LU5 HDD UNIT > LU5: LUN0 file=/dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11, size=536870912000 > LU5: LUN0 1048576000 blocks, 512 bytes/block > istgt_lu_disk.c: 642:istgt_lu_disk_init: ***ERROR*** LU5: LUN0: open error(errno=17) > istgt_lu.c:2091:istgt_lu_init_unit: ***ERROR*** LU5: lu_disk_init() failed > istgt_lu.c:2166:istgt_lu_init: ***ERROR*** LU5: lu_init_unit() failed > istgt.c:2799:main: ***ERROR*** istgt_lu_init() failed > /usr/local/etc/rc.d/istgt: WARNING: failed to start istgt > > > where am I wrong? > istgt likely tries to open the snapshot read-write, maybe http://mebsd.com/configure-freebsd-servers/istgt-iscsi-dvd-target-istgt-conf.html will work. From owner-freebsd-fs@FreeBSD.ORG Thu Sep 27 10:41:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 081481065670 for ; Thu, 27 Sep 2012 10:41:07 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from smtplq03.aruba.it (smtplq-out13.aruba.it [62.149.158.33]) by mx1.freebsd.org (Postfix) with SMTP id 52E778FC12 for ; Thu, 27 Sep 2012 10:41:05 +0000 (UTC) Received: (qmail 5260 invoked by uid 89); 27 Sep 2012 10:41:02 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq03.aruba.it with SMTP; 27 Sep 2012 10:41:02 -0000 Received: (qmail 24732 invoked by uid 89); 27 Sep 2012 10:41:02 -0000 Received: from unknown (HELO cloverinformatica.it) (info@cloverinformatica.it@151.55.85.148) by smtp1.ad.aruba.it with SMTP; 27 Sep 2012 10:41:02 -0000 Received: from [192.168.0.185] (ASUS-TERMINATOR [192.168.0.185]) by cloverinformatica.it (Postfix) with ESMTP id 12DA468; Thu, 27 Sep 2012 12:41:04 +0200 (CEST) Message-ID: <50642D3F.2070908@cloverinformatica.it> Date: Thu, 27 Sep 2012 12:41:03 +0200 From: Maurizio Vairani User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Zeus Panchenko References: <20120926173700.29600@relay.ibs.dn.ua> <20120927025519.63369@relay.ibs.dn.ua> <20120927090131.84403@relay.ibs.dn.ua> In-Reply-To: <20120927090131.84403@relay.ibs.dn.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI 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, 27 Sep 2012 10:41:07 -0000 On 27/09/2012 8.01, Zeus Panchenko wrote: > Gezeala M. Bacuño II wrote: >>> does it mean, I have no way to give access to the very snapshot, as if I >>> manipulate the snapshot locally by cp/mv/cmp e.t.c. commands? >>> >>> may I do that with zfs rather than with zvol? >> The recommended way of accessing snapshots is by cloning it. >> or >> cd /your-pool/your-fs-with-snapshot/.zfs/snapshot >> ls -ls >> >> If your filesystem or volume has snapshots you should see them. Take >> note that everything is read-only. >> > I do can access snapshots locally, what am I asking about is can I give > access to snapshots via network? via iSCSI, NFS or SAMBA ... > > since attempt to share snapshot via iSCSI leads to the error messages I > have posted in the first post I share my snapshots via SAMBA. In /usr/local/etc/smb.conf I have: [Maurizio] path = /pool500gb/shared/maurizio comment = Drive per Maurizio browseable = yes writeable = yes public = yes [Maurizio-Snapshot] path = /pool500gb/shared/maurizio/.zfs/snapshot comment = Snapshot del drive per Maurizio browseable = yes writeable = no public = yes where Maurizio is my work drive and Maurizio-Snapshot is the zfs snaphot Regards Maurizio From owner-freebsd-fs@FreeBSD.ORG Thu Sep 27 12:53:06 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41B3A1065686 for ; Thu, 27 Sep 2012 12:53:06 +0000 (UTC) (envelope-from gezeala@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1242B8FC1C for ; Thu, 27 Sep 2012 12:53:06 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so4103983pbb.13 for ; Thu, 27 Sep 2012 05:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=t4hpVFFerZlrWbBgjN1gq1ndQ2kbuOqXqIsai7DYQD4=; b=yyTYBbzAlpRJfuMSs1uYMYoY4zXt7cm0gJRevNelbojZ9WUGP3XxMh+KrZ7Q8OlalE NlS/eyPCUn9/Xct+FZphPscthbypP+WY4JTdga6tZJNTv+wFGi1xqFyQ2Fy6FVEihYOb pLrPYVzs3iJvGwzVc6tEx/Df1NSLQzLU2lA5mbC/g8F1EH3npHEAxkvRKjOK3sdoR9YT V/sADK976iWAW5Rgjejr2XAu2fi5kbitg+9n/hBS50V4FOzk0lOndXgn7oHOa36wJXZ2 s1G5JuR07cGz/sWshmORSeCmAMs57VmdSCyqSnUoHknsyvVtOxJGXVOij3XVFJ4de+of 2jJA== Received: by 10.68.235.68 with SMTP id uk4mr11294629pbc.52.1348750385883; Thu, 27 Sep 2012 05:53:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.69 with HTTP; Thu, 27 Sep 2012 05:52:25 -0700 (PDT) In-Reply-To: <20120927090131.84403@relay.ibs.dn.ua> References: <20120926173700.29600@relay.ibs.dn.ua> <20120927025519.63369@relay.ibs.dn.ua> <20120927090131.84403@relay.ibs.dn.ua> From: =?ISO-8859-1?Q?Gezeala_M=2E_Bacu=F1o_II?= Date: Thu, 27 Sep 2012 05:52:25 -0700 Message-ID: To: Zeus Panchenko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI 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, 27 Sep 2012 12:53:06 -0000 On Wed, Sep 26, 2012 at 11:01 PM, Zeus Panchenko wrote: > Gezeala M. Bacu=F1o II wrote: >> > >> > does it mean, I have no way to give access to the very snapshot, as if= I >> > manipulate the snapshot locally by cp/mv/cmp e.t.c. commands? >> > >> > may I do that with zfs rather than with zvol? >> >> The recommended way of accessing snapshots is by cloning it. >> or >> cd /your-pool/your-fs-with-snapshot/.zfs/snapshot >> ls -ls >> >> If your filesystem or volume has snapshots you should see them. Take >> note that everything is read-only. >> > > I do can access snapshots locally, what am I asking about is can I give > access to snapshots via network? via iSCSI, NFS or SAMBA ... > > since attempt to share snapshot via iSCSI leads to the error messages I > have posted in the first post > Did you clone your snapshot like what I've suggested in my first post? From owner-freebsd-fs@FreeBSD.ORG Thu Sep 27 13:57:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1F54106564A for ; Thu, 27 Sep 2012 13:57:24 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF8E8FC0A for ; Thu, 27 Sep 2012 13:57:24 +0000 (UTC) Received: by bkcjf20 with SMTP id jf20so805471bkc.13 for ; Thu, 27 Sep 2012 06:57:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PsDukY8U2B0UAXl7Peq+FHVfY7vVjJGBT2RVKDgqmas=; b=gUmQjQQtBUkYJgUBMD747Z9lTU4bqdS+YOu7Tj0hmOlvWYIU2wuRlxhujQlPtXiWT0 PI1/UdCMjgT4hE0SE3qq/CpFsqkbnQi5nX+/Ifj3SLtJwP2tTYgkyQbE5J3Cg2AA2oEY l5ntCkiZVeyNccOnSvnPnEo3H/dIVLYuzT4dGJZqZQvcu4oz1Ee1Nvse5AODvJE++LKz VoCoQGUjBo0TziQi+QcWIJLlW8ra1+FTYe9LUr2QJQcFrfJ8D6/B0pCCNrcfe+rdN+Xi XIRva9eHp5Xyb8QrInmpvNVRCo97yt+fJbUYv09tPHs1wtdtlPTGX0JOSd7KQA7++a7O Zy+g== MIME-Version: 1.0 Received: by 10.152.110.74 with SMTP id hy10mr3362792lab.54.1348754243050; Thu, 27 Sep 2012 06:57:23 -0700 (PDT) Received: by 10.112.2.36 with HTTP; Thu, 27 Sep 2012 06:57:22 -0700 (PDT) In-Reply-To: <20120926173700.29600@relay.ibs.dn.ua> References: <20120926173700.29600@relay.ibs.dn.ua> Date: Thu, 27 Sep 2012 15:57:22 +0200 Message-ID: From: Olivier Smedts To: Zeus Panchenko Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnM8GwJrM0I9Z50NesgzNVwjSflSaW9m9WoTPMwiKcmQ9neICFDMQAeb+cQCqHrrr7F4IuW Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI 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, 27 Sep 2012 13:57:25 -0000 2012/9/26 Zeus Panchenko : > hi all, > > please, may somebody advice, can I access ZFS snapshot via iSCSI? > > I do can get access to ZFS filesystem and zvol, but how to access ZFS snapshot? > > I am trying that via istgt, in istgt.conf I put: > > [LogicalUnit4] > Comment "ZVOL 500Gb to test" > TargetName zvol-totest > Mapping PortalGroup1 InitiatorGroup1 > AuthMethod Auto > AuthGroup AuthGroup1 > UseDigest Auto > UnitType Disk > QueueDepth 64 > LUN0 Storage /dev/zvol/storage/win/zvol-totest Auto > > and I can mount it and use > > when I put > > [LogicalUnit5] > Comment "snapshot of ZVOL 500Gb totest" > TargetName zvol-totest-snapshot > Mapping PortalGroup1 InitiatorGroup1 > AuthMethod Auto > AuthGroup AuthGroup1 > UseDigest Auto > UnitType Disk > QueueDepth 64 > LUN0 Storage /dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11 Auto Can you set a read-only access in this config file ? Maybe istgt tries to open the volume read-write but it can't because it's a snapshot. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-fs@FreeBSD.ORG Thu Sep 27 19:27:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 438BB106564A for ; Thu, 27 Sep 2012 19:27:31 +0000 (UTC) (envelope-from gezeala@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 15CA18FC0A for ; Thu, 27 Sep 2012 19:27:30 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so4735275pbb.13 for ; Thu, 27 Sep 2012 12:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tw4sNn3psaffCmFZwvR0QZUGMzhHKfQNkbqp0KQD1E4=; b=eewan4eui6kKSZhaOSExGbiSmCGtVoHneNVowhbMU85ZZUM+ud3tw+lxUkWFiQZ4cl WEjjx/Imrfl+0tQscqIKXeyYaXvPkq/3nnDUQbVxES3cayebMeyBuX0lFgfAKXEtTDwt yBkmPqvWeD/mAJf0T+Eay041IJHaCfwDA+HLLtU4UlRH3Sv7R73Xrwup4P9eMtUb7nVw n8MhnDMn+Yf61isQwT98LgJvyxawoZZKWabu5zmVGwa3yjQmzoG7OudDC2L82/MY5H8h YCoz0oPBY8qTy6PmuTExhXF7Lslzd9QOr/NDddJtJOmAZTQiOn/xdP2ln8UCVCoopeDw j7vQ== Received: by 10.68.194.165 with SMTP id hx5mr14595291pbc.40.1348774050590; Thu, 27 Sep 2012 12:27:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.69 with HTTP; Thu, 27 Sep 2012 12:26:50 -0700 (PDT) In-Reply-To: References: <20120926173700.29600@relay.ibs.dn.ua> From: =?ISO-8859-1?Q?Gezeala_M=2E_Bacu=F1o_II?= Date: Thu, 27 Sep 2012 12:26:50 -0700 Message-ID: To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: how to access ZFS snapshot via iSCSI 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, 27 Sep 2012 19:27:31 -0000 On Thu, Sep 27, 2012 at 6:57 AM, Olivier Smedts wrote: > 2012/9/26 Zeus Panchenko : >> hi all, >> >> please, may somebody advice, can I access ZFS snapshot via iSCSI? >> >> I do can get access to ZFS filesystem and zvol, but how to access ZFS snapshot? >> >> I am trying that via istgt, in istgt.conf I put: >> >> [LogicalUnit4] >> Comment "ZVOL 500Gb to test" >> TargetName zvol-totest >> Mapping PortalGroup1 InitiatorGroup1 >> AuthMethod Auto >> AuthGroup AuthGroup1 >> UseDigest Auto >> UnitType Disk >> QueueDepth 64 >> LUN0 Storage /dev/zvol/storage/win/zvol-totest Auto >> >> and I can mount it and use >> >> when I put >> >> [LogicalUnit5] >> Comment "snapshot of ZVOL 500Gb totest" >> TargetName zvol-totest-snapshot >> Mapping PortalGroup1 InitiatorGroup1 >> AuthMethod Auto >> AuthGroup AuthGroup1 >> UseDigest Auto >> UnitType Disk >> QueueDepth 64 >> LUN0 Storage /dev/zvol/storage/win/zvol-totest@hourly-2012-09-26-11 Auto > > Can you set a read-only access in this config file ? Maybe istgt tries > to open the volume read-write but it can't because it's a snapshot. > > -- > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org - against HTML email & vCards X > www: http://www.gid0.org - against proprietary attachments / \ > > "Il y a seulement 10 sortes de gens dans le monde : > ceux qui comprennent le binaire, > et ceux qui ne le comprennent pas." > _______________________________________________ > 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" Try adding "ReadOnly Yes" option on LogicalUnit. [LogicalUnit5] ... ReadOnly Yes ... From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 05:42:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08C051065670 for ; Fri, 28 Sep 2012 05:42:44 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5C83F8FC08 for ; Fri, 28 Sep 2012 05:42:42 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id q8S5gXM0087738; Fri, 28 Sep 2012 08:42:34 +0300 (EEST) Message-ID: <20120928084233.87736@relay.ibs.dn.ua> Date: Fri, 28 Sep 2012 08:42:33 +0300 From: Zeus Panchenko To: References: <20120926173700.29600@relay.ibs.dn.ua> Organization: I.B.S. LLC X-Mailer: MH-E 8.2; GNU Mailutils 2.99.97; GNU Emacs 23.4.1 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ Cc: =?ISO-8859-1?Q?Gezeala_M=2E_Bacu=F1o_II?= Subject: Re: how to access ZFS snapshot via iSCSI X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 05:42:44 -0000 hi all, thanks everybody for the help! the cause was just in ReadOnly option absence of LogicalUnit section in istgt.conf it have to be set -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 14:18:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C0E106566B; Fri, 28 Sep 2012 14:18:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4688FC08; Fri, 28 Sep 2012 14:18:05 +0000 (UTC) Received: by bkcjf20 with SMTP id jf20so2641218bkc.13 for ; Fri, 28 Sep 2012 07:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mvnR7vbW9GBmk2WeR/qA5omNqAxLn0HAt8sPIeVjwo8=; b=RR5t2XQ5cjBn4d2e7qYZCYQ3Lk7+LsQq97s2z7W4UyAR0Np7B2PXWlQMOhwci4n71g ywc7+lOb9poiPg49meDHQAu1SChebGoqF6opCRNSDT+trFMtYzOhkXtMVWb6TJlt5Cu7 lkKT32VWfcDg2CK5DZe1ioEMJWeMj4AY+uA2imxz622+rLv9UdWKFqnI6JAkB7AznqPw +NsiJNYckHllGrVsfrsndPpwPogvDBdoNZadjANlkiQI7Yk1tqE/+vJiFm0wfKE0Et7B FW7VF+4xJm+4f49UDhr9RuIRQY+2/bb7pIGH5NBaufp8V2P2x8O/O+Gwon86RNARU208 O//Q== MIME-Version: 1.0 Received: by 10.112.86.41 with SMTP id m9mr2789062lbz.108.1348841884682; Fri, 28 Sep 2012 07:18:04 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.102.39 with HTTP; Fri, 28 Sep 2012 07:18:04 -0700 (PDT) In-Reply-To: <5062E0DE.70805@omnilan.de> References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> <5061F6E9.6030104@omnilan.de> <5062E0DE.70805@omnilan.de> Date: Fri, 28 Sep 2012 15:18:04 +0100 X-Google-Sender-Auth: ZIQAKTF4zBB_vg4H9QDvpKUJy5s Message-ID: From: Attilio Rao To: Harald Schmalzbauer Content-Type: text/plain; charset=UTF-8 Cc: Peter Holm , bdrewery@freebsd.org, FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 14:18:07 -0000 On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer wrote: > schrieb Harald Schmalzbauer am 25.09.2012 20:24 (localtime): >> schrieb Attilio Rao am 21.09.2012 02:22 (localtime): >>> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao wrote: >>>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao wrote: >>>>> 2012/7/4 Attilio Rao : >>>>>> 2012/6/29 Attilio Rao : >>>>>>> As already published several times, according to the following plan: >>>>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >>>>>>> >>>>>> I still haven't heard from Vivien or Edward, anyway as NTFS is >>>>>> basically only used RO these days (also the mount_ntfs code just >>>>>> permits RO mounting) I stripped all the uncomplete/bogus write support >>>>>> with the following patch: >>>>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch >>>>>> >>>>>> This is an attempt to make the code smaller and possibly just focus on >>>>>> the locking that really matter (as read-only filesystem). >>>>>> On some points of the patch I'm a bit less sure as we could easily >>>>>> take into account also write for things like vaccess() arguments, and >>>>>> make easier to re-add correct write support at some point in the >>>>>> future, but still force RO, even if the approach used in the patch is >>>>>> more correct IMHO. >>>>>> As an added bonus this patch cleans some dirty code in the mount >>>>>> operation and fixes a bug as vfs_mountedfrom() is called before real >>>>>> mounting is completed and can still fail. >>>>> A quick update on this. >>>>> It looks like NTFS won't be completed for this GSoC thus I seriously >>>>> need to find an alternative to not loose the NTFS support entirely. >>>>> >>>>> I tried to look into the NTFS implementation right now and it is >>>>> really a poor support. As Peter has also verified, it can deadlock in >>>>> no-time, it compeltely violates VFS rules, etc. IMHO it deserves a >>>>> complete rewrite if we would still support in-kernel NTFS. I also >>>>> tried to look at the NetBSD implementation. Their code is someway >>>>> similar to our, but they used very complicated (and very dirty) code >>>>> to do the locking. Even if I don't know well enough NetBSD VFS, I have >>>>> the impression not all the races are correctly handled. Definitively, >>>>> not something I would like to port. >>>>> >>>>> Considering all that the only viable option would be meaning an >>>>> userland filesystem implementation. My preferred choice would be to >>>>> import PUFFS and librefuse on top of it but honestly it requires a lot >>>>> of time to be completed, time which I don't currently have as in 2 >>>>> months Giant must be gone by the VFS. >>>>> >>>>> I then decided to switch to gnn's rewamp of FUSE patches. You can find >>>>> his initial e-mail here: >>>>> http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html >>>>> >>>>> I've precisely got the second version of George's patch and created >>>>> this dolphin branch: >>>>> svn://svn.freebsd.org/base/projects/fuse >>>>> >>>>> I'm fixing low hanging fruit for the moment (see r238411 for example) >>>>> and I still have to make a throughful review. >>>>> However my idea is to commit the support once: >>>>> - ntfs-3g is well stress-tested and proves to be bug-free >>>>> - there is no major/big technical issue pending after the reviews >>>> In the last weeks Peter, Florian, Gustau and I have been working in >>>> stabilizing fuse support. In the specific, Peter has worked hard on >>>> producing several utilities to nit stress-test fuse and in particular >>>> ntfs, Florian has improved fuse related ports (as explained later) and >>>> Gustau has done sparse testing. I feel moderately satisfied by the >>>> level of stability of fuse now to propose to wider usage, in >>>> particular given the huge amount of complaints I'm hearing around >>>> about occasional fuse users. >>>> >>>> The final target of the project is to completely import into base the >>>> content of fusefs-kmod starting from earlier posted patches by George. >>>> So far, we took care only of importing in the fuse branch the kernel >>>> part, so that fusefs-kmod userland part is still needed to be >>>> installed from ports, but I was studying the mount_fusefs licensing >>>> before to process with the import for the userland bits of it. >>>> >>>> The fixing has been happening here: >>>> svn://svn.freebsd.org/base/projects/fuse/ >>>> >>>> which is essentially an HEAD branch + fuse kernel components. In order >>>> to get fuse, please compile a kernel from this branch with FUSE option >>>> or simply build and load fuse module. >>>> Alternatively, a kernel patch that should work with HEAD@240684 is here: >>>> http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch >>>> >>>> I guess the patch can easilly apply to all FreeBSD branches, really, >>>> but it is not tested to anything else different then -CURRENT. >>>> >>>> As said you still need currently to build fusefs-kmod port. However >>>> you need these further patches, to be put in the fusefs-kmod/files/ >>>> directory:: >>>> http://www.freebsd.org/~attilio/fuse_import/patch-Makefile >>>> http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_fusefs2.c >>>> >>>> They both disable the old kernel building/linking and import new >>>> functionality to let the new kernel support work well in presence of >>>> many consumers. >>>> >>>> In addition to fusefs-kmod, Bryan and Florian have also updated >>>> fusefs-lib and fusefs-ntfs ports. For instance, please refer to this >>>> e-mail: >>>> http://lists.freebsd.org/pipermail/freebsd-ports/2012-August/077950.html >>>> >>>> Even if this work is someway independent by the fusefs-kmod import, I >>>> warmly suggest to all of you to use their patches (and this what we >>>> have been testing so far too. >>> So, after Bryan and Florian ports update, I've also committed userland >>> part of fusefs-kmod and now the project branch fully mirrors >>> functionality of fusefs-kmod. The code in projects/fuse, infact, will >>> also install mount_fusefs as part of the fuse support. >>> >>> You can use the branch directly or this patch against -CURRENT at 240752: >>> http://www.freebsd.org/~attilio/fuse_import/fuse_240752.patch >> Hello, >> >> first, many thanks for your effort bringing fusefs support into base >> with decent stability!!! >> I tried to compile RELENG_9_1 with your patch, but failed figuring out >> why compiling world stops with this error: >> >> src/sbin/mount_fusefs/mount_fusefs.c:319: error: void value not ignored >> as it ought to be >> *** [mount_fusefs.o] Error code 1 > > Reason is sbin/mount/getmntopts.c, where checkpath() is void, which > changed to int in r230226 8 monthas ago in head. After many people willing to test fuse on STABLE_9, I made this patch that at least compiles there: http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch Of course, I didn't have a chance to test it because I'm also out for vacation right now but please do and report. Thanks, Attilio > > Log: > Change checkpath() to not exit on error. This is a prerequisite for > fixing the mount(8) "failok" option. > > Some questions: Is this planned to be mfc'd and if so, how can one know? In which sense "how can one know?". We usually specify MFC timeouts in the commit message (not sure if this answers your concerns). > And another svn-dummie question: How can I get the committ as a diff? cvsweb provided an esay click if I remember correctly. Once you have the commit as, say, rXXYYZZ just do: svn diff -x -p svn://svn.freebsd.org/base/head/@(XXYYZZ-1) svn://svn.freebsd.org/base/head/@XXYYZZ Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 14:47:23 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0307106564A; Fri, 28 Sep 2012 14:47:23 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 41A6A8FC16; Fri, 28 Sep 2012 14:47:22 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q8SEmEu4085201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2012 16:48:14 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5065B873.4070509@omnilan.de> Date: Fri, 28 Sep 2012 16:47:15 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: attilio@FreeBSD.org References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> <5061F6E9.6030104@omnilan.de> <5062E0DE.70805@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2BAFBC6867A2078B93B5900C" Cc: FreeBSD FS , freebsd-current@FreeBSD.org Subject: Re: MPSAFE VFS -- List of upcoming actions 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, 28 Sep 2012 14:47:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2BAFBC6867A2078B93B5900C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Attilio Rao am 28.09.2012 16:18 (localtime): > On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer > wrote: >> ... > After many people willing to test fuse on STABLE_9, I made this patch > that at least compiles there: > http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch Thanks a lot! In the meantime I made the original patch compiling. I simply looked at the changes which were made around july in the fuse project to follow changes in head (checkpath(), vrecycle() and vtruncbuf()) and "reverted" them. Since I have no idea about the code I modified, I'm happy that you did a more qualified patch set :-) > Of course, I didn't have a chance to test it because I'm also out for > vacation right now but please do and report. Happy holiday!!! If you're by chance arround the Oktoberfest, drop me a note, I'll pay you a Ma=C3=9F (or any other drink if you don't like =E2=80=9EWiesnbier=E2=80=9C) :-) >> ... >> Some questions: Is this planned to be mfc'd and if so, how can one kno= w? > In which sense "how can one know?". We usually specify MFC timeouts in > the commit message (not sure if this answers your concerns). Yep, that's what I wanted to know. So if there's no MFC timeout in the log, it's not intended to be MFCd ever I guess. Thanks a lot! World/Kernel compiled fine in the meantime, I'll do some sshfs tests. -Harry --------------enig2BAFBC6867A2078B93B5900C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlBluHMACgkQLDqVQ9VXb8iKIQCfVCNSd+P7BFeGDOyJBb0t1xEd MNsAn1CNFJdYdJEdGQlOadWmXdNFF1Y5 =SVeh -----END PGP SIGNATURE----- --------------enig2BAFBC6867A2078B93B5900C-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 15:43:06 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7551C1065675 for ; Fri, 28 Sep 2012 15:43:06 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EFF008FC16 for ; Fri, 28 Sep 2012 15:43:05 +0000 (UTC) Received: by bkcjf20 with SMTP id jf20so2793421bkc.13 for ; Fri, 28 Sep 2012 08:43:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=OWn1kwtxyhTf9DK5CcmhV9tXKXPloz9UswuG8w4tAPc=; b=da+Rx4/4pRHbkCpzzDbjwU/3H/0wqo5D5OJr0PTH4XhZ4GIZ4pPviEamSFWPOtuNAe r788S2Jmc1DBEOC/FCr7YCN8NkyW8Wbc0mHJ7rRk/pcWoudhcfh3dSEDwfJ5jaZk+nF3 7i0xEf31YmZSqlT0fzZJIKFIBFVr/0jAF3szr2MBgB0kDkqPBW4Gf08FpU24iitEihrU eBRSy0/Wqc4nMWut/QEKdo3DWKHfNG5gY/5785kxouyeaXLVqA1SIsygRJeBulwADkss fZBPIdy7fqNhSdTufS6y3cRr5+cdkQQQ2PFRm6jc+hF1zcYG2aVSHZnt2aQsnCqCR+5r T3NA== MIME-Version: 1.0 Received: by 10.112.100.8 with SMTP id eu8mr2916413lbb.12.1348846984791; Fri, 28 Sep 2012 08:43:04 -0700 (PDT) Received: by 10.112.2.36 with HTTP; Fri, 28 Sep 2012 08:43:04 -0700 (PDT) Date: Fri, 28 Sep 2012 17:43:04 +0200 Message-ID: From: Olivier Smedts To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQldsYVxMkQCcW0IDDeqUzoR0TVanGGtj1LXyHg8/YxxlQZzAbRqpREqb7Rly2xu2tQXYeWO Subject: Can't remove zil / separate log device from root pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 15:43:06 -0000 Hello, Some time ago I added a separate log device to my root pool (with the "bootfs" unset hack) but now I can't remove it from my pool : # uname -a FreeBSD zozo.afpicl.lan 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r241027: Fri Sep 28 14:43:13 CEST 2012 root@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 root@zozo:/root# zpool status pool: tank state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: resilvered 7,27M in 0h0m with 0 errors on Mon Sep 17 12:43:16 2012 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 logs gpt/zil ONLINE 0 0 0 errors: No known data errors root@zozo:/root# time zpool remove tank gpt/zil && echo "ok !" 0.000u 0.008s 0:02.61 0.0% 0+0k 0+1io 0pf+0w ok ! root@zozo:/root# zpool status pool: tank state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: resilvered 7,27M in 0h0m with 0 errors on Mon Sep 17 12:43:16 2012 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 logs gpt/zil ONLINE 0 0 0 errors: No known data errors I tried unsetting bootfs before removing the log device. Not better. I tried importing my pool with a 9.1-RC1 liveCD, removing the log device. The same thing happens. I tried by physically detaching the log device from my computer. The system can't mount root. With the 9.1-RC1 liveCD, I can import the pool with "-m" but then I still can't remove the log device from the pool. Any idea on what I could do ? Thanks -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 15:53:48 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2924B1065673 for ; Fri, 28 Sep 2012 15:53:48 +0000 (UTC) (envelope-from ulysse31@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id E0E608FC08 for ; Fri, 28 Sep 2012 15:53:47 +0000 (UTC) Received: by oagn9 with SMTP id n9so2214683oag.13 for ; Fri, 28 Sep 2012 08:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=emc/ok2b8s4o1oztOObOkpyy6uX2mm74NpAX5/fgUD4=; b=eyJIfZvDHEXfCiFjjAyiq2oDe3warDZjRgxCgIksalzrdcaSAt0l9wXpEkgrTFozil wAynrh32uuByg4IMb9gU+l7Xpc2AZv3KlhlaxKABPEUj8lkR7ZiiK3NVDHKeXUMyHYpv DkCjS0gPUfJIVDOZxwAHjetFpYaLkwKOF3S+bH7YBTgBU0yjobO9FUwlWhrOwQ1vus1x iXN/FChkC/xrJX6wBfMSiwuNN5mu1MxahURW5vqOI92eFOyS1YF1C8vN+duZWjEsmFJw G/9GaXyaoRfpvNCWyh1GrUJWTCPdo6qRdXrUjX0lI4bPJlca4NF9d/xaruAaP6EpgRJ0 pCQg== MIME-Version: 1.0 Received: by 10.182.157.45 with SMTP id wj13mr6211960obb.58.1348847627118; Fri, 28 Sep 2012 08:53:47 -0700 (PDT) Received: by 10.182.80.200 with HTTP; Fri, 28 Sep 2012 08:53:46 -0700 (PDT) Date: Fri, 28 Sep 2012 17:53:46 +0200 Message-ID: From: Ulysse 31 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: nfsv4 kerberized and gssname=root and allgsname 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, 28 Sep 2012 15:53:48 -0000 Hi all, I am actually working on a freebsd 9 backup server. this server would backup the production server via kerberized nfs4 (since the old backup server, a linux one, was doing so). we used on the old backup server a root/ kerberos identity, which allows the backup server to access all the data. I have followed the documentation found at : http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup done : - added to kernel : options KGSSAPI device crypto - added to rc.conf : nfs_client_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" devfs_enable="YES" gssd_enable="YES" - have done sysctl vfs.rpcsec.keytab_enctype=1 and added it to /etc/sysctl.conf We used MIT kerberos implementation, since it is the one used on all our servers (mostly linux), and we have created and /etc/krb5.keytab containing the following keys : host/ nfs/ root/ and, of course, i have used the available patch at : http://people.freebsd.org/~rmacklem/rpcsec_gss-9.patch When i try to mount with the (B) method (the one of the google wiki), it works as expected, i mean, with a correct user credential, i can access to the user data. But, when i try to access via the (C) method (the one that i need in order to do a full backup of the production storage server) i get a systematic kernel panic when launch the mount command. The mount command looks to something like : mount -t nfs -o nfsv4,sec=krb5i,gssname=root,allgssname : I have activated the kernel debugging stuff to get some infos, here is the message : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x368 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80866ab7 stack pointer = 0x28:0xffffff804aa39ce0 frame pointer = 0x28:0xffffff804aa39d30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 701 (mount_nfs) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff808ae486 at kdb_backtrace+0x66 #1 0xffffffff8087885e at panic+0x1ce #2 0xffffffff80b82380 at trap_fatal+0x290 #3 0xffffffff80b826b8 at trap_pfault+0x1e8 #4 0xffffffff80b82cbe at trap+0x3be #5 0xffffffff80b6c57f at calltrap+0x8 #6 0xffffffff80a78eda at rpc_gss_init+0x72a #7 0xffffffff80a79cd6 at rpc_gss_refresh_auth+0x46 #8 0xffffffff807a5a53 at newnfs_request+0x163 #9 0xffffffff807bf0f7 at nfsrpc_getattrnovp+0xd7 #10 0xffffffff807d9b29 at mountnfs+0x4e9 #11 0xffffffff807db60a at nfs_mount+0x13ba #12 0xffffffff809068fb at vfs_donmount+0x100b #13 0xffffffff80907086 at sys_nmount+0x66 #14 0xffffffff80b81c60 at amd64_syscall+0x540 #15 0xffffffff80b6c867 at Xfast_syscall+0xf7 Uptime: 2m31s Dumping 97 out of 1002 MB:..17%..33%..50%..66%..83%..99% ------------------------------------------------------------------------ Does anyone as experience something similar ? is their a way to correct that ? Thanks for the help. -- Ulysse31 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 16:08:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05225106566B; Fri, 28 Sep 2012 16:08:43 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AA1108FC12; Fri, 28 Sep 2012 16:08:42 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so2765140obb.13 for ; Fri, 28 Sep 2012 09:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=B+qVQLYvnNdArzQYk/1guIrLFPRCcymDjMjogKIzEZw=; b=w7X85qwog5rwA7zAd6AdUSL543E2XQ4axIQdqysvS2q+EfRUGBq1+8Fqh8KK86/VNn UzPIEnFcpMc9ntiVN2Emv6bkgRCrvpRz07s/vwU9lK3WAi/793W9hcLVchS8ItYxt3CZ EekLL4983nAuoUX3f5EdAMaUz6eCVPlxV2vCXH2+nSlNA+oexKRHEUtO8HFmlcYQ6mDL q8q78DVRwpmEgxRprpPaW1X+FrUo00jZmykr6LkFGh1wyhcRArimxCvcA0BeKi9q2lcA B1pI/scaipjZDx2HzIE1i6QK4UivqSh36GjPEUNF1iLwvHwgVbFdxZtcfbWHbDX9AIht lQrA== MIME-Version: 1.0 Received: by 10.60.171.69 with SMTP id as5mr6269387oec.100.1348848522117; Fri, 28 Sep 2012 09:08:42 -0700 (PDT) Received: by 10.182.98.4 with HTTP; Fri, 28 Sep 2012 09:08:41 -0700 (PDT) Date: Fri, 28 Sep 2012 18:08:41 +0200 Message-ID: From: Sami Halabi To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ZFS on HEAD 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, 28 Sep 2012 16:08:43 -0000 Hi, I tried to follow: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html to recompile the kernel with KVA_PAGES and i couldn't compile. any ideas why this? -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 16:33:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 563791065670; Fri, 28 Sep 2012 16:33:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 21FE58FC0A; Fri, 28 Sep 2012 16:33:07 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 4038F23F6D9; Fri, 28 Sep 2012 12:33:06 -0400 (EDT) Date: Fri, 28 Sep 2012 12:33:04 -0400 From: Glen Barber To: Sami Halabi Message-ID: <20120928163304.GC1287@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kVXhAStRUZ/+rrGn" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 16:33:07 -0000 --kVXhAStRUZ/+rrGn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: > I tried to follow: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs= =2Ehtml >=20 > to recompile the kernel with KVA_PAGES > and i couldn't compile. >=20 > any ideas why this? >=20 What was the error? Glen --kVXhAStRUZ/+rrGn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQZdFAAAoJEFJPDDeguUaj4qEH/1Czguey6qtzhf4wzYtJi/y9 dO0u6p5qWziuR2oMWjKRdtqVvtCnHg9XNlpluc5AzqIRz2mRU0So2167G/sWldoN iDz1vMOWSuXLUwnbW8kHP9t5PTHkmbNkLjTHBD9QgAATM6cYwSsAVDMXyQ7K9G2z rA8ef0SmDTVLWAqK5g1zLQ5q2Vr5xd9NFEo7FIEn/0R5xrBiraH6NXG6qZzaBHuQ PwLLTFM5mTv1dNYZErWarKVPrRNBMTdjZZbgo7l3QKaMjqaV3Odc3AEgi/vFjKrv vJ/WvbFoDlt30//6pw2nxbFPQSTbhohzEqAEHCuSppBNKsDf380dJSAT8TYmjdU= =4XL1 -----END PGP SIGNATURE----- --kVXhAStRUZ/+rrGn-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 19:31:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ECC8106566B; Fri, 28 Sep 2012 19:31:42 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 183E48FC0A; Fri, 28 Sep 2012 19:31:41 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so3024637obb.13 for ; Fri, 28 Sep 2012 12:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HubO8bTzcyA+x/c9jrHCs5PEFKVjxlXLRQ/kyP3O4Hg=; b=WXRFtlHVVZoxvBKzetbBPPa/9jk3keXTni8dFBDBNHo22swxtU+ImmujsSK51KQhWF M/s8b23Q3KgHYZESGJZiInM84OwMEKEfEesGpAvODNu3tRJn2zW8v+6B1IPGGpXmZL2O clP1gFP6ituo1sOYlg791etIGKKuLmBdYmdhAJWsuGvncI09vFOuzw0KflHZZD5h2Brx EMTsh3E1Qhfe0FHVq7UWqW2aACl7kLqnjSes7E283OegJ46CmeOidI9MnQVwRHtknGr6 MOKYp6Q43mlUPII6FQPGTBRhCHK/9O8bYw5KWlvKjXe2eFhdER4Q03h/WtEUo4LvJ4y4 E8/A== MIME-Version: 1.0 Received: by 10.60.3.41 with SMTP id 9mr6530102oez.113.1348860701353; Fri, 28 Sep 2012 12:31:41 -0700 (PDT) Received: by 10.182.98.4 with HTTP; Fri, 28 Sep 2012 12:31:41 -0700 (PDT) In-Reply-To: <20120928163304.GC1287@glenbarber.us> References: <20120928163304.GC1287@glenbarber.us> Date: Fri, 28 Sep 2012 21:31:41 +0200 Message-ID: From: Sami Halabi To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 19:31:42 -0000 /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES On Fri, Sep 28, 2012 at 6:33 PM, Glen Barber wrote: > On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: > > I tried to follow: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html > > > > to recompile the kernel with KVA_PAGES > > and i couldn't compile. > > > > any ideas why this? > > > > What was the error? > > Glen > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 19:36:13 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B52106564A; Fri, 28 Sep 2012 19:36:13 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id EE12B8FC0A; Fri, 28 Sep 2012 19:36:12 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 3F48D23F6D9; Fri, 28 Sep 2012 15:36:11 -0400 (EDT) Date: Fri, 28 Sep 2012 15:36:09 -0400 From: Glen Barber To: Sami Halabi Message-ID: <20120928193609.GD1287@glenbarber.us> References: <20120928163304.GC1287@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EY/WZ/HvNxOox07X" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 19:36:13 -0000 --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 28, 2012 at 09:31:41PM +0200, Sami Halabi wrote: > On Fri, Sep 28, 2012 at 6:33 PM, Glen Barber wrote: > > On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: > > > I tried to follow: > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-z= fs.html > > > > > > to recompile the kernel with KVA_PAGES > > > and i couldn't compile. > > > > > > any ideas why this? > > > > > > > What was the error? > > >=20 > /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES >=20 KVA_PAGES is not a valid option for amd64 kernel configurations. It is only needed/recommended for i386 and pc98 architectures. Glen --EY/WZ/HvNxOox07X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEbBAEBCAAGBQJQZfwpAAoJEFJPDDeguUaj5c0H+J9f1mg/ICIN+2FtRRxye21p mlYHMSoXMsxaCXRf/NMymJpsnytmoafZgR8LVIyYPQCNNpbha495ohj2kdet9JJx VgGyguzvLP4HgbqmZna6+3SvsDMwdTuAVqkVGwMMlXNTx9qGpbUsX4MzbWBUiswx 0948jXJOY/v5vgXLqYvTGEerZzMggAqHTCybTLik3Eb4jdC/sB1btGYp0J5WdP8n dMWCv0yFserODfm8E0O2mz2ITXb5BpityWkQ2cDPxy/gR3OeZ7xie2rXlnA4c+z8 EfNMFJXJ6DhG5flv4r8q+y0sIrMlkZj9RIzsnAEz5CwG9Y5meYB+MiqEUzktFw== =rEfL -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 19:37:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A86091065673; Fri, 28 Sep 2012 19:37:28 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 436DD8FC20; Fri, 28 Sep 2012 19:37:28 +0000 (UTC) Received: by oagn9 with SMTP id n9so2508806oag.13 for ; Fri, 28 Sep 2012 12:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DEG5hUyYRAgdzu19SYacS26BUB5zexrkb5xTiC6+HxI=; b=xU7hzRH7FKduMs239PNEKCMHV/mPFwb7DS1co63GIRXmUwIp1b/uTSwKKMF3a6JpwW z3ttTJ/2kPX1RUq0HqYIVq1ejExvdkfJ4XOcxW6j8Yuwy2WOea/XQWy/MnbuYZ6S6AEP /t1xc0MHYAvE62ikRjKOsCkqcTQCJ+bdDXmT7kZOThalqqpOyhYWBUuKoFT5PMuQJlLc xN5TM/wSKnkfIwl3J3Qqs3tzgGcrdHkIcMk8nxRoEylrjchgx4HWNtp6NuQt4MTKTpze HbycJAIxZFAE4ipKqXdsw1OvSiatxA+RQbji9tOD8+XiBejVH0hD+9JQdVGXwiEOZowr 0kHA== MIME-Version: 1.0 Received: by 10.60.29.229 with SMTP id n5mr4567818oeh.76.1348861047518; Fri, 28 Sep 2012 12:37:27 -0700 (PDT) Received: by 10.182.98.4 with HTTP; Fri, 28 Sep 2012 12:37:27 -0700 (PDT) In-Reply-To: <20120928193609.GD1287@glenbarber.us> References: <20120928163304.GC1287@glenbarber.us> <20120928193609.GD1287@glenbarber.us> Date: Fri, 28 Sep 2012 21:37:27 +0200 Message-ID: From: Sami Halabi To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 19:37:28 -0000 got it, I thought amd64 is i386 with 64 bit, seems i was wrong in termenlogy Thanks a lot On Fri, Sep 28, 2012 at 9:36 PM, Glen Barber wrote: > On Fri, Sep 28, 2012 at 09:31:41PM +0200, Sami Halabi wrote: > > On Fri, Sep 28, 2012 at 6:33 PM, Glen Barber wrote: > > > On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: > > > > I tried to follow: > > > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html > > > > > > > > to recompile the kernel with KVA_PAGES > > > > and i couldn't compile. > > > > > > > > any ideas why this? > > > > > > > > > > What was the error? > > > > > > > /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES > > > > KVA_PAGES is not a valid option for amd64 kernel configurations. > > It is only needed/recommended for i386 and pc98 architectures. > > Glen > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 19:43:52 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA993106566B; Fri, 28 Sep 2012 19:43:52 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8748FC0A; Fri, 28 Sep 2012 19:43:52 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id A537D37B56E; Fri, 28 Sep 2012 14:37:59 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3XT3866wCCzBpK; Fri, 28 Sep 2012 14:37:58 -0500 (CDT) Date: Fri, 28 Sep 2012 14:37:58 -0500 From: "Matthew D. Fuller" To: Sami Halabi Message-ID: <20120928193758.GC71113@over-yonder.net> References: <20120928163304.GC1287@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, Glen Barber , freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 19:43:52 -0000 On Fri, Sep 28, 2012 at 09:31:41PM +0200 I heard the voice of Sami Halabi, and lo! it spake thus: > /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES You're using amd64, not i386; you don't need to mess with KVA_PAGES. In fact, you probably don't need to tune anything on amd64, unless you've got either very little or very huge physical memory. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 19:44:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE2CD1065795; Fri, 28 Sep 2012 19:44:09 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3C48FC08; Fri, 28 Sep 2012 19:44:09 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so3038858obb.13 for ; Fri, 28 Sep 2012 12:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KIft3BX3d977ApI9VLtIzn7qnMGcSwnM3bCyUaRUjyE=; b=vSk2/RwvosubKGfKg5Vnhu3IaBctTNzpqha7Ho5M1palqRW6jMywAUZzfxcxmPtvAh oq4uEOg/OsoOoUt65oAnL52DNR3f0eX0RE3/+SOf4cuEZvDYFBvFbBU+Eb/mZpQK4ueY r4pAZy3PK8XXsXjw/fhsa8a871sLGYJQwILVELsHyV87j1lElKXlMRGFT2cpec1v+eyC DtQNflfQgQCwyuiVTQn0cRasP1S2S2hwK0F/ImHSU2FbGLydSX34xDOq6mrNdNa/x8GH KSzAlKysc1TA9/vt69r+4KGUAjC5V2OZqjDHlm3e+QOD1l9FskQ/8JlSGspivBYvesQz +rUQ== MIME-Version: 1.0 Received: by 10.60.171.69 with SMTP id as5mr6725433oec.100.1348861448933; Fri, 28 Sep 2012 12:44:08 -0700 (PDT) Received: by 10.182.98.4 with HTTP; Fri, 28 Sep 2012 12:44:08 -0700 (PDT) In-Reply-To: <20120928193758.GC71113@over-yonder.net> References: <20120928163304.GC1287@glenbarber.us> <20120928193758.GC71113@over-yonder.net> Date: Fri, 28 Sep 2012 21:44:08 +0200 Message-ID: From: Sami Halabi To: "Matthew D. Fuller" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Glen Barber , freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 19:44:10 -0000 Hi, what count for little, and what count for huge. is there any documented tunings needed for both cases? if not I'd appreciate it much if you explain the tunungs needed and what they do. Sami On Fri, Sep 28, 2012 at 9:37 PM, Matthew D. Fuller wrote: > On Fri, Sep 28, 2012 at 09:31:41PM +0200 I heard the voice of > Sami Halabi, and lo! it spake thus: > > /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES > > You're using amd64, not i386; you don't need to mess with KVA_PAGES. > > In fact, you probably don't need to tune anything on amd64, unless > you've got either very little or very huge physical memory. > > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 19:49:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9412F106566C; Fri, 28 Sep 2012 19:49:24 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 627D78FC08; Fri, 28 Sep 2012 19:49:24 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id B3F1937B54F; Fri, 28 Sep 2012 14:49:23 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3XT3PH1CXWzBpp; Fri, 28 Sep 2012 14:49:23 -0500 (CDT) Date: Fri, 28 Sep 2012 14:49:23 -0500 From: "Matthew D. Fuller" To: Sami Halabi Message-ID: <20120928194923.GD71113@over-yonder.net> References: <20120928163304.GC1287@glenbarber.us> <20120928193758.GC71113@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, Glen Barber , freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 19:49:24 -0000 On Fri, Sep 28, 2012 at 09:44:08PM +0200 I heard the voice of Sami Halabi, and lo! it spake thus: > > what count for little, and what count for huge. Off the top of my head, I'd say less than 1 gig (maybe 2) or more than 256. With very little, you may need to start looking at some of the i386 tuning to things to scale back. But anywhere in the middle the defaults should work fine (I'm sure there are gains to be had from working at tuning, but probably not huge and probably very dependent on your particular hardware and workloads). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 28 20:16:25 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45E2E106566B for ; Fri, 28 Sep 2012 20:16:25 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id F16558FC0C for ; Fri, 28 Sep 2012 20:16:24 +0000 (UTC) Received: from [209.249.190.124] (port=63938 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1THgz2-0004m4-83; Fri, 28 Sep 2012 16:16:24 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: George Neville-Neil In-Reply-To: <5056D896.8060607@icritical.com> Date: Fri, 28 Sep 2012 16:16:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49E027FB-2FA7-4839-84C8-3112A039DEE7@neville-neil.com> References: <5056D896.8060607@icritical.com> To: Matt Burke X-Mailer: Apple Mail (2.1498) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: freebsd-fs@FreeBSD.org Subject: Re: [patch] DTrace disk IO 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, 28 Sep 2012 20:16:25 -0000 On Sep 17, 2012, at 04:00 , Matt Burke wrote: > I've recently been trying to get a grip on measuring disk IO latency = (per transaction), and have found it to be rather difficult given the = asynchronous nature of the beast, and also I can't find a way of = translating the bio start of transaction timestamps to anything I can = use in DTrace when pulling them out. >=20 Interesting. Have you looked at all at the I/O module I added in HEAD? Best, George > So I knocked up this little patch against releng/9.1 to put a couple = of DTrace probes in the right places to pick up crucial data like the = now+then timestamps while they're present. >=20 > The predicate on the probe is needed to pick up the right firing - for = reasons I've not been able to fathom because gstat et al give correct = data, devstat_end_transaction is called multiple times for a given = operation - from g_disk_done(), then g_io_deliver() - without anything = useful in the bio struct (device name, number, etc). There also seem to = be a lot of firings coming from the following path which I don't = understand, again without anything useful in the bio: > kernel`devstat_end_transaction+0x13b > kernel`g_io_deliver+0x1b0 > kernel`g_io_schedule_up+0xa6 > kernel`g_up_procbody+0x5c > kernel`fork_exit+0x11f > kernel`0xffffffff80c1c3fe >=20 > Catching flushes is also proving problematic. It would seem that = devstat_end_transaction_bio() is called, but the bio and devstat structs = are virtually empty. bp->bio_dev, bp->bio_disk, ds->device_name, = ds->device_number, ds_unit_number are all null/empty, so I know that one = disk has flushed, and I know how long it took, but I can't find out = which disk it was. >=20 >=20 > Thoughts? >=20 >=20 >=20 > Index: sys/kern/subr_devstat.c > =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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/subr_devstat.c (revision 240481) > +++ sys/kern/subr_devstat.c (working copy) > @@ -29,6 +29,7 @@ > #include > __FBSDID("$FreeBSD$"); >=20 > +#include "opt_kdtrace.h" > #include > #include > #include > @@ -41,9 +42,22 @@ > #include > #include > #include > +#include >=20 > #include >=20 > +SDT_PROVIDER_DEFINE(devstat); > +SDT_PROBE_DEFINE(devstat, subr_devstat, devstat_end_transaction, = stat, stat); > +SDT_PROBE_ARGTYPE(devstat, subr_devstat, devstat_end_transaction, = stat, 0, "struct devstat *"); > +SDT_PROBE_ARGTYPE(devstat, subr_devstat, devstat_end_transaction, = stat, 1, "uint32_t"); > +SDT_PROBE_ARGTYPE(devstat, subr_devstat, devstat_end_transaction, = stat, 2, "struct bintime *"); > +SDT_PROBE_ARGTYPE(devstat, subr_devstat, devstat_end_transaction, = stat, 3, "struct bintime *"); > +SDT_PROBE_DEFINE(devstat, subr_devstat, devstat_end_transaction_bio, = stat, stat); > +SDT_PROBE_ARGTYPE(devstat, subr_devstat, devstat_end_transaction_bio, = stat, 0, "struct devstat *"); > +SDT_PROBE_ARGTYPE(devstat, subr_devstat, devstat_end_transaction_bio, = stat, 1, "struct bio *"); > + > + > + > static int devstat_num_devs; > static long devstat_generation =3D 1; > static int devstat_version =3D DEVSTAT_VERSION; > @@ -312,6 +326,8 @@ >=20 > ds->end_count++; > atomic_add_rel_int(&ds->sequence0, 1); > + > + SDT_PROBE(devstat, subr_devstat, devstat_end_transaction, stat, = ds, bytes, now, then, 0); > } >=20 > void > @@ -332,6 +348,8 @@ > else=20 > flg =3D DEVSTAT_NO_DATA; >=20 > + SDT_PROBE(devstat, subr_devstat, devstat_end_transaction_bio, = stat, ds, bp, 0, 0, 0); > + > devstat_end_transaction(ds, bp->bio_bcount - bp->bio_resid, > DEVSTAT_TAG_SIMPLE, flg, NULL, = &bp->bio_t0); > } >=20 >=20 >=20 >=20 > Sample dtrace script: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > BEGIN > { > bio_cmds[1] =3D "READ"; > bio_cmds[2] =3D "WRITE"; > bio_cmds[4] =3D "DELETE"; > bio_cmds[8] =3D "GETATTR"; > bio_cmds[16] =3D "FLUSH"; > } >=20 > devstat::devstat_end_transaction_bio: > { > self->bio =3D args[1]; > } >=20 > devstat::devstat_end_transaction: > /self->bio && args[0]->device_number/ > { > diff_frac =3D args[2]->frac - args[3]->frac; > diff_ufrac =3D (diff_frac < 0) ? (args[3]->frac - = args[2]->frac) : diff_frac; > diff =3D (1000000000*(diff_ufrac>>32))>>32; >=20 > printf("%d\t%s%d\t%s\t%d\t0.%09d\n", timestamp, > args[0]->device_name, args[0]->unit_number, > bio_cmds[self->bio->bio_cmd], > args[1], > diff > ); > } >=20 >=20 > --=20 > The information contained in this message is confidential and intended = for the addressee only. If you have received this message in error, or = there are any problems with its content, please contact the sender.=20 >=20 > iCritical is a trading name of Critical Software Ltd. Registered in = England: 04909220. > Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 = 5NH. >=20 > This message has been scanned for security threats by iCritical. = www.icritical.com >=20 > _______________________________________________ > 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 Fri Sep 28 23:23:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFD3A106566C; Fri, 28 Sep 2012 23:23:00 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 47C728FC0A; Fri, 28 Sep 2012 23:23:00 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F15FF40009; Sat, 29 Sep 2012 01:22:58 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E2CEB4000C; Sat, 29 Sep 2012 01:22:58 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 347A340009; Sat, 29 Sep 2012 01:22:57 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3XT87h5hBkz8ggx; Sat, 29 Sep 2012 01:22:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id tszyfbxBNpsY; Sat, 29 Sep 2012 01:22:54 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3XT87f4tKyz8ggv; Sat, 29 Sep 2012 01:22:54 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3XT87f3Txtz9Ctq; Sat, 29 Sep 2012 01:22:54 +0200 (CEST) Message-ID: <5066314A.4010309@daemonic.se> Date: Sat, 29 Sep 2012 01:22:50 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: "Matthew D. Fuller" References: <20120928163304.GC1287@glenbarber.us> <20120928193758.GC71113@over-yonder.net> <20120928194923.GD71113@over-yonder.net> In-Reply-To: <20120928194923.GD71113@over-yonder.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-fs@freebsd.org, Glen Barber , freebsd-current@freebsd.org Subject: Re: ZFS on HEAD 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, 28 Sep 2012 23:23:00 -0000 On 2012-09-28 21:49, Matthew D. Fuller wrote: > On Fri, Sep 28, 2012 at 09:44:08PM +0200 I heard the voice of > Sami Halabi, and lo! it spake thus: >> >> what count for little, and what count for huge. > > Off the top of my head, I'd say less than 1 gig (maybe 2) or more than > 256. With very little, you may need to start looking at some of the > i386 tuning to things to scale back. But anywhere in the middle the > defaults should work fine (I'm sure there are gains to be had from > working at tuning, but probably not huge and probably very dependent > on your particular hardware and workloads). > > Just as a measuring point, I managed to run ZFS on an moderately busy FTP server with 2GB while waiting for replacement RAM. It worked, but is perhaps not the best approach. Less than 4 or even 8GB ram is probably not recommended these days, especially since RAM is resonably cheap. Regards! -- Niclas P.S. The handbook should perhaps be slightly updated wrt ZFS, at least to clarify that tuning is only needed on i386 in the general case, and that you're usually better off running ZFS on an amd64 machine if you can choose. I'll look into it tomorrow... From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 00:40:06 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBB10106566B for ; Sat, 29 Sep 2012 00:40:06 +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 7EB2C8FC15 for ; Sat, 29 Sep 2012 00:40:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHFCZlCDaFvO/2dsb2JhbAA8CRaFdbkwgiABAQEEAQEBICsgCxsYAgINGQIpAQkmBggHBAEcBIVwgXQLpWCTCIEhiXkPBAUGhHWBEgOSOIEEgi2BFY8WgwOBPwg0 X-IronPort-AV: E=Sophos;i="4.80,505,1344225600"; d="scan'208";a="183827390" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 28 Sep 2012 20:39:58 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7D058B4038; Fri, 28 Sep 2012 20:39:58 -0400 (EDT) Date: Fri, 28 Sep 2012 20:39:58 -0400 (EDT) From: Rick Macklem To: Ulysse 31 Message-ID: <933684392.1422908.1348879198470.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@freebsd.org Subject: Re: nfsv4 kerberized and gssname=root and allgsname 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, 29 Sep 2012 00:40:06 -0000 Ulysse 31 wrote: > Hi all, > > I am actually working on a freebsd 9 backup server. > this server would backup the production server via kerberized nfs4 > (since the old backup server, a linux one, was doing so). > we used on the old backup server a root/ kerberos identity, > which allows the backup server to access all the data. > I have followed the documentation found at : > > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup > > done : > - added to kernel : > > options KGSSAPI > device crypto > > - added to rc.conf : > > nfs_client_enable="YES" > rpc_lockd_enable="YES" > rpc_statd_enable="YES" > rpcbind_enable="YES" > devfs_enable="YES" > gssd_enable="YES" > > - have done sysctl vfs.rpcsec.keytab_enctype=1 and added it to > /etc/sysctl.conf > > We used MIT kerberos implementation, since it is the one used on all > our servers (mostly linux), and we have created and /etc/krb5.keytab > containing the following keys : > host/ > nfs/ > root/ > > and, of course, i have used the available patch at : > http://people.freebsd.org/~rmacklem/rpcsec_gss-9.patch > > When i try to mount with the (B) method (the one of the google wiki), > it works as expected, i mean, with a correct user credential, i can > access to the user data. > But, when i try to access via the (C) method (the one that i need in > order to do a full backup of the production storage server) i get a > systematic kernel panic when launch the mount command. > The mount command looks to something like : mount -t nfs -o > nfsv4,sec=krb5i,gssname=root,allgssname fqdn>: > I have activated the kernel debugging stuff to get some infos, here is > the message : > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x368 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80866ab7 > stack pointer = 0x28:0xffffff804aa39ce0 > frame pointer = 0x28:0xffffff804aa39d30 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 701 (mount_nfs) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff808ae486 at kdb_backtrace+0x66 > #1 0xffffffff8087885e at panic+0x1ce > #2 0xffffffff80b82380 at trap_fatal+0x290 > #3 0xffffffff80b826b8 at trap_pfault+0x1e8 > #4 0xffffffff80b82cbe at trap+0x3be > #5 0xffffffff80b6c57f at calltrap+0x8 > #6 0xffffffff80a78eda at rpc_gss_init+0x72a > #7 0xffffffff80a79cd6 at rpc_gss_refresh_auth+0x46 > #8 0xffffffff807a5a53 at newnfs_request+0x163 > #9 0xffffffff807bf0f7 at nfsrpc_getattrnovp+0xd7 > #10 0xffffffff807d9b29 at mountnfs+0x4e9 > #11 0xffffffff807db60a at nfs_mount+0x13ba > #12 0xffffffff809068fb at vfs_donmount+0x100b > #13 0xffffffff80907086 at sys_nmount+0x66 > #14 0xffffffff80b81c60 at amd64_syscall+0x540 > #15 0xffffffff80b6c867 at Xfast_syscall+0xf7 > Uptime: 2m31s > Dumping 97 out of 1002 MB:..17%..33%..50%..66%..83%..99% > > ------------------------------------------------------------------------ > > Does anyone as experience something similar ? is their a way to > correct that ? > Thanks for the help. > Well, you're probably the first person to try doing this in years. I did have it working about 4-5years ago. Welcome to the bleeding edge;-) Could you do the following w.r.t. above kernel: # cd /boot/nkernel (or wherever the kernel lives) # nm kernel | grep rpc_gss_init - add the offset 0x72a to the address for rpc_gss_init # addr2line -e kernel.symbols 0xXXX - the hex number above (address of rpc_gss_init+0x72a) - email me what it prints out, so I know where the crash is occurring You could also run the following command on the Linux server to capture packets during the mount attempt, then email me the xxx.pcap file so I can look at it in wireshark, to see what is happening before the crash. (I'm guessing nr_auth is somehow bogus, but that's just a guess.:-) # tcpdump -s 0 -w xxx.pcap host rick > -- > Ulysse31 > _______________________________________________ > 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 Sat Sep 29 13:01:36 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF74A1065670 for ; Sat, 29 Sep 2012 13:01:35 +0000 (UTC) (envelope-from testdog@hotmail.com) Received: from snt0-omc4-s48.snt0.hotmail.com (snt0-omc4-s48.snt0.hotmail.com [65.54.51.99]) by mx1.freebsd.org (Postfix) with ESMTP id C1D708FC08 for ; Sat, 29 Sep 2012 13:01:35 +0000 (UTC) Received: from SNT002-W71 ([65.55.90.199]) by snt0-omc4-s48.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Sep 2012 06:00:29 -0700 Message-ID: X-Originating-IP: [66.196.55.100] From: Wayne Hotmail To: "freebsd-fs@freebsd.org" Date: Sat, 29 Sep 2012 13:00:29 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Sep 2012 13:00:29.0974 (UTC) FILETIME=[672E7360:01CD9E42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NFS Performance Help 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, 29 Sep 2012 13:01:36 -0000 Like others I am having issues getting any decent performance out of my NFS= clients on FreeBSD.I have tried 8.3 and 9.1 beta on stand alone servers or= as vmware clients. Used 1 Gig connections or a 10 Gig connection.Tried mou= nting using Version 3 and Version 4.I have tried the noatime=2C sync=2C and= tcp options nothing seems to help.I am connecting to a IceWeb NAS. My perf= ormance with DD is 60 meg a second at best when writing to the server. If I= load a Redhat Linux server on the same hardware using the same connection = my write performance is about 340 Meg a second.=20 It really falls apart when I run a test script where I create a 100 folders= then create a 100 files in the folders and append to these files 5 times u= sing 5 random files. I am trying to simulate a IMAP email server. If I run = the script on my local mirror drives it takes about a one minute and thirty= seconds to complete. If I run the script on the NFS mounted drives it take= s hours to complete. With my Linux install on the same hardware this NFS mo= unted script takes about 4 minutes.=20 Google is tired of me asking the same question over and over. So if anyone = would be so kind as to point out some kernel or system tweaks to get me pas= sed my NFS issues that would be greatly appreciated. Wayne = From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 14:31:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAF321065678 for ; Sat, 29 Sep 2012 14:31:55 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9738FC18 for ; Sat, 29 Sep 2012 14:31:54 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 53A25251; Sat, 29 Sep 2012 16:30:50 +0200 (CEST) Date: Sat, 29 Sep 2012 16:32:12 +0200 From: Pawel Jakub Dawidek To: Tim Gustafson Message-ID: <20120929143212.GG1402@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6AFz5yWxU/FsGPwt" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Exporting ZFS File System to Multiple Subnets 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, 29 Sep 2012 14:31:55 -0000 --6AFz5yWxU/FsGPwt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 26, 2012 at 12:50:13PM -0700, Tim Gustafson wrote: > > And it seems that ZFS somehow > > gets in the way of /etc/exports for ZFS file systems, so that if I > > turn off sharenfs ("zfs inherit sharenfs tank/export; zfs inherit > > sharenfs tank/projects") it actually blocks the export lines in > > /etc/exports from being mounted. >=20 > So, this was incorrect. Something else was going on that was > preventing the exports in /etc/exports from working; after a few > reboots, with sharenfs set to "inherited" for all file systems, we are > able to specify exports in /etc/exports again. And this is what I would recommend. sharenfs property syntax is very limited, but you can turn off that property and just use /etc/exports as for any other file system. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --6AFz5yWxU/FsGPwt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBnBmsACgkQForvXbEpPzSwEACghPjjzRHa3ojYhDUVsUzePFQF si0AoLohObgJEAVMiqJkqxb1Yp2Adrbh =d9sA -----END PGP SIGNATURE----- --6AFz5yWxU/FsGPwt-- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 14:37:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 208D61065716 for ; Sat, 29 Sep 2012 14:37:23 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id D866F8FC14 for ; Sat, 29 Sep 2012 14:37:22 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id B7B7E256; Sat, 29 Sep 2012 16:36:19 +0200 (CEST) Date: Sat, 29 Sep 2012 16:37:42 +0200 From: Pawel Jakub Dawidek To: Jason Usher Message-ID: <20120929143742.GH1402@garage.freebsd.pl> References: <1348155984.52722.YahooMailClassic@web121204.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GACvPnKyN03uhzyl" Content-Disposition: inline In-Reply-To: <1348155984.52722.YahooMailClassic@web121204.mail.ne1.yahoo.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS stats output - used, compressed, deduped, etc. 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, 29 Sep 2012 14:37:23 -0000 --GACvPnKyN03uhzyl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 08:46:24AM -0700, Jason Usher wrote: > Hi, >=20 > I have a ZFS filesystem with compression turned on. Does the "used" prop= erty show me the actual data size, or the compressed data size ? If it sho= ws me the compressed size, where can I see the actual data size ? To calculate uncompressed data size you multiple 'used' property by 'compressratio' property. > I also wonder about checking status of dedupe - I created my pool without= dedupe, and continue to NOT enable dedupe - from zpool history, we see: >=20 > zpool create -f -O atime=3Doff -O setuid=3Doff -O exec=3Doff -m /mnt/pool= pool raidz3 da0 da1 da2 da3 da4 da5 da6 da7 da8 da9 da10 da11 >=20 > Later, I enabled dedup for just a single filesystem on this pool: >=20 > zfs set dedup=3Don pool/dataset >=20 > and now, I see in 'zpool list' a value for dedupratio: >=20 > pool dedupratio 1.65x - >=20 >=20 > Why do I see a value here ? Isn't dedupe still OFF for the pool as a who= le ? I do NOT want to enable dedupe for the entire pool. >=20 > Also, why do I not see any dedupe stats for the individual filesystem ? = I see compressratio, and I see dedup=3Don, but I don't see any dedupratio f= or the filesystem itself... >=20 > Did turning on dedupe for a single filesystem turn it on for the entire p= ool ? Deduplication is pool-wide property that you enable for each individual file system. The idea here is to share deduped data across separate file systems. Note that only file systems that you enabled dedup for will actually participate in dedup. File systems that have dedup=3Doff won't go through the dedup. Dedup works while you write to file system. Block's checksum is being calculated and search for in dedup table. If we find a match, reference count is bumped and no additional data is written to the pool. This path is skipped for file systems that don't have dedup enabled. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --GACvPnKyN03uhzyl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBnB7UACgkQForvXbEpPzTtiACfWfp9d6CF39EFnyh6rytLf50x BO0AoMkjP5CK/S617zv3++MbQFe4RYhC =RIkf -----END PGP SIGNATURE----- --GACvPnKyN03uhzyl-- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 14:41:26 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE769106564A for ; Sat, 29 Sep 2012 14:41:26 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8351E8FC1A for ; Sat, 29 Sep 2012 14:41:26 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 30CDF259; Sat, 29 Sep 2012 16:40:23 +0200 (CEST) Date: Sat, 29 Sep 2012 16:41:45 +0200 From: Pawel Jakub Dawidek To: Dennis Glatting Message-ID: <20120929144145.GI1402@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RvYRPxT9kmUw5evD" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: How to recover from theis ZFS 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: Sat, 29 Sep 2012 14:41:26 -0000 --RvYRPxT9kmUw5evD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 19, 2012 at 11:35:15AM -0700, Dennis Glatting wrote: >=20 > One of my pools (disk-1) with 12T of data is reporting this error after a= =20 > scrub. Is there a way to fix this error without backing up and restoring= =20 > 12T of data? >=20 >=20 > errors: Permanent errors have been detected in the following files: >=20 > :<0x0> > disk-1:<0x0> Can you paste entire 'zpool status -v' output after scrub? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --RvYRPxT9kmUw5evD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBnCKgACgkQForvXbEpPzTLygCffE8guep4mi1lPjGYR/5u5QQv gPAAn0bBv7zBVdHd7tdYbuqbvt9DX6aZ =R72z -----END PGP SIGNATURE----- --RvYRPxT9kmUw5evD-- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 14:45:07 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA5DA1065672 for ; Sat, 29 Sep 2012 14:45:07 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 78BCB8FC18 for ; Sat, 29 Sep 2012 14:45:07 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 5FDEE25C; Sat, 29 Sep 2012 16:44:04 +0200 (CEST) Date: Sat, 29 Sep 2012 16:45:26 +0200 From: Pawel Jakub Dawidek To: "Justin T. Gibbs" Message-ID: <20120929144526.GJ1402@garage.freebsd.pl> References: <76CBA055-021F-458D-8978-E9A973D9B783@scsiguy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CxSUI8jTRJ26tNoZ" Content-Disposition: inline In-Reply-To: <76CBA055-021F-458D-8978-E9A973D9B783@scsiguy.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@FreeBSD.org Subject: Re: ZFS: Deadlock during vnode recycling 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, 29 Sep 2012 14:45:08 -0000 --CxSUI8jTRJ26tNoZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 18, 2012 at 09:14:22AM -0600, Justin T. Gibbs wrote: > One of our systems became unresponsive due to an inability to recycle > vnodes. We tracked this down to a deadlock in zfs_zget(). I've attached > the stack trace from the vnlru process to the end of this email. >=20 > We are currently testing the following patch. Since this issue is hard to > replicate I would appreciate review and feedback before I commit it to > FreeBSD. I think the patch is ok. The whole mess we have to deal when to comes to reclamation won't get much more messy with this patch in place:) > Patch > =3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D= =3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D= =3D=3D8< > Change 635310 by justing@justing_ns1_spectrabsd on 2012/09/17 15:30:14 >=20 > For most vnode consumers of ZFS, the appropriate behavior > when encountering a vnode that is in the process of being > reclaimed is to wait for that process to complete and then > allocate a new vnode. This behavior is enforced in zfs_zget() > by checking for the VI_DOOMED vnode flag. In the case of > the thread actually reclaiming the vnode, zfs_zget() must > return the current vnode, otherwise a deadlock will occur. > =09 > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h: > Create a virtual znode field, z_reclaim_td, which is > implemeted as a macro that redirects to z_task.ta_context. > =09 > z_task is only used by the reclaim code to perform the > final cleanup of a znode in a secondary thread. Since > this can only occur after any calls to zfs_zget(), it > is safe to reuse the ta_context field. > =09 > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: > In zfs_freebsd_reclaim(), record curthread in the > znode being reclaimed. > =09 > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c: > o Null out z_reclaim_td when znode_ts are constructed. > =09 > o In zfs_zget(), return a "doomed vnode" if the current > thread is actively reclaiming this object. >=20 > Affected files ... >=20 > ... //SpectraBSD/stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sy= s/zfs_znode.h#2 edit > ... //SpectraBSD/stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zf= s_vnops.c#3 edit > ... //SpectraBSD/stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zf= s_znode.c#2 edit >=20 > Differences ... >=20 > =3D=3D=3D=3D //SpectraBSD/stable/sys/cddl/contrib/opensolaris/uts/common/= fs/zfs/sys/zfs_znode.h#2 (text) =3D=3D=3D=3D >=20 > @@ -241,6 +241,7 @@ > struct task z_task; > } znode_t; > =20 > +#define z_reclaim_td z_task.ta_context > =20 > /* > * Convert between znode pointers and vnode pointers >=20 > =3D=3D=3D=3D //SpectraBSD/stable/sys/cddl/contrib/opensolaris/uts/common/= fs/zfs/zfs_vnops.c#3 (text) =3D=3D=3D=3D >=20 > @@ -6083,6 +6083,13 @@ > =20 > ASSERT(zp !=3D NULL); > =20 > + /* > + * Mark the znode so that operations that typically block > + * waiting for reclamation to complete will return the current, > + * "doomed vnode", for this thread. > + */ > + zp->z_reclaim_td =3D curthread; > + > /* > * Destroy the vm object and flush associated pages. > */ >=20 > =3D=3D=3D=3D //SpectraBSD/stable/sys/cddl/contrib/opensolaris/uts/common/= fs/zfs/zfs_znode.c#2 (text) =3D=3D=3D=3D >=20 > @@ -158,6 +158,7 @@ > zp->z_dirlocks =3D NULL; > zp->z_acl_cached =3D NULL; > zp->z_moved =3D 0; > + zp->z_reclaim_td =3D NULL; > return (0); > } > =20 > @@ -1192,7 +1193,8 @@ > dying =3D 1; > else { > VN_HOLD(vp); > - if ((vp->v_iflag & VI_DOOMED) !=3D 0) { > + if ((vp->v_iflag & VI_DOOMED) !=3D 0 && > + zp->z_reclaim_td !=3D curthread) { > dying =3D 1; > /* > * Don't VN_RELE() vnode here, because >=20 > vnlru_proc debug session > =3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D= =3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D8<=3D= =3D=3D8< > #0 sched_switch (td=3D0xfffffe000f87b470, newtd=3D0xfffffe000d36c8e0, fl= ags=3DVariable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1927 > #1 0xffffffff8057f2b6 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/sr= c/sys/kern/kern_synch.c:485 > #2 0xffffffff805b8982 in sleepq_timedwait (wchan=3D0xfffffe05c7515640, p= ri=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:658 > #3 0xffffffff8057f89f in _sleep (ident=3D0xfffffe05c7515640, lock=3D0x0,= priority=3DVariable "priority" is not available. > ) at /usr/src/sys/kern/kern_synch.c:246 > #4 0xffffffff81093035 in zfs_zget (zfsvfs=3D0xfffffe001de4c000, obj_num= =3D81963, zpp=3D0xffffff8c60dc51b0) at /usr/src/sys/modules/zfs/../../cddl/= contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1224 > #5 0xffffffff810bec9a in zfs_get_data (arg=3D0xfffffe001de4c000, lr=3D0x= ffffff820f5330b8, buf=3D0x0, zio=3D0xfffffe0584625000) at /usr/src/sys/modu= les/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1142 > #6 0xffffffff81096891 in zil_commit (zilog=3D0xfffffe001c382800, foid=3D= Variable "foid" is not available. > ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/zil.c:1048 > #7 0xffffffff810bceb0 in zfs_freebsd_write (ap=3DVariable "ap" is not av= ailable. > ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/zfs_vnops.c:1083 > #8 0xffffffff8081f112 in VOP_WRITE_APV (vop=3D0xffffffff8112cf40, a=3D0x= ffffff8c60dc5680) at vnode_if.c:951 > #9 0xffffffff807b1a6b in vnode_pager_generic_putpages (vp=3D0xfffffe05c7= 6171e0, ma=3D0xffffff8c60dc5890, bytecount=3DVariable "bytecount" is not av= ailable. > ) at vnode_if.h:413 > #10 0xffffffff807b1749 in vnode_pager_putpages (object=3D0xfffffe05e9ee9b= c8, m=3D0xffffff8c60dc5890, count=3D61440, sync=3D1, rtvals=3D0xffffff8c60d= c57a0) at vnode_if.h:1189 > #11 0xffffffff807aaee0 in vm_pageout_flush (mc=3D0xffffff8c60dc5890, coun= t=3D15, flags=3D1, mreq=3D0, prunlen=3D0xffffff8c60dc594c, eio=3D0xffffff8c= 60dc59c0) at vm_pager.h:145 > #12 0xffffffff807a3da3 in vm_object_page_collect_flush (object=3DVariable= "object" is not available. > ) at /usr/src/sys/vm/vm_object.c:936 > #13 0xffffffff807a3f23 in vm_object_page_clean (object=3D0xfffffe05e9ee9b= c8, start=3DVariable "start" is not available. > ) at /usr/src/sys/vm/vm_object.c:861 > #14 0xffffffff807a42d4 in vm_object_terminate (object=3D0xfffffe05e9ee9bc= 8) at /usr/src/sys/vm/vm_object.c:706 > #15 0xffffffff807b241e in vnode_destroy_vobject (vp=3D0xfffffe05c76171e0)= at /usr/src/sys/vm/vnode_pager.c:167 > #16 0xffffffff810beec7 in zfs_freebsd_reclaim (ap=3DVariable "ap" is not = available. > ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/zfs_vnops.c:6146 > #17 0xffffffff806101e1 in vgonel (vp=3D0xfffffe05c76171e0) at vnode_if.h:= 830 > #18 0xffffffff80616379 in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:7= 34 >=20 > (kgdb) frame 4 > #4 0xffffffff81093035 in zfs_zget (zfsvfs=3D0xfffffe001de4c000, obj_num= =3D81963, zpp=3D0xffffff8c60dc51b0) at /usr/src/sys/modules/zfs/../../cddl/= contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1224 > 1224 tsleep(zp, 0, "zcollide", 1); > (kgdb) l > 1219 sa_buf_rele(db, NULL); > 1220 mutex_exit(&zp->z_lock); > 1221 ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num= ); > 1222 if (vp !=3D NULL) > 1223 VN_RELE(vp); > 1224 tsleep(zp, 0, "zcollide", 1); > 1225 goto again; > 1226 } > 1227 *zpp =3D zp; > 1228 err =3D 0; > (kgdb) >=20 >=20 > _______________________________________________ > 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" --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --CxSUI8jTRJ26tNoZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBnCYYACgkQForvXbEpPzT8RwCgyP++edGnHK37PtdyBUeW33BC gVUAn1jEdRYlMExYwOb0q89oh9GB8pKR =+DJd -----END PGP SIGNATURE----- --CxSUI8jTRJ26tNoZ-- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 15:18:15 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C44E6106564A; Sat, 29 Sep 2012 15:18:15 +0000 (UTC) (envelope-from freebsd@pki2.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 53C4A8FC19; Sat, 29 Sep 2012 15:18:15 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q8TFHtPG029689; Sat, 29 Sep 2012 08:17:55 -0700 (PDT) (envelope-from freebsd@pki2.com) From: Dennis Glatting To: Pawel Jakub Dawidek In-Reply-To: <20120929144145.GI1402@garage.freebsd.pl> References: <20120929144145.GI1402@garage.freebsd.pl> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 29 Sep 2012 08:17:55 -0700 Message-ID: <1348931875.15649.4.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q8TFHtPG029689 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: fs@FreeBSD.org Subject: Re: How to recover from theis ZFS 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: Sat, 29 Sep 2012 15:18:15 -0000 On Sat, 2012-09-29 at 16:41 +0200, Pawel Jakub Dawidek wrote: > On Wed, Sep 19, 2012 at 11:35:15AM -0700, Dennis Glatting wrote: > > > > One of my pools (disk-1) with 12T of data is reporting this error after a > > scrub. Is there a way to fix this error without backing up and restoring > > 12T of data? > > > > > > errors: Permanent errors have been detected in the following files: > > > > :<0x0> > > disk-1:<0x0> > > Can you paste entire 'zpool status -v' output after scrub? > Yes but I am in the process of transferring off a 7TB file, which will take a few days and I don't want to potentually, negativly impact that transfer. It seems as though a common thread is my use of compressed file volumes, which is necessary due to my amounts of data. This is the current output: bd3# zpool status -v pool: disk-1 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://illumos.org/msg/ZFS-8000-8A scan: resilvered 384K in 0h0m with 0 errors on Wed Sep 19 08:18:21 2012 config: NAME STATE READ WRITE CKSUM disk-1 ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da13 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10 ONLINE 0 0 0 da11 ONLINE 0 0 0 logs gpt/zil-disk1 ONLINE 0 0 0 cache ada0 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: :<0x0> disk-1:<0x0> pool: disk-2 state: ONLINE scan: scrub repaired 0 in 0h1m with 0 errors on Tue Sep 18 02:37:13 2012 config: NAME STATE READ WRITE CKSUM disk-2 ONLINE 0 0 0 da12 ONLINE 0 0 0 logs gpt/zil-disk2 ONLINE 0 0 0 errors: No known data errors bd3# bd3# dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #3 r241015: Thu Sep 27 21:44:04 PDT 2012 root@bd3:/sys/amd64/compile/DTRACE amd64 CPU: AMD FX(tm)-8150 Eight-Core Processor (4017.98-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbff Features2=0x1e98220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33079078912 (31546 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfca0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 atrtc0: port 0x70-0x73 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 19 at device 3.0 on pci0 pci1: on pcib1 mps0: port 0xde00-0xdeff mem 0xfdbfc000-0xfdbfffff,0xfdb80000-0xfdbbffff irq 19 at device 0.0 on pci1 mps0: Firmware: 13.00.57.00, Driver: 14.00.00.01-fbsd mps0: IOCCapabilities: 1285c pcib2: irq 17 at device 9.0 on pci0 pci2: on pcib2 xhci0: mem 0xfd9f8000-0xfd9fffff irq 17 at device 0.0 on pci2 xhci0: 64 byte context size. usbus0 on xhci0 pcib3: irq 18 at device 10.0 on pci0 pci3: on pcib3 ahci0: port 0xbf00-0xbf07,0xbe00-0xbe03,0xbd00-0xbd07,0xbc00-0xbc03,0xbb00-0xbb0f mem 0xfd7ff000-0xfd7ff1ff irq 18 at device 0.0 on pci3 ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 pcib4: irq 19 at device 11.0 on pci0 pci4: on pcib4 mps1: port 0xae00-0xaeff mem 0xfcdfc000-0xfcdfffff,0xfcd80000-0xfcdbffff irq 19 at device 0.0 on pci4 mps1: Firmware: 13.00.57.00, Driver: 14.00.00.01-fbsd mps1: IOCCapabilities: 185c pcib5: irq 16 at device 12.0 on pci0 pci5: on pcib5 mps2: port 0x9e00-0x9eff mem 0xfdefc000-0xfdefffff,0xfde80000-0xfdebffff irq 16 at device 0.0 on pci5 mps2: Firmware: 13.00.57.00, Driver: 14.00.00.01-fbsd mps2: IOCCapabilities: 1285c pcib6: irq 17 at device 13.0 on pci0 pci6: on pcib6 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdcc0000-0xfdcdffff irq 17 at device 0.0 on pci6 hdac0: mem 0xfdcfc000-0xfdcfffff irq 18 at device 0.1 on pci6 ahci1: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfdfff000-0xfdfff3ff irq 19 at device 17.0 on pci0 ahci1: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported ahcich2: at channel 0 on ahci1 ahcich3: at channel 1 on ahci1 ahcich4: at channel 2 on ahci1 ahcich5: at channel 3 on ahci1 ahcich6: at channel 4 on ahci1 ahcich7: at channel 5 on ahci1 ohci0: mem 0xfdffe000-0xfdffefff irq 18 at device 18.0 on pci0 usbus1 on ohci0 ehci0: mem 0xfdffd000-0xfdffd0ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 ohci1: mem 0xfdffc000-0xfdffcfff irq 18 at device 19.0 on pci0 usbus3 on ohci1 ehci1: mem 0xfdffb000-0xfdffb0ff irq 17 at device 19.2 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci1 pci0: at device 20.0 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib7: at device 20.4 on pci0 pci7: on pcib7 ath0: mem 0xfd6e0000-0xfd6effff irq 20 at device 6.0 on pci7 [ath] enabling AN_TOP2_FIXUP [ath]: default pwr offset: -5 dBm != EEPROM pwr offset: 0 dBm; curves will be adjusted. ath0: AR9280 mac 128.2 RF5133 phy 13.0 ohci2: mem 0xfdffa000-0xfdffafff irq 18 at device 20.5 on pci0 usbus5 on ohci2 pcib8: at device 21.0 on pci0 pci8: on pcib8 re0: port 0x7e00-0x7eff mem 0xfd2ff000-0xfd2fffff,0xfd2f8000-0xfd2fbfff irq 17 at device 0.0 on pci8 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 50:e5:49:45:55:8e pcib9: at device 21.1 on pci0 pci9: on pcib9 xhci1: mem 0xfd1f8000-0xfd1fffff irq 17 at device 0.0 on pci9 xhci1: 64 byte context size. usbus6 on xhci1 pcib10: at device 21.2 on pci0 pci10: on pcib10 ahci2: port 0x5f00-0x5f07,0x5e00-0x5e03,0x5d00-0x5d07,0x5c00-0x5c03,0x5b00-0x5b0f mem 0xfcfff000-0xfcfff1ff irq 17 at device 0.0 on pci10 ahci2: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS ahcich8: at channel 0 on ahci2 ahcich9: at channel 1 on ahci2 ohci3: mem 0xfdff9000-0xfdff9fff irq 18 at device 22.0 on pci0 usbus7 on ohci3 ehci2: mem 0xfdff8000-0xfdff80ff irq 17 at device 22.2 on pci0 usbus8: EHCI version 1.0 usbus8 on ehci2 orm0: at iomem 0xc0000-0xcffff,0xd5000-0xdafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range ctl: CAM Target Layer loaded hwpstate0: on cpu0 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 5.0Gbps Super Speed USB v3.0 usbus7: 12Mbps Full Speed USB v1.0 usbus8: 480Mbps High Speed USB v2.0 ugen0.1: <0x1b6f> at usbus0 uhub0: <0x1b6f XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: <0x1b6f> at usbus6 uhub6: <0x1b6f XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ugen8.1: at usbus8 uhub8: on usbus8 uhub5: 2 ports with 2 removable, self powered uhub7: 4 ports with 4 removable, self powered uhub1: 5 ports with 5 removable, self powered uhub3: 5 ports with 5 removable, self powered uhub0: 4 ports with 4 removable, self powered uhub6: 4 ports with 4 removable, self powered (probe257:mps1:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe257:mps1:0:2:0): CAM status: Invalid Target ID (probe257:mps1:0:2:0): Error 22, Unretryable error (probe258:mps1:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe258:mps1:0:3:0): CAM status: Invalid Target ID (probe258:mps1:0:3:0): Error 22, Unretryable error (probe2:mps1:0:2:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe2:mps1:0:2:1): CAM status: Invalid Target ID (probe2:mps1:0:2:1): Error 22, Unretryable error (probe8:mps1:0:3:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe8:mps1:0:3:1): CAM status: Invalid Target ID (probe8:mps1:0:3:1): Error 22, Unretryable error (probe2:mps1:0:2:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe2:mps1:0:2:2): CAM status: Invalid Target ID (probe2:mps1:0:2:2): Error 22, Unretryable error (probe8:mps1:0:3:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe8:mps1:0:3:2): CAM status: Invalid Target ID (probe8:mps1:0:3:2): Error 22, Unretryable error (probe2:mps1:0:2:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe2:mps1:0:2:3): CAM status: Invalid Target ID (probe2:mps1:0:2:3): Error 22, Unretryable error (probe8:mps1:0:3:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe8:mps1:0:3:3): CAM status: Invalid Target ID (probe8:mps1:0:3:3): Error 22, Unretryable error (probe2:mps1:0:2:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe2:mps1:0:2:4): CAM status: Invalid Target ID (probe2:mps1:0:2:4): Error 22, Unretryable error (probe8:mps1:0:3:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe8:mps1:0:3:4): CAM status: Invalid Target ID (probe8:mps1:0:3:4): Error 22, Unretryable error (probe2:mps1:0:2:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe2:mps1:0:2:5): CAM status: Invalid Target ID (probe2:mps1:0:2:5): Error 22, Unretryable error (probe8:mps1:0:3:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe8:mps1:0:3:5): CAM status: Invalid Target ID (probe8:mps1:0:3:5): Error 22, Unretryable error (probe2:mps1:0:2:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe2:mps1:0:2:6): CAM status: Invalid Target ID (probe2:mps1:0:2:6): Error 22, Unretryable error (probe8:mps1:0:3:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe8:mps1:0:3:6): CAM status: Invalid Target ID (probe8:mps1:0:3:6): Error 22, Unretryable error (probe2:mps1:0:2:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe2:mps1:0:2:7): CAM status: Invalid Target ID (probe2:mps1:0:2:7): Error 22, Unretryable error (probe8:mps1:0:3:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe8:mps1:0:3:7): CAM status: Invalid Target ID (probe8:mps1:0:3:7): Error 22, Unretryable error (probe2:mps1:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe2:mps1:0:3:0): CAM status: Invalid Target ID (probe2:mps1:0:3:0): Error 22, Unretryable error (probe8:mps1:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:mps1:0:2:0): CAM status: Invalid Target ID (probe8:mps1:0:2:0): Error 22, Unretryable error (probe255:mps1:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe255:mps1:0:0:0): CAM status: SCSI Status Error (probe255:mps1:0:0:0): SCSI status: Check Condition (probe255:mps1:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe255:mps1:0:0:0): Command Specific Info: 0x344703c0 (probe255:mps1:0:0:0): Error 22, Unretryable error (probe2:mps1:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe2:mps1:0:3:0): CAM status: Invalid Target ID (probe2:mps1:0:3:0): Error 22, Unretryable error (probe8:mps1:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:mps1:0:2:0): CAM status: Invalid Target ID (probe8:mps1:0:2:0): Error 22, Unretryable error (probe9:mps1:0:3:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe9:mps1:0:3:1): CAM status: Invalid Target ID (probe9:mps1:0:3:1): Error 22, Unretryable error (probe2:mps1:0:2:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe2:mps1:0:2:1): CAM status: Invalid Target ID (probe2:mps1:0:2:1): Error 22, Unretryable error (probe8:mps1:0:3:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe8:mps1:0:3:1): CAM status: Invalid Target ID (probe8:mps1:0:3:1): Error 22, Unretryable error (probe2:mps1:0:2:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe2:mps1:0:2:1): CAM status: Invalid Target ID (probe2:mps1:0:2:1): Error 22, Unretryable error (probe9:mps1:0:3:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe9:mps1:0:3:2): CAM status: Invalid Target ID (probe9:mps1:0:3:2): Error 22, Unretryable error (probe8:mps1:0:2:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe8:mps1:0:2:2): CAM status: Invalid Target ID (probe8:mps1:0:2:2): Error 22, Unretryable error (probe2:mps1:0:3:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe2:mps1:0:3:2): CAM status: Invalid Target ID (probe2:mps1:0:3:2): Error 22, Unretryable error (probe8:mps1:0:2:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe8:mps1:0:2:2): CAM status: Invalid Target ID (probe8:mps1:0:2:2): Error 22, Unretryable error (probe9:mps1:0:3:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe9:mps1:0:3:3): CAM status: Invalid Target ID (probe9:mps1:0:3:3): Error 22, Unretryable error (probe2:mps1:0:2:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe2:mps1:0:2:3): CAM status: Invalid Target ID (probe2:mps1:0:2:3): Error 22, Unretryable error (probe8:mps1:0:3:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe8:mps1:0:3:3): CAM status: Invalid Target ID (probe8:mps1:0:3:3): Error 22, Unretryable error (probe2:mps1:0:2:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe2:mps1:0:2:3): CAM status: Invalid Target ID (probe2:mps1:0:2:3): Error 22, Unretryable error (probe9:mps1:0:3:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe9:mps1:0:3:4): CAM status: Invalid Target ID (probe9:mps1:0:3:4): Error 22, Unretryable error (probe8:mps1:0:2:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe8:mps1:0:2:4): CAM status: Invalid Target ID (probe8:mps1:0:2:4): Error 22, Unretryable error (probe2:mps1:0:3:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe2:mps1:0:3:4): CAM status: Invalid Target ID (probe2:mps1:0:3:4): Error 22, Unretryable error (probe8:mps1:0:2:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe8:mps1:0:2:4): CAM status: Invalid Target ID (probe8:mps1:0:2:4): Error 22, Unretryable error (probe9:mps1:0:3:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe9:mps1:0:3:5): CAM status: Invalid Target ID (probe9:mps1:0:3:5): Error 22, Unretryable error (probe2:mps1:0:2:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe2:mps1:0:2:5): CAM status: Invalid Target ID (probe2:mps1:0:2:5): Error 22, Unretryable error (probe8:mps1:0:3:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe8:mps1:0:3:5): CAM status: Invalid Target ID (probe8:mps1:0:3:5): Error 22, Unretryable error (probe2:mps1:0:2:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe2:mps1:0:2:5): CAM status: Invalid Target ID (probe2:mps1:0:2:5): Error 22, Unretryable error (probe9:mps1:0:3:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe9:mps1:0:3:6): CAM status: Invalid Target ID (probe9:mps1:0:3:6): Error 22, Unretryable error (probe8:mps1:0:2:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe8:mps1:0:2:6): CAM status: Invalid Target ID (probe8:mps1:0:2:6): Error 22, Unretryable error (probe2:mps1:0:3:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe2:mps1:0:3:6): CAM status: Invalid Target ID (probe2:mps1:0:3:6): Error 22, Unretryable error (probe8:mps1:0:2:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe8:mps1:0:2:6): CAM status: Invalid Target ID (probe8:mps1:0:2:6): Error 22, Unretryable error (probe9:mps1:0:3:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe9:mps1:0:3:7): CAM status: Invalid Target ID (probe9:mps1:0:3:7): Error 22, Unretryable error (probe2:mps1:0:2:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe2:mps1:0:2:7): CAM status: Invalid Target ID (probe2:mps1:0:2:7): Error 22, Unretryable error (probe8:mps1:0:3:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe8:mps1:0:3:7): CAM status: Invalid Target ID (probe8:mps1:0:3:7): Error 22, Unretryable error (probe2:mps1:0:2:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe2:mps1:0:2:7): CAM status: Invalid Target ID (probe2:mps1:0:2:7): Error 22, Unretryable error (probe255:mps1:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe255:mps1:0:0:0): CAM status: SCSI Status Error (probe255:mps1:0:0:0): SCSI status: Check Condition (probe255:mps1:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe255:mps1:0:0:0): Field Replaceable Unit: 55 (probe255:mps1:0:0:0): Command Specific Info: 0x36343236 (probe255:mps1:0:0:0): Error 22, Unretryable error ada0 at ahcich2 bus 0 scbus5 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 85857MB (175836528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 ada1 at ahcich3 bus 0 scbus6 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad10 da7 at mps1 bus 0 scbus3 target 0 lun 0 da7: Fixed Direct Access SCSI-6 device da7: 150.000MB/s transfers da7: Command Queueing enabled da7: 952720MB (1951170560 512 byte sectors: 255H 63S/T 121454C) da6 at mps0 bus 0 scbus0 target 7 lun 0 da6: Fixed Direct Access SCSI-6 device da6: 600.000MB/s transfers da6: Command Queueing enabled da6: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da2 at mps0 bus 0 scbus0 target 3 lun 0 da2: Fixed Direct Access SCSI-6 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da3 at mps0 bus 0 scbus0 target 4 lun 0 da3: Fixed Direct Access SCSI-6 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da4 at mps0 bus 0 scbus0 target 5 lun 0 da4: Fixed Direct Access SCSI-6 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da5 at mps0 bus 0 scbus0 target 6 lun 0 da5: Fixed Direct Access SCSI-6 device da5: 300.000MB/s transfers da5: Command Queueing enabled da5: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da11 at mps2 bus 0 scbus4 target 5 lun 0 da11: Fixed Direct Access SCSI-6 device da11: 300.000MB/s transfers da11: Command Queueing enabled da11: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da10 at mps2 bus 0 scbus4 target 2 lun 0 da10: Fixed Direct Access SCSI-6 device da10: 300.000MB/s transfers da10: Command Queueing enabled da10: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da9 at mps2 bus 0 scbus4 target 1 lun 0 da9: Fixed Direct Access SCSI-6 device da9: 300.000MB/s transfers da9: Command Queueing enabled da9: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da8 at mps2 bus 0 scbus4 target 0 lun 0 da8: Fixed Direct Access SCSI-6 device da8: 300.000MB/s transfers da8: Command Queueing enabled da8: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da13 at mps2 bus 0 scbus4 target 8 lun 0 da13: Fixed Direct Access SCSI-6 device da13: 300.000MB/s transfers da13: Command Queueing enabled da13: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da1 at mps0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-6 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) da0 at mps0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 2384658MB (4883781168 512 byte sectors: 255H 63S/T 304001C) SMP: AP CPU #1 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 15695244 Hz quality 1000 uhub8: 4 ports with 4 removable, self powered da12 at mps2 bus 0 scbus4 target 6 lun 0 da12: Fixed Direct Access SCSI-6 device da12: 600.000MB/s transfers da12: Command Queueing enabled da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) uhub4: 5 ports with 5 removable, self powered uhub2: 5 ports with 5 removable, self powered ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 uhid0: on usbus1 Trying to mount root from ufs:/dev/gpt/disk0 [rw]... ZFS filesystem version 5 ZFS storage pool version 28 bd3# From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 15:40:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEE1F1065670; Sat, 29 Sep 2012 15:40:43 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA1F8FC1B; Sat, 29 Sep 2012 15:40:43 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id AFCBF26E; Sat, 29 Sep 2012 17:39:39 +0200 (CEST) Date: Sat, 29 Sep 2012 17:41:02 +0200 From: Pawel Jakub Dawidek To: Konstantin Belousov Message-ID: <20120929154101.GK1402@garage.freebsd.pl> References: <505DB4E6.8030407@smeets.im> <20120924224606.GE79077@ithaqua.etoilebsd.net> <20120925090840.GD35915@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKaPnVNVpyX08bAX" Content-Disposition: inline In-Reply-To: <20120925090840.GD35915@deviant.kiev.zoral.com.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ ...cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1407 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, 29 Sep 2012 15:40:44 -0000 --gKaPnVNVpyX08bAX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2012 at 12:08:40PM +0300, Konstantin Belousov wrote: > On Tue, Sep 25, 2012 at 12:46:07AM +0200, Baptiste Daroussin wrote: > > Hi, > >=20 > > I have the exact same problem making: tinderbox and poudriere highly > > unusable. > > > > This is really problematic because pointyhat also rely on nullfs and > > zfs, which means we can't upgrade the building nodes if we need to for > > example. > > > > regards, Bapt >=20 > This is zfs bug. Filesystems shall not call getnewvnode() while holding > internal locks. At least not the locks which are needed during reclaim. > Nullfs changes amplified the probability of the problematic situation, > since now nullfs vnodes are indeed cached instead of being recreated > on each access, so the overall count of used vnodes could be twice as > high. >=20 > You might try to increase the kern.maxvnodes to reduce the probability of > the recursive calls into vnlnru() from getnewvnode(). But for real, bug > needs to be fixed in zfs. With all FreeBSD's VFS constraints, it is really hard to breath, especially within file system that was not designed with our VFS complexity in mind. For example it would be nice of VFS to not reclaim vnodes from getnewvnode() and leave this task entirely to the vnlru process. It is pretty obvious layering violation to me - file system code needs new vnode, it calls VFS routine to allocate one, which then calls file system again to reclaim one of its vnodes. It would also be nice to handle EAGAIN from VOP_RECLAIM(). Currently we panic on error. This would be useful to return if some of the locks cannot be acquired immediately. ZFS reclaim already discovers potential deadlocks and defer some reclamation portion to separate thread. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --gKaPnVNVpyX08bAX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBnFo0ACgkQForvXbEpPzQ9AgCdE3vMR7ftQFE2OoT84R6K7b0w gAEAoKiRNATQHM1RmGIc0p/T3sn1/Hed =yysf -----END PGP SIGNATURE----- --gKaPnVNVpyX08bAX-- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 23:06:57 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA224106566C; Sat, 29 Sep 2012 23:06:57 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (ns1.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 8F04B8FC08; Sat, 29 Sep 2012 23:06:57 +0000 (UTC) Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q8TMiV3g033068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 Sep 2012 16:44:31 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: "Justin T. Gibbs" In-Reply-To: <20120929144526.GJ1402@garage.freebsd.pl> Date: Sat, 29 Sep 2012 16:44:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76CBA055-021F-458D-8978-E9A973D9B783@scsiguy.com> <20120929144526.GJ1402@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1498) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [192.168.0.4]); Sat, 29 Sep 2012 16:44:31 -0600 (MDT) Cc: fs@freebsd.org Subject: Re: ZFS: Deadlock during vnode recycling 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, 29 Sep 2012 23:06:57 -0000 On Sep 29, 2012, at 8:45 AM, Pawel Jakub Dawidek = wrote: > On Tue, Sep 18, 2012 at 09:14:22AM -0600, Justin T. Gibbs wrote: >> One of our systems became unresponsive due to an inability to recycle >> vnodes. We tracked this down to a deadlock in zfs_zget(). I've = attached >> the stack trace from the vnlru process to the end of this email. >>=20 >> We are currently testing the following patch. Since this issue is = hard to >> replicate I would appreciate review and feedback before I commit it = to >> FreeBSD. >=20 > I think the patch is ok. The whole mess we have to deal when to comes = to > reclamation won't get much more messy with this patch in place:) We're running now with something a little more invasive than the last patch I presented. I added stats for the two different types of collisions, but doing so made zfs_zget() even more messy, so I refactored it. I also made the stats in the file real kstats. -- Justin Both together: Change 635310 by justing@justing_ns1_spectrabsd on 2012/09/17 15:30:14 For most vnode consumers of ZFS, the appropriate behavior when encountering a vnode that is in the process of being reclaimed is to wait for that process to complete and then allocate a new vnode. This behavior is enforced in zfs_zget() by checking for the VI_DOOMED vnode flag. In the case of the thread actually reclaiming the vnode, zfs_zget() must return the current vnode, otherwise a deadlock will occur. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h: Create a virtual znode field, z_reclaim_td, which is implemeted as a macro that redirects to z_task.ta_context. z_task is only used by the reclaim code to perform the final cleanup of a znode in a secondary thread. Since this can only occur after any calls to zfs_zget(), it is safe to reuse the ta_context field. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In zfs_freebsd_reclaim(), record curthread in the znode being reclaimed. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c: o Null out z_reclaim_td when znode_ts are constructed. o In zfs_zget(), return a "doomed vnode" if the current thread is actively reclaiming this object. Change 635653 on 2012/09/19 by justing@justing_ns1_spectrabsd Add statistics for zfs_zget() vnode reclamation collisions. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c: o Convert the existing, but sun only, znode stats to use the solaris kstat facility much like the rest of ZFS. o Create a debug class of znode stats which are only collected and published if ZFS's DEBUG macro is defined. These are incremented using ZNODE_DEBUG_STAT_ADD() instead of ZNODE_STAT_ADD(). All of the pre-existing stats were debug only, and are now in this class. o Add two new (always available) stat entries: zget_reclaim_collisions: The number of times ZFS has slept in zfs_zget() waiting for a vnode to be reclaimed. zget_reclaim_td_collisions: The number of times ZFS has entered zfs_zget() from the thread reclaiming the vnode that is being reclaimed. In this case the "doomed" vnode is returned imemediately so that reclamation can complete. o Refactor zfs_zget() Two new helper functions were created: =20 zfs_zget_znode_alloc(): Called by zfs_zget() when no existing znode is found. zfs_zget_reclaim_pause(): Called by zfs_zget() when it must pause to wait for an in-progress vnode reclamation to complete. Using these routines, restructure zfs_zget() to remove a goto and nested blocks that pushed the common path way off to the right. --- = /usr/home/justing/perforce/vendor/FreeBSD/head/sys/cddl/contrib/opensolari= s/uts/common/fs/zfs/zfs_znode.h 2012-09-14 16:27:27.869936258 -0600 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.h = 2012-09-20 10:56:49.908850009 -0600 @@ -241,6 +241,7 @@ struct task z_task; } znode_t; =20 +#define z_reclaim_td z_task.ta_context =20 /* * Convert between znode pointers and vnode pointers --- = /usr/home/justing/perforce/vendor/FreeBSD/head/sys/cddl/contrib/opensolari= s/uts/common/fs/zfs/zfs_vnops.c 2012-09-14 16:27:27.869936258 -0600 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c = 2012-09-20 10:56:49.908850009 -0600 @@ -6083,6 +6083,13 @@ zfs_freebsd_reclaim(ap) =20 ASSERT(zp !=3D NULL); =20 + /* + * Mark the znode so that operations that typically block + * waiting for reclamation to complete will return the current, + * "doomed vnode", for this thread. + */ + zp->z_reclaim_td =3D curthread; + /* * Destroy the vm object and flush associated pages. */ --- = /usr/home/justing/perforce/vendor/FreeBSD/head/sys/cddl/contrib/opensolari= s/uts/common/fs/zfs/zfs_znode.c 2012-09-14 16:27:27.869936258 -0600 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c = 2012-09-20 10:56:49.908850009 -0600 @@ -43,6 +42,7 @@ #include #include #include +#include #include #include #include @@ -70,19 +70,53 @@ SYSCTL_INT(_debug_sizeof, OID_AUTO, znode, CTLFLAG_RD, 0, = sizeof(znode_t), "sizeof(znode_t)"); =20 -/* - * Define ZNODE_STATS to turn on statistic gathering. By default, it is = only - * turned on when DEBUG is also defined. - */ +typedef struct znode_stats { + kstat_named_t zns_zget_reclaim_collisions; + kstat_named_t zns_zget_reclaim_td_collisions; +} znode_stats_t; + +static znode_stats_t znode_stats =3D { + { "zget_reclaim_collisions", KSTAT_DATA_UINT64 }, + { "zget_reclaim_td_collisions", KSTAT_DATA_UINT64 }, +}; +kstat_t *znode_ksp; + +#define ZNODE_STAT_ADD(stat) \ + atomic_add_64(&znode_stats.zns_##stat.value.ui64, 1) + #ifdef DEBUG -#define ZNODE_STATS -#endif /* DEBUG */ +typedef struct znode_debug_stats { +#ifdef sun + kstat_named_t znds_move_zfsvfs_invald; + kstat_named_t znds_move_zfsvfs_recheck1; + kstat_named_t znds_move_zfsvfs_unmounted; + kstat_named_t znds_move_zfsvfs_recheck2; + kstat_named_t znds_move_obj_held; + kstat_named_t znds_move_vnode_locked; + kstat_named_t znds_move_not_only_dnlc; + kstat_named_t znds_zget_reclaim_collision; + kstat_named_t znds_zget_reclaim_td_collision; +#endif /* sun */ +} znode_debug_stats_t; =20 -#ifdef ZNODE_STATS -#define ZNODE_STAT_ADD(stat) ((stat)++) +static znode_debug_stats_t znode_debug_stats =3D { +#ifdef sun + { "move_zfsvfs_invalid", KSTAT_DATA_UINT64 }, + { "move_zfsvfs_recheck1", KSTAT_DATA_UINT64 }, + { "move_zfsvfs_unmounted", KSTAT_DATA_UINT64 }, + { "move_zfsvfs_recheck2", KSTAT_DATA_UINT64 }, + { "move_obj_held", KSTAT_DATA_UINT64 }, + { "move_vnode_locked", KSTAT_DATA_UINT64 }, + { "move_not_only_dnlc", KSTAT_DATA_UINT64 }, +#endif /* sun */ +}; +kstat_t *znode_debug_ksp; + +#define ZNODE_DEBUG_STAT_ADD(stat) \ + atomic_add_64(&znode_debug_stats.znds_##stat.value.ui64, 1) #else -#define ZNODE_STAT_ADD(stat) /* nothing */ -#endif /* ZNODE_STATS */ +#define ZNODE_DEBUG_STAT_ADD(stat) do { } while (0) +#endif /* DEBUG */ =20 /* * Functions needed for userland (ie: libzpool) are not put under @@ -159,6 +193,7 @@ zfs_znode_cache_constructor(void *buf, v zp->z_dirlocks =3D NULL; zp->z_acl_cached =3D NULL; zp->z_moved =3D 0; + zp->z_reclaim_td =3D NULL; return (0); } =20 @@ -277,7 +312,7 @@ zfs_znode_move(void *buf, void *newbuf,=20 */ zfsvfs =3D ozp->z_zfsvfs; if (!POINTER_IS_VALID(zfsvfs)) { - ZNODE_STAT_ADD(znode_move_stats.zms_zfsvfs_invalid); + ZNODE_DEBUG_STAT_ADD(move_zfsvfs_invalid); return (KMEM_CBRC_DONT_KNOW); } =20 @@ -290,7 +325,7 @@ zfs_znode_move(void *buf, void *newbuf,=20 rw_enter(&zfsvfs_lock, RW_WRITER); if (zfsvfs !=3D ozp->z_zfsvfs) { rw_exit(&zfsvfs_lock); - ZNODE_STAT_ADD(znode_move_stats.zms_zfsvfs_recheck1); + ZNODE_DEBUG_STAT_ADD(move_zfsvfs_recheck1); return (KMEM_CBRC_DONT_KNOW); } =20 @@ -304,7 +339,7 @@ zfs_znode_move(void *buf, void *newbuf,=20 if (zfsvfs->z_unmounted) { ZFS_EXIT(zfsvfs); rw_exit(&zfsvfs_lock); - ZNODE_STAT_ADD(znode_move_stats.zms_zfsvfs_unmounted); + ZNODE_DEBUG_STAT_ADD(move_zfsvfs_unmounted); return (KMEM_CBRC_DONT_KNOW); } rw_exit(&zfsvfs_lock); @@ -317,7 +352,7 @@ zfs_znode_move(void *buf, void *newbuf,=20 if (zfsvfs !=3D ozp->z_zfsvfs) { mutex_exit(&zfsvfs->z_znodes_lock); ZFS_EXIT(zfsvfs); - ZNODE_STAT_ADD(znode_move_stats.zms_zfsvfs_recheck2); + ZNODE_DEBUG_STAT_ADD(move_zfsvfs_recheck2); return (KMEM_CBRC_DONT_KNOW); } =20 @@ -329,7 +364,7 @@ zfs_znode_move(void *buf, void *newbuf,=20 if (ZFS_OBJ_HOLD_TRYENTER(zfsvfs, ozp->z_id) =3D=3D 0) { mutex_exit(&zfsvfs->z_znodes_lock); ZFS_EXIT(zfsvfs); - ZNODE_STAT_ADD(znode_move_stats.zms_obj_held); + ZNODE_DEBUG_STAT_ADD(move_obj_held); return (KMEM_CBRC_LATER); } =20 @@ -338,7 +373,7 @@ zfs_znode_move(void *buf, void *newbuf,=20 ZFS_OBJ_HOLD_EXIT(zfsvfs, ozp->z_id); mutex_exit(&zfsvfs->z_znodes_lock); ZFS_EXIT(zfsvfs); - ZNODE_STAT_ADD(znode_move_stats.zms_vnode_locked); + ZNODE_DEBUG_STAT_ADD(move_vnode_locked); return (KMEM_CBRC_LATER); } =20 @@ -348,7 +383,7 @@ zfs_znode_move(void *buf, void *newbuf,=20 ZFS_OBJ_HOLD_EXIT(zfsvfs, ozp->z_id); mutex_exit(&zfsvfs->z_znodes_lock); ZFS_EXIT(zfsvfs); - ZNODE_STAT_ADD(znode_move_stats.zms_not_only_dnlc); + ZNODE_DEBUG_STAT_ADD(move_not_only_dnlc); return (KMEM_CBRC_LATER); } =20 @@ -380,6 +415,27 @@ zfs_znode_init(void) sizeof (znode_t), 0, /* zfs_znode_cache_constructor */ NULL, zfs_znode_cache_destructor, NULL, NULL, NULL, 0); kmem_cache_set_move(znode_cache, zfs_znode_move); + + znode_ksp =3D kstat_create("zfs", 0, "znodestats", "misc", + KSTAT_TYPE_NAMED, sizeof (znode_stats) / sizeof = (kstat_named_t), + KSTAT_FLAG_VIRTUAL); + + if (znode_ksp !=3D NULL) { + znode_ksp->ks_data =3D &znode_stats; + kstat_install(znode_ksp); + } + +#ifdef DEBUG + znode_debug_ksp =3D kstat_create("zfs", 0, "znodestats", = "debug", + KSTAT_TYPE_NAMED, + sizeof (znode_debug_stats) / sizeof (kstat_named_t), + KSTAT_FLAG_VIRTUAL); + + if (znode_debug_ksp !=3D NULL) { + znode_debug_ksp->ks_data =3D &znode_debug_stats; + kstat_install(znode_debug_ksp); + } +#endif /* DEBUG */ } =20 void @@ -399,6 +455,17 @@ zfs_znode_fini(void) kmem_cache_destroy(znode_cache); znode_cache =3D NULL; rw_destroy(&zfsvfs_lock); + + if (znode_ksp !=3D NULL) { + kstat_delete(znode_ksp); + znode_ksp =3D NULL; + } +#ifdef DEBUG + if (znode_debug_ksp !=3D NULL) { + kstat_delete(znode_debug_ksp); + znode_debug_ksp =3D NULL; + } +#endif /* DEBUG */ } =20 #ifdef sun @@ -1140,6 +1203,69 @@ zfs_xvattr_set(znode_t *zp, xvattr_t *xv } } =20 +/* + * Safely sleep for a short period while waiting for vnode + * reclamation to complete. + */ +static void +zfs_zget_reclaim_pause(zfsvfs_t *zfsvfs, uint64_t obj_num, dmu_buf_t = *db, + znode_t *zp, vnode_t *vp) +{ + sa_buf_rele(db, NULL); + mutex_exit(&zp->z_lock); + ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); + if (vp !=3D NULL) { + /* + * We must VN_RELE() the vnode here, after dropping + * the znode lock, instead of closer to the VN_HOLD() + * where the dying vnode is first detected. VN_RELE() + * will call vn_lock() when the last reference is + * dropped, but the defined locking order is vnode lock + * followed by the znode lock. + */ + VN_RELE(vp); + } + ZNODE_STAT_ADD(zget_reclaim_collisions); + tsleep(zp, 0, "zcollide", 1); +} + +/* + * Create a new znode/vnode but only if the file exists. + * + * Note: There is a small window where zfs_vget() could + * find this object while a file create is still in + * progress. This is checked for in zfs_znode_alloc(). + * + * Note: If zfs_znode_alloc() fails it will drop the hold on the + * bonus buffer. + */ +static int +zfs_zget_znode_alloc(zfsvfs_t *zfsvfs, dmu_buf_t *db, dmu_object_info_t = *doi, + znode_t **zpp) +{ + znode_t *zp; + vnode_t *vp; + int err; + + *zpp =3D NULL; + zp =3D zfs_znode_alloc(zfsvfs, db, doi->doi_data_block_size, + doi->doi_bonus_type, NULL); + if (zp =3D=3D NULL) + return (ENOENT); + + vp =3D ZTOV(zp); + err =3D insmntque(vp, zfsvfs->z_vfs); + if (err !=3D 0) { + zp->z_vnode =3D NULL; + zfs_znode_dmu_fini(zp); + zfs_znode_free(zp); + return (err); + } + *zpp =3D zp; + VOP_UNLOCK(vp, 0); + return (0); +} + int zfs_zget(zfsvfs_t *zfsvfs, uint64_t obj_num, znode_t **zpp) { @@ -1148,33 +1274,38 @@ zfs_zget(zfsvfs_t *zfsvfs, uint64_t obj_ znode_t *zp; int err; sa_handle_t *hdl; - int first =3D 1; =20 *zpp =3D NULL; =20 -again: - ZFS_OBJ_HOLD_ENTER(zfsvfs, obj_num); + for (;;) { + vnode_t *vp; =20 - err =3D sa_buf_hold(zfsvfs->z_os, obj_num, NULL, &db); - if (err) { - ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); - return (err); - } + ZFS_OBJ_HOLD_ENTER(zfsvfs, obj_num); =20 - dmu_object_info_from_db(db, &doi); - if (doi.doi_bonus_type !=3D DMU_OT_SA && - (doi.doi_bonus_type !=3D DMU_OT_ZNODE || - (doi.doi_bonus_type =3D=3D DMU_OT_ZNODE && - doi.doi_bonus_size < sizeof (znode_phys_t)))) { - sa_buf_rele(db, NULL); - ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); - return (EINVAL); - } + err =3D sa_buf_hold(zfsvfs->z_os, obj_num, NULL, &db); + if (err) { + ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); + return (err); + } =20 - hdl =3D dmu_buf_get_user(db); - if (hdl !=3D NULL) { - zp =3D sa_get_userdata(hdl); + dmu_object_info_from_db(db, &doi); + if (doi.doi_bonus_type !=3D DMU_OT_SA && + (doi.doi_bonus_type !=3D DMU_OT_ZNODE || + (doi.doi_bonus_type =3D=3D DMU_OT_ZNODE && + doi.doi_bonus_size < sizeof (znode_phys_t)))) { + sa_buf_rele(db, NULL); + ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); + return (EINVAL); + } + + hdl =3D (sa_handle_t *)dmu_buf_get_user(db); + if (hdl =3D=3D NULL) { + err =3D zfs_zget_znode_alloc(zfsvfs, db, &doi, = zpp); + ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); + return (err); + } =20 + zp =3D sa_get_userdata(hdl); =20 /* * Since "SA" does immediate eviction we @@ -1188,83 +1319,36 @@ again: ASSERT3U(zp->z_id, =3D=3D, obj_num); if (zp->z_unlinked) { err =3D ENOENT; - } else { - vnode_t *vp; - int dying =3D 0; + break; + } =20 - vp =3D ZTOV(zp); - if (vp =3D=3D NULL) - dying =3D 1; - else { - VN_HOLD(vp); - if ((vp->v_iflag & VI_DOOMED) !=3D 0) { - dying =3D 1; - /* - * Don't VN_RELE() vnode here, = because - * it can call vn_lock() which = creates - * LOR between vnode lock and = znode - * lock. We will VN_RELE() the = vnode - * after droping znode lock. - */ - } - } - if (dying) { - if (first) { - ZFS_LOG(1, "dying znode detected = (zp=3D%p)", zp); - first =3D 0; - } - /* - * znode is dying so we can't reuse it, = we must - * wait until destruction is completed. - */ - sa_buf_rele(db, NULL); - mutex_exit(&zp->z_lock); - ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); - if (vp !=3D NULL) - VN_RELE(vp); - tsleep(zp, 0, "zcollide", 1); - goto again; - } - *zpp =3D zp; - err =3D 0; + vp =3D ZTOV(zp); + if (vp =3D=3D NULL) { + zfs_zget_reclaim_pause(zfsvfs, obj_num, db, zp, = vp); + continue; } - sa_buf_rele(db, NULL); - mutex_exit(&zp->z_lock); - ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); - return (err); - } =20 - /* - * Not found create new znode/vnode - * but only if file exists. - * - * There is a small window where zfs_vget() could - * find this object while a file create is still in - * progress. This is checked for in zfs_znode_alloc() - * - * if zfs_znode_alloc() fails it will drop the hold on the - * bonus buffer. - */ - zp =3D zfs_znode_alloc(zfsvfs, db, doi.doi_data_block_size, - doi.doi_bonus_type, NULL); - if (zp =3D=3D NULL) { - err =3D ENOENT; - } else { - *zpp =3D zp; - } - if (err =3D=3D 0) { - vnode_t *vp =3D ZTOV(zp); + VN_HOLD(vp); + if ((vp->v_iflag & VI_DOOMED) !=3D 0) { =20 - err =3D insmntque(vp, zfsvfs->z_vfs); - if (err =3D=3D 0) - VOP_UNLOCK(vp, 0); - else { - zp->z_vnode =3D NULL; - zfs_znode_dmu_fini(zp); - zfs_znode_free(zp); - *zpp =3D NULL; + if ((zp->z_reclaim_td !=3D curthread)) { + zfs_zget_reclaim_pause(zfsvfs, obj_num, = db, + zp, vp); + continue; + } + + /* + * The the thread reclaiming this vnode + * is allowed to use it. + */ + ZNODE_STAT_ADD(zget_reclaim_td_collisions); } + *zpp =3D zp; + err =3D 0; + break; } + sa_buf_rele(db, NULL); + mutex_exit(&zp->z_lock); ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); return (err); } =20= From owner-freebsd-fs@FreeBSD.ORG Sat Sep 29 23:50:21 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C525106566B for ; Sat, 29 Sep 2012 23:50:21 +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 281428FC08 for ; Sat, 29 Sep 2012 23:50:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EACeIZ1CDaFvO/2dsb2JhbABFhgu5MYIgAQEBBAEBASArIAsbDgoCAg0ZAikBCSYGCAcEARwEh2QLp2+SFIEhihiFH4ESA5M8gi2BFY8WgwOBRzQ X-IronPort-AV: E=Sophos;i="4.80,510,1344225600"; d="scan'208";a="181240984" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Sep 2012 19:50:14 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5D6F5B4048; Sat, 29 Sep 2012 19:50:14 -0400 (EDT) Date: Sat, 29 Sep 2012 19:50:14 -0400 (EDT) From: Rick Macklem To: Wayne Hotmail Message-ID: <1363900011.1436778.1348962614353.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.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFS Performance Help 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, 29 Sep 2012 23:50:21 -0000 Wayne Hotmail wrote: > Like others I am having issues getting any decent performance out of > my NFS clients on FreeBSD.I have tried 8.3 and 9.1 beta on stand alone > servers or as vmware clients. Used 1 Gig connections or a 10 Gig > connection.Tried mounting using Version 3 and Version 4.I have tried > the noatime, sync, and tcp options nothing seems to help.I am > connecting to a IceWeb NAS. My performance with DD is 60 meg a second > at best when writing to the server. If I load a Redhat Linux server on > the same hardware using the same connection my write performance is > about 340 Meg a second. > It really falls apart when I run a test script where I create a 100 > folders then create a 100 files in the folders and append to these > files 5 times using 5 random files. I am trying to simulate a IMAP > email server. If I run the script on my local mirror drives it takes > about a one minute and thirty seconds to complete. If I run the script > on the NFS mounted drives it takes hours to complete. With my Linux > install on the same hardware this NFS mounted script takes about 4 > minutes. > Google is tired of me asking the same question over and over. So if > anyone would be so kind as to point out some kernel or system tweaks > to get me passed my NFS issues that would be greatly appreciated. > Wayne > You could try a smaller rsize,wsize by setting the command line args for the mount. In general, larger rsize,wsize should perform better, but if a large write generates a burst of traffic that overloads some part of the network fabric or server, such that packets get dropped, performance will be hit big time. Other than that, if you capture packets and look at them in wireshark, you might be able to spot where packets are getting lost and retransmitted. (If packets are getting dropped, then the fun part is figuring out why and coming up with a workaround.) Hopefully others will have more/better suggestions, rick > > _______________________________________________ > 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"