From owner-freebsd-fs@FreeBSD.ORG Sun May 20 08:10:06 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 051291065676 for ; Sun, 20 May 2012 08:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A8F518FC08 for ; Sun, 20 May 2012 08:10:05 +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 q4K8A4oq087731 for ; Sun, 20 May 2012 08:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4K8A4KP087730; Sun, 20 May 2012 08:10:04 GMT (envelope-from gnats) Date: Sun, 20 May 2012 08:10:04 GMT Message-Id: <201205200810.q4K8A4KP087730@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Birgmeier Cc: Subject: Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly atomic updates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Birgmeier List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 08:10:06 -0000 The following reply was made to PR kern/136865; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org, simon@comsys.ntu-kpi.kiev.ua Cc: Subject: Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly atomic updates Date: Sun, 20 May 2012 10:04:01 +0200 Dear Andrey, It seems that you have done some great work here, and I would really like to see this integrated into the core FreeBSD distribution (I was the submitter of http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/131342). I would like to try out your patches and have two questions: - Do your patches support multiple zfs sharenfs specifications as proposed in http://www.freebsd.org/cgi/query-pr.cgi?pr=147881 (I am using this)? - Could you give a concise list of incompatibilities (and even regressions if they should exist at all) of your solution compared to the standard one? - As to the advantages, I am already convinced. :-) Thank you & regards, Martin From owner-freebsd-fs@FreeBSD.ORG Sun May 20 12:35:12 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85668106564A; Sun, 20 May 2012 12:35:12 +0000 (UTC) (envelope-from gleb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 58AFA8FC0C; Sun, 20 May 2012 12:35:12 +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 q4KCZCqN052248; Sun, 20 May 2012 12:35:12 GMT (envelope-from gleb@freefall.freebsd.org) Received: (from gleb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4KCZCdC052244; Sun, 20 May 2012 12:35:12 GMT (envelope-from gleb) Date: Sun, 20 May 2012 12:35:12 GMT Message-Id: <201205201235.q4KCZCdC052244@freefall.freebsd.org> To: gk@FreeBSD.org, gleb@FreeBSD.org, freebsd-fs@FreeBSD.org From: gleb@FreeBSD.org Cc: Subject: Re: kern/139597: [patch] [tmpfs] tmpfs initializes va_gen but doesn't update it on vnode change 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, 20 May 2012 12:35:12 -0000 Synopsis: [patch] [tmpfs] tmpfs initializes va_gen but doesn't update it on vnode change State-Changed-From-To: open-> State-Changed-By: gleb State-Changed-When: Sun May 20 12:32:55 UTC 2012 State-Changed-Why: Not a bug, only ZFS updates generation number. http://www.freebsd.org/cgi/query-pr.cgi?pr=139597 From owner-freebsd-fs@FreeBSD.ORG Sun May 20 13:27:58 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D09E10657B3; Sun, 20 May 2012 13:27:58 +0000 (UTC) (envelope-from gleb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 70A868FC12; Sun, 20 May 2012 13:27:58 +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 q4KDRwXo098873; Sun, 20 May 2012 13:27:58 GMT (envelope-from gleb@freefall.freebsd.org) Received: (from gleb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4KDRw3g098869; Sun, 20 May 2012 13:27:58 GMT (envelope-from gleb) Date: Sun, 20 May 2012 13:27:58 GMT Message-Id: <201205201327.q4KDRw3g098869@freefall.freebsd.org> To: gk@FreeBSD.org, gleb@FreeBSD.org, freebsd-fs@FreeBSD.org From: gleb@FreeBSD.org Cc: Subject: Re: kern/139597: [patch] [tmpfs] tmpfs initializes va_gen but doesn't update it on vnode change 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, 20 May 2012 13:27:58 -0000 Synopsis: [patch] [tmpfs] tmpfs initializes va_gen but doesn't update it on vnode change State-Changed-From-To: open->closed State-Changed-By: gleb State-Changed-When: Sun May 20 13:27:09 UTC 2012 State-Changed-Why: Not a bug, only ZFS updates generation number. http://www.freebsd.org/cgi/query-pr.cgi?pr=139597 From owner-freebsd-fs@FreeBSD.ORG Mon May 21 03:15: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 BFB9D106566B for ; Mon, 21 May 2012 03:15:48 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE0C8FC08 for ; Mon, 21 May 2012 03:15:47 +0000 (UTC) Received: by ggnm2 with SMTP id m2so4935577ggn.13 for ; Sun, 20 May 2012 20:15:47 -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=GBPVN7MGRR8o8dKbTMS2UgfBgC9Y7Hgyf7ikiYwcysA=; b=e952z+nFlMicH50p+dcvIIvE2s+Kw5ddEOMUFrUu4SJDs0WAJSAg487UOUHbhb3Adk dXndiMcfLwOyG5qFGdym9yHc4BwRAmlf5DWrNTnOhZjLIWlP1ImNxQW6ph5H3F19y/u8 ev1MyDSm85CuuXwMkFWE3frWd0GHdEzKi0v8hHMVEu2fsYCjGF5WaqfpMfZ+hkX/BvVv JJ8avnPcWkuEitiuMNXtbyoXkmUP90/kgGLRLl6MtzwXV56dpG6DN3OM2I/FQ2+WRXsL u5aGkrL/olF4UWVh+7PQA6PGdOk0Z5tC+gY0NnseLsj/m1XJ03d7Ael+4m12E6ebIE4B /0EQ== MIME-Version: 1.0 Received: by 10.50.171.69 with SMTP id as5mr5527869igc.72.1337570146756; Sun, 20 May 2012 20:15:46 -0700 (PDT) Received: by 10.231.31.196 with HTTP; Sun, 20 May 2012 20:15:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 May 2012 11:15:46 +0800 Message-ID: From: Marcelo Araujo To: Trent Nelson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Mirror of Raidz for data reliability 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, 21 May 2012 03:15:48 -0000 2012/5/19 Trent Nelson > Hi Marcelo, > > > >2012/5/17 George Kontostanos > > > > > >Not no.You can use Devd to start some scripts to mount the FS in another > >machine or something like that. > >But I can't be focused only in this scenario, I believe there are much > >more > >application for it. > > I'm in a similar situation with Snakebite. I have two boxes that can see > a common set of disks (via FC SAN). I'm interested in failover, but like > you, I don't want to use HAST -- why duplicate data when both machines can > access the disks? > > I came across these articles yesterday, which are pretty neat: > > CARP and devd on FreeBSD: > http://blather.michaelwlucas.com/archives/224 > Automated CARP/HAST > Failover: http://blather.michaelwlucas.com/archives/241 > > Yeap, you can use CARP + anything else to help you make it work. However in my case, if I have a JBOD fail, I want to be able to import the another JBOD with all data, so in my case I need raidz + vdev(mirror). Currently, I made a patch and now it works pretty well, but I'm doing some more tests to check if I'll face out any problem. Best Regards, -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Mon May 21 03:18:33 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 123F1106564A for ; Mon, 21 May 2012 03:18:33 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BEACF8FC18 for ; Mon, 21 May 2012 03:18:32 +0000 (UTC) Received: by ggnm2 with SMTP id m2so4936518ggn.13 for ; Sun, 20 May 2012 20:18:32 -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=WHIQ3RU7l954YravjkyoWpYuaevDZNEyLzVozZY9kv0=; b=S/tqMq/tLRJrgmJaRLrIVCR+3QpP8jWVBahO314j/TJC1mvfRk3brRNA8z9QBhJ0vl RBDbdq3XUiAT1rPBoF51SRpqxSZxjdhb3Y4czN2mDFXU29lvfkvwI0NTEDrIcjP3AWyT z+6sfcl/CdWwmy12LGDU7VxvGxvilOnqgd1qzmRoac4oyg3zk2LioZll9KKGh2H42Nr7 /yrsHZPotJxQXGtJUTCl1BlFk3HEEibODBEn5h4DlgB0a8HlClyl+o1eWGfcxyCFtf9E cME/fSxJwzH1eM6lp86omoEjfO6eNTBQLsf+FKxc5h3FH0/86lgn2dIkMb57s3xotYCR l1kA== MIME-Version: 1.0 Received: by 10.43.49.3 with SMTP id uy3mr2198919icb.2.1337570312006; Sun, 20 May 2012 20:18:32 -0700 (PDT) Received: by 10.231.31.196 with HTTP; Sun, 20 May 2012 20:18:31 -0700 (PDT) In-Reply-To: <4FB77248.50709@digsys.bg> References: <4FB77248.50709@digsys.bg> Date: Mon, 21 May 2012 11:18:31 +0800 Message-ID: From: Marcelo Araujo To: Daniel Kalchev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Mirror of Raidz for data reliability 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, 21 May 2012 03:18:33 -0000 2012/5/19 Daniel Kalchev > > > On 18.05.12 19:55, Trent Nelson wrote: > >> So, my thinking is=C5=A0 because both machines can see all disks, the ma= ster >> could import the zpool as normal, and the slave could import it read-onl= y. >> (Or not import it at all...) >> > > The proper way of doing it is "not import it at all". ZFS is not an share= d > filesystem. > > If you have the second host mount the zpool even if read-only, you only > guarantee that data on the pool will not be corrupted, but you cannot avo= id > the second "read-only" host panic or otherwise crash if it tries to acces= s > data which is no longer where it thinks it is, because the second host > doesn't have access to the primary host's in-memory metadata about ZFS. > Since ZFS is copy on write filesystem, chances are you will be accessing > data that is no longer valid. Refreshing the internal ZFS state between t= wo > or more hosts is non-trivial (if it was, Sun would have done this, as it > suits their usage) and in any case performance will suffer at least as mu= ch > as an true networked filesystem does, compared to "native" ZFS. > > Yeap, you are right! In my environment I'm not doing ACTIVE-ACTIVE servers, so, one of those controller always will be in stand-by mode. In case someone need to have all data available in both machines at the same time, the best choice right now is use HAST. But my solution is to reach another necessity. Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Mon May 21 08:32:38 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD7381065670; Mon, 21 May 2012 08:32:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 812948FC08; Mon, 21 May 2012 08:32:38 +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 q4L8Wc9d099271; Mon, 21 May 2012 08:32:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4L8WcUP099265; Mon, 21 May 2012 08:32:38 GMT (envelope-from linimon) Date: Mon, 21 May 2012 08:32:38 GMT Message-Id: <201205210832.q4L8WcUP099265@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/168158: [zfs] incorrect parsing of sharenfs options in zfs (fsshare.c) 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, 21 May 2012 08:32:38 -0000 Old Synopsis: incorrect parsing of sharenfs options in zfs (fsshare.c) New Synopsis: [zfs] incorrect parsing of sharenfs options in zfs (fsshare.c) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 21 08:32:13 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=168158 From owner-freebsd-fs@FreeBSD.ORG Mon May 21 11:07:12 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1EA2106564A for ; Mon, 21 May 2012 11:07:12 +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 8A08C8FC15 for ; Mon, 21 May 2012 11:07:12 +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 q4LB7CDu049084 for ; Mon, 21 May 2012 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4LB7BpD049082 for freebsd-fs@FreeBSD.org; Mon, 21 May 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 May 2012 11:07:11 GMT Message-Id: <201205211107.q4LB7BpD049082@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, 21 May 2012 11:07:12 -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/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/167905 fs [zfs] zfs set canmount=on UNMOUNTS dataset 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/167266 fs [zfs] [nfs] ZFS + new NFS export (sharenfs) leads to N 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/166566 fs [zfs] zfs split renders 2 disk (MBR based) mirror unbo o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/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 o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161511 fs [unionfs] Filesystem deadlocks when using multiple uni o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/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 kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o 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 278 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon May 21 21:37: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 8E71B1065673; Mon, 21 May 2012 21:37:07 +0000 (UTC) (envelope-from freebsd@knarf.de) Received: from mail.server-king.de (mail.server-king.de [IPv6:2a01:4f8:100:41a2::25]) by mx1.freebsd.org (Postfix) with ESMTP id D91DA8FC15; Mon, 21 May 2012 21:37:06 +0000 (UTC) Received: from cheese.server-king.de (localhost [127.0.0.1]) by mail.server-king.de (8.14.5/8.14.5) with ESMTP id q4LLagFw068999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 May 2012 23:36:42 +0200 (CEST) (envelope-from freebsd@knarf.de) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=knarf.de; s=mail.server-king.de; t=1337636203; bh=/+eu2Z55ZZgdC09G+9mcOGRmsYNwR3f37KhRwrwQhjc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=mtgTqlDygyMd0qj4X++go0YQGQQ40+9UfLKaWpsOJCxWDIYdWN8ay5DjXhvUmiRxp b44+6eoE3LEQgNiTa9nruqDYs5VXQKlEN3FRtsuhAIAopl3+H5e9/5mnkl7xazktvz skNr3y+kF30L1KyHNrYDxm8sJ3Gc9Z2VM28Ggyjs= Received: (from knarf@localhost) by cheese.server-king.de (8.14.5/8.14.5/Submit) id q4LLaeEH068875; Mon, 21 May 2012 23:36:40 +0200 (CEST) (envelope-from freebsd@knarf.de) X-Authentication-Warning: cheese.server-king.de: knarf set sender to freebsd@knarf.de using -f Date: Mon, 21 May 2012 23:36:40 +0200 From: Frank Bartels To: freebsd-fs@freebsd.org Message-ID: <20120521213640.GC69425@server-king.de> References: <39C592E81AEC0B418EAD826FC1BBB09B25253F@mailgate> <4F1878AC.6060704@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25284B@mailgate> <4F1AC995.7050506@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> <4F1D75CD.6050000@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25607F@mailgate> <4F1DC398.3050502@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25CF08@mailgate> <20120518175225.GA4735@server-king.de> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline In-Reply-To: <20120518175225.GA4735@server-king.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mail.server-king.de [127.0.0.1]); Mon, 21 May 2012 23:36:43 +0200 (CEST) Cc: Martin Ranne , 'Andriy Gapon' Subject: Re: zpool import reboots computer 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, 21 May 2012 21:37:07 -0000 --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi freebsd-fs, my zpool is still not importable. :( I've got some tips during the last days, but none of them changed the error messages below in the second "screenshot". The zdb -lu output is in sync for all disks. I've replaced the boot mirror (FreeBSD 8.3-RELEASE-p1, gptzfsboot) with a plain FreeBSD 9.0-STABLE (gptboot, single disk, / on ufs) with the patched vdev_mirror.c and finally managed to get a crashdump while trying to import the zpool zdata using "zpool import -f -R /angus.zdata -d /dev/gpt zdata": https://www.server-king.de/download/zfs-crash-debug/backtrace.zdata.crash.t= xt The patch I've used is here: https://www.server-king.de/download/zfs-crash-debug/vdev_mirror.c.patch.txt Otherwise it would crash before the same way as with plain RELENG_8_3. Do you need any more information? Thanks for any help, Knarf P.S.: The latest changes seen in http://www.freebsd.org/cgi/cvsweb.cgi/src/cddl/contrib/opensolaris/lib/libz= fs/common/libzfs_dataset.c (SVN rev 235702) do not seem to be related with my problem, but I'll do a make world right now. On Fri, May 18, 2012 at 19:52:25 +0200, Frank Bartels wrote: > Hi freebsd-fs, >=20 > I have a similar problem like Martin. >=20 > It started a while ago with a broken zfs, I was no longer able to > delete some files on /home/ncvs: >=20 > Checking setuid files and devices: > find: /home/ncvs/del/efax/Attic/pkg-comment,v: Bad file descriptor > find: /home/ncvs/del/libsyncml/files: No such file or directory >=20 > Two days ago the machine started rebooting every two hours, directly > after syncing my local cvsup-server. >=20 > So I renamed the zfs /home/ncvs to /home/ncvs.del and tried to > destroy it including its snapshots. The machine crashed again and > now I'm unable to import the pool. >=20 > First I've seen this backtrace: >=20 > https://www.server-king.de/download/DSC02742.medium.JPG >=20 > Then I've added the three blocks above to vdev_mirror.c. It still > crashes, but the backtrace has changed: >=20 > https://www.server-king.de/download/DSC02744.medium.JPG >=20 > ... > calltrap > zio_checksum_verify > zio_execute > arc_read_nolock > arc_read > ... >=20 > This is FreeBSD 8.3-RELEASE-p1 amd64 on a Xeon X5650 with 24 GByte > RAM and 12 hard disks and 2 SSDs. >=20 > This is what I see with zpool import -d /dev/gpt >=20 > pool: zdata > id: 18141461787395278116 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: >=20 > zdata ONLINE > raidz2-0 ONLINE > gpt/zdata1.eli ONLINE > gpt/zdata0.eli ONLINE > gpt/zdata2.eli ONLINE > gpt/zdata3.eli ONLINE > gpt/zdata5.eli ONLINE > gpt/zdata4.eli ONLINE > gpt/zdata6.eli ONLINE > gpt/zdata8.eli ONLINE > gpt/zdata9.eli ONLINE > cache > gpt/zcache0.eli > gpt/zcache1.eli > spares > gpt/zdata7.eli > logs > mirror-1 ONLINE > gpt/zlog0.eli ONLINE > gpt/zlog1.eli ONLINE >=20 > I have no idea why I don't see zcaches and zdata7 as ONLINE. >=20 > If I use zpool import (without -d) I see dsk/gpt instead of gpt/ > on these three disks: >=20 > cache > dsk/gpt/zcache0.eli > dsk/gpt/zcache1.eli > spares > dsk/gpt/zdata7.eli >=20 > Do you have any idea what I can do? I've tried 9.0-RELEASE (LiveCD) > without success. Do you think using 8.3-STABLE or 9.0-STABLE could > cure my problem? >=20 > Thanks, > Knarf >=20 > On Wed, Jan 25, 2012 at 16:10:19 +0000, Martin Ranne wrote: > > Thank you everyone who have helped me with hacking zfs. We have now bee= n able to do an import of the pool and transfered all the data to another c= omputer. Next step is to see if we can quickly repair the pool or just dele= te it and make it new again. > > > > We hacked the functions vdev_mirror_child_select() and vdev_mirror_io_s= tart(). In vdev_mirror_io_start() we added the code below just after the mc= pointer was set in both loops. > > > > if (mc->mc_vd =3D=3D NULL) { > > (void) printf("mc->mc_vd is NULL. Child %i\n", c); > > continue; > > } > > > > In vdev_mirror_child_select(), we added the code below just after the m= c pointer was set. > > > > if (mc->mc_vd =3D=3D NULL) { > > (void) printf("mc->mc_vd is NULL. Child %i\n", c); > > mc->mc_tried =3D 1; > > mc->mc_skipped =3D 1; > > continue; > > } > > > > > > Best regards, > > > > Martin Ranne > > > > >On 2012-01-23 21:31, Andriy Gapon wrote: > > >>on 23/01/2012 20:33 Martin Ranne said the following: > > >>Have done some checking and found mc->mc_vd =3D=3D NULL in the functi= on vdev_mirror_io_start() where the while-loop is. > > >> > > >>while (children--) { > > >> mc =3D &mm->mm_child[c]; > > >> zio_nowait(zio_vdev_child_io(zio, zio->io_bp, > > >> mc->mc_vd, mc->mc_offset, zio->io_data, zio->io_size, > > >> zio->io_type, zio->io_priority, 0, > > >> vdev_mirror_child_done, mc)); > > >> c++; > > >>} > > >> > > >>if i set a break before it runs zio_nowait() it will still crash the = kernel. > > >>What can i check next for it to be able to continue? Is it possible t= o have it ignore the child where mc_vd is NULL? I am also looking into what= more I can do to debug it (adding code to print to console as i can not us= e kernel dumps). > > >> > > >Not sure. If by "set a break" you mean inserting a break statement, t= ry > > >continue instead. > > > > > > > _______________________________________________ > > 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" --9Ek0hoCL9XbhcSqy Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQkgYJKoZIhvcNAQcCoIIQgzCCEH8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DcQwggY0MIIEHKADAgECAgEgMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAyNTVaFw0xNzEwMjQyMTAyNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDLKIVFnAEs+xny q6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQA7Xj9AGM6wgP hEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQgKO19b+R t8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj113yK Mm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLsw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQA6qScNyNO0FpHvaZTQacVMXH33O51KyEKSRw3IvdQxRu31YR0ZDGdSfgSoOVDVMSBSdmfQ fdDInHPzV3LO5DwUXZ+lxjv7z3PO2OkfnFkvTXPfn6dxJ5rJveDsTsCPcJ/Kp6/+qN5g+J6D /SaYcFD018B6L42r0Z4VEBy36P4tjRtF14Ex10tl5tJFVKM16qWKQHbpjIgf73s49UB0CQ5l HT2DHKfq3oPfdNc5Mk93w1v4ryVb+qVrZIej8NsrWU+5r4O2IV91edDb/OtHFddZqHFFXKgS 79IHE/hwQ2LW7r3sTX7cDUCg+dfdwO8zeLxuwk2JF8crUoyrl66RGrRIhT8VoG/OJ1Y9uUlO av69V4cG8upi4ZG2l7JZFbcBFk91Wp+Payo5SuF61CmGFrZ386umkmpObtFacXda2O/bVoQ9 xHQrzoTc/0KZTWvlZCLK3Ke/vGYT9ZdW9lOjGsSFbXrlTA919L84iMK+48WGnvRWY28ZaVHp ql43AtEGhXze6iNCbEDACy+4hkQYOytAqDgcxAnQ937mYpeZFPyz/XK9QSt9VNFMuudWxZwD DDJKoQAoSG59Hou9lZ26UrK60nRdAQBmEPL8h2nuWgoPh++XVQld9yuhbsWa39Pck8/lcfz5 HUVGJF5mc/zk38iV7FDlF68puiryNq2KXHEpOTCCB4gwggZwoAMCAQICAhnSMA0GCSqGSIb3 DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTExMjA3MDg0 MjU3WhcNMTMxMjA3MTgwNTMxWjCBjzEgMB4GA1UEDRMXNTg1MzA2LXQ2SXE3M3MwMDFWQTlV M3ExCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCYXllcm4xETAPBgNVBAcTCE11ZW5jaGVuMRYw FAYDVQQDEw1GcmFuayBCYXJ0ZWxzMSIwIAYJKoZIhvcNAQkBFhNrbmFyZkBjYW1lbG90LWVr LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8N5hhEgqWbS/FRuLFDLqAVvV +y0aDtXj5D5p8hkNNm4jgukL8DoqRLG3lc/tP5wZQHfKLXSwHdujwH8xu4Vl3tNIr1OagZnT Vcf7qWlv9+EFoIf5wql3zveLKTLA49mSqI7MJN3mWNwSxDeUXXYGrUvqnoF0X5ihg0zRfmpz xb1nSU9l9X29ONJh9IyoXucG/6eRLyjUu6QAtGRNe7rZJAyt/fnYvCqgeqUOfNLl5BDCCdpM FNqy5EH1B9NJYe74TGV87+woiZf+Tp47Nkle5aUG0Tp81Zak3MS1qW8Q4Uk8jSELLMCfvIv+ MFPrW3e6qkJGsAO+xK26GlmCj+kJfQIDAQABo4ID7TCCA+kwCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRtarO3vRru MRytTmEChbqEJq191jAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzBdBgNVHREE VjBUgRNrbmFyZkBjYW1lbG90LWVrLmRlgRNrbmFyZkBjYW1lbG90LWVrLmRlgQ5rbmFyZkBr bmFyZi5kZYEYZi5iYXJ0ZWxzQGhhcHB5LXBpeGVsLmRlMIICIQYDVR0gBIICGDCCAhQwggIQ BgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVy bWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5n IHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENv bSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEF BQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFi aWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0w K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh c3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAnfH80+NVJo1IwpzN1F2iQjiEKTj828LG a9petNHG2ivFylhzZlN6N93ioZmJvsUBe5KviJ2Pr4EyalHj+1MfCh475YI+vv0owqMGFEjC evcOOmgnNdugfQ4eVEoRshaRdYyOvftG8K9RTGoHrnk1De9QJMAKvEZa8Rx1/4mb3VC+pSnl ny2EdkEU0sJ30U6xXs+Z/JbVZJZyUMm2uDerF4lEykWuJL6vuBKuL/HZnIHWs5Nmd8ikVdlZ PBY/ul1fFbe3ertA4Z9i5aswdWiDbHCGUuEtZuMtjZfR9xFnTMwebTMuzlWv4ccRJWjF34pc cppyA3yda5I6y+dtUmszMDGCApYwggKSAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0ECAhnSMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTIxMjEzNjQwWjAjBgkqhkiG9w0BCQQxFgQUDNyNBCHv PeqRe6oebFTm0q/jZ0gweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAUGWhIcs/ fSABany7JiVlyC0B+/REvdb13cA53V6CREGA9fuRaqA8HcaqvL8fABUK7QGgCMi+1j4meY4m HJtBT8UW8/KQOv6viNpylKtFn52Ul2Ax223FxQF1OlmzTAHXc2WVW2BPJ/hKgLOj0T8ScxOz u1jlX6TyuYOvw5dSbXmKfioSudVNXpUb897Iknrf12VUfOAaXowd8aoDCT15Gn7/PMG1HC6x rWADVdFK+9fcDx4qqK4FoNfw81XwooAT8BP1dBTyK0p1hAo4B9misado9K3x4KjMtfFBAY97 GgsFnNvQUev0p+EaJ6FkbnFuGXlE4xm9SuOwrMXR7/TMyg== --9Ek0hoCL9XbhcSqy-- From owner-freebsd-fs@FreeBSD.ORG Tue May 22 08:05: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 9724A106566B for ; Tue, 22 May 2012 08:05:23 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6B398FC14 for ; Tue, 22 May 2012 08:04:59 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SWk5N-0005oB-6b; Tue, 22 May 2012 11:04:53 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 979821CC21; Tue, 22 May 2012 11:04:56 +0300 (EEST) Date: Tue, 22 May 2012 11:04:56 +0300 From: Andrey Simonenko To: Martin Birgmeier Message-ID: <20120522080456.GA40365@pm513-1.comsys.ntu-kpi.kiev.ua> References: <201205200810.q4K8A4KP087730@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205200810.q4K8A4KP087730@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-05-22 11:04:53 X-Connected-IP: 10.18.52.101:64609 X-Message-Linecount: 88 X-Body-Linecount: 72 X-Message-Size: 3530 X-Body-Size: 2825 Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly atomic updates 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, 22 May 2012 08:05:23 -0000 Hello, On Sun, May 20, 2012 at 08:10:04AM +0000, Martin Birgmeier wrote: > The following reply was made to PR kern/136865; it has been noted by GNATS. > > From: Martin Birgmeier > To: bug-followup@FreeBSD.org, simon@comsys.ntu-kpi.kiev.ua > Cc: > Subject: Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly > atomic updates > Date: Sun, 20 May 2012 10:04:01 +0200 > > Dear Andrey, > > It seems that you have done some great work here, and I would really > like to see this integrated into the core FreeBSD distribution (I was > the submitter of http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/131342). > > I would like to try out your patches and have two questions: > > - Do your patches support multiple zfs sharenfs specifications as > proposed in http://www.freebsd.org/cgi/query-pr.cgi?pr=147881 (I am > using this)? The exports(5) manual page says that address specifications must be specified after options. The nfs.exports(5) file format allows to use options after address specifications, so they can overwrite previously specified options. It is possible to specify all settings for one file system in one line, no ';' like separators are required. For example line: /fs -ro -sec krb5 1.1.1.1 -nfsv4 no -rw 2.2.2.2 -sec sys -nfsv4 yes 3.3.3.3 will be translated to ("nfse -t ..." output): Pathname /fs Export specifications: -rw -sec sys -maproot=-2:-2 -host 3.3.3.3 -rw -sec krb5 -maproot=-2:-2 -nfsv4 no -host 2.2.2.2 -ro -sec krb5 -maproot=-2:-2 -host 1.1.1.1 > > - Could you give a concise list of incompatibilities (and even > regressions if they should exist at all) of your solution compared to > the standard one? - As to the advantages, I am already convinced. :-) In short: if nfse is run in compatible mode with mountd ("nfse -C ..."), then it is more compatible with exports(5) than mountd is. If one did not follow rules of exports(5), then "nfse -C ..." can be incompatible with mountd. If nfse is run in native nfs.export(5) configuration file format mode, then logic of configuration looks like exports(5), but differs in some places. So, when we speak about "incompatibilities" then it is necessary to distinguish incompatibilities of "nfse native mode" vs mountd and incompatibilities of "nfse compatible mode" vs mountd. I suggest to check whether "nfse -C ..." is compatible with mountd using instructions described here: http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html You do not need to install anything or modify existent system for testing. Can you try "nfse -Ct ..." and tell me whether "nfse -C ..." is compatible enough with mountd (try correct configurations and configurations with mistakes). I have list of difference somewhere, I'll try to find it. From owner-freebsd-fs@FreeBSD.ORG Tue May 22 18:35: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 DC0D8106564A for ; Tue, 22 May 2012 18:35:06 +0000 (UTC) (envelope-from bsalinux@gmail.com) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id 973648FC17 for ; Tue, 22 May 2012 18:35:06 +0000 (UTC) Received: by qabj40 with SMTP id j40so3364390qab.15 for ; Tue, 22 May 2012 11:35:06 -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=xcT69ZqehcBFmJbRWsf2zy3hslrMl3Kf59Bxfhlt6WI=; b=Se6MZ/exLx2KQxT3KzD/tS+dUCVIg7vJPzOYRhDYXNlO0AqfEGD0kok9rnPQLPsUc3 jYwPwo4R6dIzS5haztEPCMw+nJRN4hFDGIj7RkNLwDooajRgrk0wa4ktWcaPLeVQN+b/ wOs55yIShHX0S35URboZFNw/herbaNqYd5FMHtGGtPRVDDS/g8WyXjc+SUyB31OSBVwS n+5z7ShCLoj4RUrDd+eFsSXFK/pAv2a8LXutiOK5hIQdVeDSpcKqkJ835+WmTJGCtA4e F2/AiTexNvjYwE71CPdIDjGZmMFta8ran3nvTxfqoG0Dob0o1ginVw1ZpM/BWLSCSumE 2syg== MIME-Version: 1.0 Received: by 10.229.111.229 with SMTP id t37mr12600160qcp.143.1337711705844; Tue, 22 May 2012 11:35:05 -0700 (PDT) Received: by 10.229.22.130 with HTTP; Tue, 22 May 2012 11:35:05 -0700 (PDT) Date: Tue, 22 May 2012 11:35:05 -0700 Message-ID: From: "bsalinux@gmail.com" To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: NFS Server Limiting open port RST response 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, 22 May 2012 18:35:06 -0000 Hi, I have a FreeBSD + ZFS server configured as NFS server. This server is being used to store regressions that are generated over a period of 2-3 days. Time to time nfs would drop the mount and the program fails to find the output directory (nfs automount). On the other hand if I use Linux NFS server to host this space, I see no issues. Time to time I see messages like these in the logs: Limiting open port RST response from 334 to 200 packets/sec It seems that the automount dismounts the server while the regressions are being computed and the output is idle. I even kept one terminal window open on the compute server that is "cd" into the output directory so that it prevents the dismounting the automount but it still fails. Do I need to tweak any parameters? Can I stop dismounting (from NFS server side)? Any help would be appreciated. Thanks. From owner-freebsd-fs@FreeBSD.ORG Tue May 22 19:26: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 F1736106564A for ; Tue, 22 May 2012 19:26:24 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6BAB18FC15 for ; Tue, 22 May 2012 19:26:24 +0000 (UTC) Received: by laai10 with SMTP id i10so6627925laa.13 for ; Tue, 22 May 2012 12:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=om3jmT0Tqjutm1SIuzSrmp3+6Hj+TqgVMkZdFjZC/iE=; b=lPzndbTLcnW90T48Dw2/wl1CQKpmsNIMI2SsZsNNLBXhn3yeXQzxPTmSZgorGy+hin ieYp9+nsylhNiEs5bMBn7WPtAf2rxbfBW0nj28k1de9B9q+XQ2mPVwohD5yKS6w1Y1cI 86AHsHYYze97f8OxuvNODLTIfGBpWDLbWMJxNMf5zMLuFOKM2zHGD/tivjyyctY/jibm aKVOnUGSPphCeuK2OQJk6hPkxBDHi1IXRGWFEgx4Z+Iy9GOg+21zprtRKPSdfHHr4PNY oOm1O4YT39WmJ2TtsyemhRf3gJxsjig6IvcjGVbhRTs6Jjv5NRLudCznWoht8XYZERro 8Ftg== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr10775689lbo.35.1337714783140; Tue, 22 May 2012 12:26:23 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.112.130.4 with HTTP; Tue, 22 May 2012 12:26:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 12:26:23 -0700 X-Google-Sender-Auth: rgUL6NZcH38rkI08ujx0TaFwwro Message-ID: From: Artem Belevich To: "bsalinux@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: NFS Server Limiting open port RST response 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, 22 May 2012 19:26:25 -0000 On Tue, May 22, 2012 at 11:35 AM, bsalinux@gmail.com wrote: > Hi, > > I have a FreeBSD + ZFS server configured as NFS server. This server is > being used to store regressions that are generated over a period of > 2-3 days. Time to time nfs would drop the mount and the program fails > to find the output directory (nfs automount). On the other hand if I > use Linux NFS server to host this space, I see no issues. > > Time to time I see messages like these in the logs: > > Limiting open port RST response from 334 to 200 packets/sec Which FreeBSD version are you using? This problem sounds rather similar to what I've fixed last fall in head@225234, stable/8@225384 --Artem From owner-freebsd-fs@FreeBSD.ORG Tue May 22 21:16: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 209951065670; Tue, 22 May 2012 21:16:31 +0000 (UTC) (envelope-from bsalinux@gmail.com) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id B7A0A8FC12; Tue, 22 May 2012 21:16:30 +0000 (UTC) Received: by qabj40 with SMTP id j40so3497823qab.15 for ; Tue, 22 May 2012 14:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3C67nBGnjugHNKyZajxK7eygv4JGG2uDpUCOlnZIplI=; b=1E7v4WH9gW7zv4XAdZcOzMLZpYySFOt14hHxFR2inooo9NgdFZx4EpjHsAveVUNOAL R50Xb9J9DTDpEbL3qj1nVH7s8/7aSojNBBEUtuu93jmbmF9VNvDdp/i5TMlLiHS3rSvr dLs4NaM6xoINu8XJ120mI1Qb8pVc+vkKLTt9V4Qb/Y9DiR9MR+2dcS7HIgaUnX8sM/IK SDId/i89y/3h7u0+fVk5RFyh8qit4KGva8y1ISc5YNT3rBFIUi+bx7D26vnZGXf9iscf 5bI6pIf+zxLjf+vtOR43/5s6bdq7g35ChMPrwo0HnQ4fskq6X/WNfSq2LgmQV1ocRofS ySXw== MIME-Version: 1.0 Received: by 10.224.33.8 with SMTP id f8mr1835780qad.11.1337721389865; Tue, 22 May 2012 14:16:29 -0700 (PDT) Received: by 10.229.22.130 with HTTP; Tue, 22 May 2012 14:16:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 14:16:29 -0700 Message-ID: From: "bsalinux@gmail.com" To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: NFS Server Limiting open port RST response 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, 22 May 2012 21:16:31 -0000 Hi, I'm using "9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012" Thanks, On Tue, May 22, 2012 at 12:26 PM, Artem Belevich wrote: > > Which FreeBSD version are you using? This problem sounds rather > similar to what I've fixed last fall in head@225234, stable/8@225384 > > --Artem From owner-freebsd-fs@FreeBSD.ORG Tue May 22 22:42:22 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 C66AC106564A for ; Tue, 22 May 2012 22:42:22 +0000 (UTC) (envelope-from artemb@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 3D2478FC12 for ; Tue, 22 May 2012 22:42:22 +0000 (UTC) Received: by lbon10 with SMTP id n10so6736927lbo.13 for ; Tue, 22 May 2012 15:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=16BI4AeuD6YFsJB+HhcICbC8tCGMobkc+U/fuEwBJ3I=; b=eEmx6j407S0FuY3K0GHbwUI7/s93PlhXqkkY+IpUdQtIcfEBYheGcOCzVM1UtIx0SX I1pLkgC6u208rXVaX1IeJZzTURaMSmiZaEdEWsholjC8UwyrQhCd+PVaqQWravOLw0GK UrARRoukku1F8BjcwsZUMaWLPwmLERerv/Js+vHTLWsM7tzQDPBGe8I85y+uEIMvhECg +Ewk46BoZ15OsGMGeKbLFnaUkcj/dqMjgU4wCQ5BGhl4/8YS4QgVPbFABAmBl1HjpjOx urPTnM3agYE3xCAVFhexoJmO4w0kNIhEAgDN/lxC/korbFVT9zyOvJZHRKpxqWa5QPZQ W4bQ== MIME-Version: 1.0 Received: by 10.152.111.200 with SMTP id ik8mr24637230lab.15.1337726540791; Tue, 22 May 2012 15:42:20 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.112.130.4 with HTTP; Tue, 22 May 2012 15:42:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 15:42:20 -0700 X-Google-Sender-Auth: V3gpfE8XiDoYGjEpAbLpRBLryY8 Message-ID: From: Artem Belevich To: "bsalinux@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: NFS Server Limiting open port RST response 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, 22 May 2012 22:42:22 -0000 On Tue, May 22, 2012 at 2:16 PM, bsalinux@gmail.com wr= ote: > Hi, > > I'm using "9.0-RELEASE #0: Tue Jan =A03 07:46:30 UTC 2012" Looks like your issue is not the same after all. The fix for the issue I had in mind is in 9.0 since BETA2. --Artem. > > Thanks, > > On Tue, May 22, 2012 at 12:26 PM, Artem Belevich wrote: >> >> Which FreeBSD version are you using? This problem sounds rather >> similar to what I've fixed last fall in head@225234, stable/8@225384 >> >> --Artem From owner-freebsd-fs@FreeBSD.ORG Thu May 24 11:47: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 AAA731065891 for ; Thu, 24 May 2012 11:47:04 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4508FC19 for ; Thu, 24 May 2012 11:47:04 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SXWVS-0000zB-Ng for freebsd-fs@freebsd.org; Thu, 24 May 2012 14:47:02 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 38D2A1CC34; Thu, 24 May 2012 14:47:03 +0300 (EEST) Date: Thu, 24 May 2012 14:47:02 +0300 From: Andrey Simonenko To: freebsd-fs@freebsd.org Message-ID: <20120524114702.GA38087@pm513-1.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-05-24 14:47:02 X-Connected-IP: 10.18.52.101:42209 X-Message-Linecount: 30 X-Body-Linecount: 18 X-Message-Size: 1246 X-Body-Size: 745 Subject: NLM uses AUTH_SYS ignoring sec option in mount_nfs 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, 24 May 2012 11:47:04 -0000 Hello, Looks like that NLM always uses AUTH_SYS even if a client specified another security flavor in the mount_nfs's "sec" option. Also NLM on the server does not verify that NLM client's security flavor is allowed by NFS exported file system, security flavors array from VFS_CHECKEXP() is ignored in nlm/nlm_prot_impl.c:nlm_get_vfs_state(). Such behaviour of NLM I see on 10-CURRENT, I added log messages to the kernel to see security flavors used by NFSv3 and NLM requests. Both NFS client and server are on the same system, NFSv3 mounts are from unprivileged users. According to [1] NLMv4 allows to use different security flavors. Can somebody comment such behaviour of NLM? [1] http://pubs.opengroup.org/onlinepubs/9629799/chap14.htm From owner-freebsd-fs@FreeBSD.ORG Thu May 24 13:40:04 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0082E106566C for ; Thu, 24 May 2012 13:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DE0428FC08 for ; Thu, 24 May 2012 13:40:03 +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 q4ODe34g065024 for ; Thu, 24 May 2012 13:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4ODe3TJ065023; Thu, 24 May 2012 13:40:03 GMT (envelope-from gnats) Date: Thu, 24 May 2012 13:40:03 GMT Message-Id: <201205241340.q4ODe3TJ065023@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: =?utf-8?Q?"Germ=C3=A1n_M._Bravo"?= Cc: Subject: Re: kern/161511: [unionfs] Filesystem deadlocks when using multiple unionfs mounts on top of single filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "=?utf-8?Q? Germ=C3=A1n_M._Bravo ?=" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:40:04 -0000 The following reply was made to PR kern/161511; it has been noted by GNATS. From: =?utf-8?Q?"Germ=C3=A1n_M._Bravo"?= To: "bug-followup@FreeBSD.org" , "gcooper@ixsystems.com" Cc: Subject: Re: kern/161511: [unionfs] Filesystem deadlocks when using multiple unionfs mounts on top of single filesystem Date: Thu, 24 May 2012 08:34:25 -0500 I can verify this patch absolutely fixes all the issues I was experiencing. M= y problem was random deadlocking behavior, forcing me to reboot the system m= anually, when I started/stopped jails using unionfs and/or starting services= inside said jails, under FreeBSD 9 RELEASE.= From owner-freebsd-fs@FreeBSD.ORG Fri May 25 05:40:21 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C63D6106566C; Fri, 25 May 2012 05:40:21 +0000 (UTC) (envelope-from daichi@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 98EBA8FC0C; Fri, 25 May 2012 05:40: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 q4P5eL3f094159; Fri, 25 May 2012 05:40:21 GMT (envelope-from daichi@freefall.freebsd.org) Received: (from daichi@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4P5eLrL094148; Fri, 25 May 2012 05:40:21 GMT (envelope-from daichi) Date: Fri, 25 May 2012 05:40:21 GMT Message-Id: <201205250540.q4P5eLrL094148@freefall.freebsd.org> To: gcooper@ixsystems.com, daichi@FreeBSD.org, freebsd-fs@FreeBSD.org From: daichi@FreeBSD.org Cc: Subject: Re: kern/161511: [unionfs] Filesystem deadlocks when using multiple unionfs mounts on top of single filesystem 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, 25 May 2012 05:40:21 -0000 Synopsis: [unionfs] Filesystem deadlocks when using multiple unionfs mounts on top of single filesystem State-Changed-From-To: open->closed State-Changed-By: daichi State-Changed-When: Fri May 25 05:39:59 UTC 2012 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=161511 From owner-freebsd-fs@FreeBSD.ORG Fri May 25 13:24: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 BB8F91065670 for ; Fri, 25 May 2012 13:24:19 +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 858F18FC19 for ; Fri, 25 May 2012 13:24:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:From:Mime-Version:Subject:Date:To:Content-Type; bh=fq/+7hwgJBa+J+xmGHdJqOHgJT++g8MPL8t5QrAq1tM=; b=kziFl88JxizE07TX8K4uOnbU/+Wj9uFLuYoAHRHVmta/XQvPSSU3PhyGuR3+k1aU/U5sUJ+eYI4Cv4l7N/JcDjfFCpMKgqmJ4rbZtzQ/ryhqXYzt9Dy12yOdGT+EzMhy; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXuV8-000Ma3-Dr for freebsd-fs@freebsd.org; Fri, 25 May 2012 08:24:19 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1337952252-3288-3287/5/26; Fri, 25 May 2012 13:24:12 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Date: Fri, 25 May 2012 08:24:11 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: User-Agent: Opera Mail/11.64 (FreeBSD) X-SA-Score: -1.0 Subject: UFS SUJ and fsck questions 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, 25 May 2012 13:24:19 -0000 Hi guys, I'm building out a highly available storage backend with HAST+NFS on UFS. So far I've encountered a node going down and the filesystem being dirty, so the other side won't mount it automatically. I've resolved this issue with the following before the mount: fsck -C -t ufs -y /dev/hast/${disk} However, the problem is that on a disk nearly 1TB in size it will take a long time to fsck and the failover won't be as smooth. SUJ would fit the bill here pretty well. My main issue is not understanding the interaction between SUJ and fsck. If I simply try to mount a fs with SUJ, it will do the SUJ magic if necessary and move on. But what if it's damaged beyond what SUJ can handle and needs a real fsck? Can I use the same procedure? Will executing `fsck -C` against an SUJ enabled filesystem that hasn't run the SUJ journal yet do that first and exit if the journal replay was successful? If not, does anyone have any ideas on how I can detect that automatically so I can get the filesystem mounted cleanly without human intervention? Thanks! From owner-freebsd-fs@FreeBSD.ORG Fri May 25 13:38: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 481D81065794; Fri, 25 May 2012 13:38:07 +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 D6B0F8FC08; Fri, 25 May 2012 13:38:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJ+Kv0+DaFvO/2dsb2JhbABFhTSwdoIVAQEBBAEBASArIAsbDgoCAg0ZAikBCSYGCAcEARwEh2wLqFiSVoEkiXcKhBCBEgOSc4IlgQ+ID4ZSgnyBQw X-IronPort-AV: E=Sophos;i="4.75,657,1330923600"; d="scan'208";a="173229434" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 25 May 2012 09:36:58 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5A7CBB4038; Fri, 25 May 2012 09:36:58 -0400 (EDT) Date: Fri, 25 May 2012 09:36:58 -0400 (EDT) From: Rick Macklem To: Andrey Simonenko Message-ID: <169170676.853090.1337953018295.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120524114702.GA38087@pm513-1.comsys.ntu-kpi.kiev.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 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, dfr Subject: Re: NLM uses AUTH_SYS ignoring sec option in mount_nfs 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, 25 May 2012 13:38:07 -0000 Andrey Simonenko wrote: > Hello, > > Looks like that NLM always uses AUTH_SYS even if a client specified > another security flavor in the mount_nfs's "sec" option. Also NLM > on the server does not verify that NLM client's security flavor > is allowed by NFS exported file system, security flavors array from > VFS_CHECKEXP() is ignored in nlm/nlm_prot_impl.c:nlm_get_vfs_state(). > > Such behaviour of NLM I see on 10-CURRENT, I added log messages to > the kernel to see security flavors used by NFSv3 and NLM requests. > Both NFS client and server are on the same system, NFSv3 mounts are > from unprivileged users. > > According to [1] NLMv4 allows to use different security flavors. > > Can somebody comment such behaviour of NLM? > Well, as you might know, I wasn't the author of the NLM implementation, so I'm just commenting based on what little I know about it. (I've added dfr@ to the cc list, in case he can provide more insight?) I think the big problem with using Kerberos with the NLM is "what happens when the user's TGT ticket expires on the client?". If this happens and the server requires a valid credential based on a Kerberos ticket, then the client/user won't be able to unlock the locks that have been put on the file. It is conceivable that these file locks could hang around "forever". (An obvious case here is where the user for a uid isn't actually prsent to do a fresh kinit when the TGT expires. Another is an application program that doesn't handle a EACCES error from a lock syscall well.) I think this problem could be avoided by allowing AUTH_SYS for unlock operations, so that the unlocking won't fail. Also, from a glance at the code, it appears that the client will re-acquire locks after a server crashes/reboots. What do you do if this re-acquisition fails, due to a TGT timeout? NFSv4 works around the above issues by using a "host based initiator credential in a keytab file" for system stuff like lock recovery. (The FreeBSD client will fall back to using this "system credential" for LockU operations, if the user's credential fails, but I don't know if all clients choose to do this? Grep in the client sources for ND_USEGSSNAME to see this being used.) Unfortunately, the patch I have to add support for "host based initiator credentials in the keytab file" is ugly and has never made it into head. Maybe I'll figure out a way to resolve this before the end of this summer? Hopefully dfr@ can provide some more insight, but my feeling is that making the NLM server require Kerberos credentials might result in more serious problems than the security risk of not requiring them. I'm sure I've stated it before (and, yes, I am biased), but if you want reliable byte range locking to work across multiple clients, then using NFSv4 is a much better bet than the NLM. rick > [1] http://pubs.opengroup.org/onlinepubs/9629799/chap14.htm > _______________________________________________ > 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 May 25 16:30:40 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 081D21065674 for ; Fri, 25 May 2012 16:30:40 +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 733D48FC12 for ; Fri, 25 May 2012 16:30:39 +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:To:Content-Type; bh=LbWUy+0dcRi5C9Woya4ypKUFCW8adkKtg57SaeM7FDw=; b=DqJ5clEeHhEgz9hLXmx+CUGezaXHkkyXVIRP0U9fyB0jYql5uxUBwJig4rhM/UVIvylINquf0bNUHSJrNzI0nwlIU8b7v8/e9tFErs9xm3JMbZ/SW+F0cN3byCYoUju7; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXxPS-0002KW-GO for freebsd-fs@freebsd.org; Fri, 25 May 2012 11:30:39 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1337963432-3288-3287/5/28; Fri, 25 May 2012 16:30:32 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: Date: Fri, 25 May 2012 11:30:31 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/11.64 (FreeBSD) X-SA-Score: -1.5 Subject: Re: UFS SUJ and fsck questions 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, 25 May 2012 16:30:40 -0000 I finished the build of my FreeBSD 9 version of this backend and was able to do some further testing. It looks like the first question asked when you run fsck -C -y /dev/foo which has SUJ enabled is whether or not you want to run the journal first. This looks like it will be sufficient for my needs. From owner-freebsd-fs@FreeBSD.ORG Fri May 25 21:04:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27ABD1065679 for ; Fri, 25 May 2012 21:04:17 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 0004B8FC20 for ; Fri, 25 May 2012 21:04:16 +0000 (UTC) Received: from gypsy.mahan.org (localhost [127.0.0.1]) by ns.mahan.org (8.14.4/8.14.4) with ESMTP id q4PKkBIf053256 for ; Fri, 25 May 2012 13:46:11 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4FBFEF94.4020407@mahan.org> Date: Fri, 25 May 2012 13:46:12 -0700 From: Patrick Mahan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: GEOM: ada0: corrupt or invalid 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, 25 May 2012 21:04:17 -0000 All, First - These are FreeBSD 9.0 I am experiencing an unusual problem brought on because I used dd(1) to close a boot drive. We are setting up some demo systems to ship to our VARs and we initially used HP Proliants with WD 300 GB drives. But management decided to go with a Dell towers (power edge?) instead. These new drives are only 80 GB, so I tried to use dd to only copy the first 80 GB since it did not look like the usage on the WD's were under 80 GB. However, after the dd and boot of the Dell box I am seeing the following: ada0 at ata2 bus 0 scbus2 target 0 lun 0 ada0: ATA-6 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: 76293MB (156250000 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 GEOM: ada0: corrupt or invalid GPT detected. GEOM: ada0: GPT rejected -- may not be recoverable. And the boxes will not boot since they cannot find the kernel, etc. I booted the install media and switched to live-cd. That's where I found the error for the ada0 device. Looking at the /dev directory, I don't seen and of the partitions (a, b, c, etc). Also, on the HP this drive showed up as da0, not ada0, so I know that the /etc/fstab file needs to be fixed. But the question is - "Is this recoverable? Or should we just re-install everything from scratch?" Googling for the above error only seemed per From owner-freebsd-fs@FreeBSD.ORG Fri May 25 21:29: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 7DC5A106566C; Fri, 25 May 2012 21:29:30 +0000 (UTC) (envelope-from SRS0=rVvuI5=D5=rogers.blackberry.net=mdtancsa@srs.bis6.us.blackberry.com) Received: from smtp01.bis6.us.blackberry.com (smtp01.bis6.us.blackberry.com [74.82.85.1]) by mx1.freebsd.org (Postfix) with ESMTP id 303D18FC15; Fri, 25 May 2012 21:29:30 +0000 (UTC) Received: from b12.c8.bise6.blackberry ([192.168.0.112]) by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id q4PKmwTo024975; Fri, 25 May 2012 21:28:21 GMT X-rim-org-msg-ref-id: 152486179 Message-ID: <152486179-1337981301-cardhu_decombobulator_blackberry.rim.net-166733674-@b12.c8.bise6.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <4FBFEF94.4020407@mahan.org> In-Reply-To: <4FBFEF94.4020407@mahan.org> Sensitivity: Normal Importance: Normal To: "Patrick Mahan" , owner-freebsd-fs@freebsd.org, freebsd-fs@freebsd.org From: "Mike Tancsa" Date: Fri, 25 May 2012 21:28:19 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Cc: Subject: Re: GEOM: ada0: corrupt or invalid X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mike@wireless.sentex.ca List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:29:30 -0000 DQotLS0tLS0tLS0tLS0tLS0tLS0NCk1pa2UgVGFuY3NhDQpTZW50ZXggQ29tbXVuaWNhdGlvbnMg ICAgICAgICAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXRyaWNrIE1h aGFuIDxtYWhhbkBtYWhhbi5vcmc+DQpTZW5kZXI6IG93bmVyLWZyZWVic2QtZnNAZnJlZWJzZC5v cmcNCkRhdGU6IEZyaSwgMjUgTWF5IDIwMTIgMTM6NDY6MTIgDQpUbzogPGZyZWVic2QtZnNAZnJl ZWJzZC5vcmc+DQpTdWJqZWN0OiBHRU9NOiBhZGEwOiBjb3JydXB0IG9yIGludmFsaWQNCg0KQWxs LA0KDQpGaXJzdCAtIFRoZXNlIGFyZSBGcmVlQlNEIDkuMA0KDQpJIGFtIGV4cGVyaWVuY2luZyBh biB1bnVzdWFsIHByb2JsZW0gYnJvdWdodCBvbiBiZWNhdXNlIEkgdXNlZA0KZGQoMSkgdG8gY2xv c2UgYSBib290IGRyaXZlLiAgV2UgYXJlIHNldHRpbmcgdXAgc29tZSBkZW1vIHN5c3RlbXMNCnRv IHNoaXAgdG8gb3VyIFZBUnMgYW5kIHdlIGluaXRpYWxseSB1c2VkIEhQIFByb2xpYW50cyB3aXRo DQpXRCAzMDAgR0IgZHJpdmVzLiAgQnV0IG1hbmFnZW1lbnQgZGVjaWRlZCB0byBnbyB3aXRoIGEg RGVsbCB0b3dlcnMNCihwb3dlciBlZGdlPykgaW5zdGVhZC4gIFRoZXNlIG5ldyBkcml2ZXMgYXJl IG9ubHkgODAgR0IsIHNvIEkNCnRyaWVkIHRvIHVzZSBkZCB0byBvbmx5IGNvcHkgdGhlIGZpcnN0 IDgwIEdCIHNpbmNlIGl0IGRpZCBub3QNCmxvb2sgbGlrZSB0aGUgdXNhZ2Ugb24gdGhlIFdEJ3Mg d2VyZSB1bmRlciA4MCBHQi4NCg0KSG93ZXZlciwgYWZ0ZXIgdGhlIGRkIGFuZCBib290IG9mIHRo ZSBEZWxsIGJveCBJIGFtIHNlZWluZyB0aGUNCmZvbGxvd2luZzoNCg0KYWRhMCBhdCBhdGEyIGJ1 cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4gMA0KYWRhMDogPFdEQyBXRDgwMEpELTc1Sk5BMCAwNS4w MUMwNT4gQVRBLTYgU0FUQSAxLnggZGV2aWNlDQphZGEwOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMg KFNBVEEgMS54LCBVRE1BNSwgUElPIDgxOTJieXRlcykNCmFkYTA6IDc2MjkzTUIgKDE1NjI1MDAw MCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQ0KYWRhMDogUHJldmlvdXNseSB3 YXMga25vd24gYXMgYWQ0DQoNCkdFT006IGFkYTA6IGNvcnJ1cHQgb3IgaW52YWxpZCBHUFQgZGV0 ZWN0ZWQuDQpHRU9NOiBhZGEwOiBHUFQgcmVqZWN0ZWQgLS0gbWF5IG5vdCBiZSByZWNvdmVyYWJs ZS4NCg0KQW5kIHRoZSBib3hlcyB3aWxsIG5vdCBib290IHNpbmNlIHRoZXkgY2Fubm90IGZpbmQg dGhlIGtlcm5lbCwNCmV0Yy4NCg0KSSBib290ZWQgdGhlIGluc3RhbGwgbWVkaWEgYW5kIHN3aXRj aGVkIHRvIGxpdmUtY2QuICBUaGF0J3Mgd2hlcmUNCkkgZm91bmQgdGhlIGVycm9yIGZvciB0aGUg YWRhMCBkZXZpY2UuICBMb29raW5nIGF0IHRoZSAvZGV2DQpkaXJlY3RvcnksIEkgZG9uJ3Qgc2Vl biBhbmQgb2YgdGhlIHBhcnRpdGlvbnMgKGEsIGIsIGMsIGV0YykuICBBbHNvLA0Kb24gdGhlIEhQ IHRoaXMgZHJpdmUgc2hvd2VkIHVwIGFzIGRhMCwgbm90IGFkYTAsIHNvIEkga25vdyB0aGF0DQp0 aGUgL2V0Yy9mc3RhYiBmaWxlIG5lZWRzIHRvIGJlIGZpeGVkLg0KDQpCdXQgdGhlIHF1ZXN0aW9u IGlzIC0gICJJcyB0aGlzIHJlY292ZXJhYmxlPyAgT3Igc2hvdWxkIHdlIGp1c3QNCnJlLWluc3Rh bGwgZXZlcnl0aGluZyBmcm9tIHNjcmF0Y2g/Ig0KDQpHb29nbGluZyBmb3IgdGhlIGFib3ZlIGVy cm9yIG9ubHkgc2VlbWVkIHBlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmZyZWVic2QtZnNAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQpodHRwOi8v bGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWZzDQpUbyB1bnN1YnNj cmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1mcy11bnN1YnNjcmliZUBmcmVlYnNkLm9y ZyINCg0K From owner-freebsd-fs@FreeBSD.ORG Fri May 25 22:08:46 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 26D1F106564A for ; Fri, 25 May 2012 22:08:46 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 84BB78FC1C for ; Fri, 25 May 2012 22:08:45 +0000 (UTC) Received: from seedling.local (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q4PM8cjt008926 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 May 2012 23:08:41 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q4PM8cjt008926 Authentication-Results: smtp.infracaninophile.co.uk/q4PM8cjt008926; dkim=none (no signature); dkim-adsp=none X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host seedling.black-earth.co.uk [81.187.76.163] claimed to be seedling.local Message-ID: <4FC002CF.2080702@FreeBSD.org> Date: Sat, 26 May 2012 00:08:15 +0200 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Patrick Mahan References: <4FBFEF94.4020407@mahan.org> In-Reply-To: <4FBFEF94.4020407@mahan.org> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD28DF0D1AE674D6101CBF9B5" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-fs@FreeBSD.org Subject: Re: GEOM: ada0: corrupt or invalid 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, 25 May 2012 22:08:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD28DF0D1AE674D6101CBF9B5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25/05/2012 22:46, Patrick Mahan wrote: > But the question is - "Is this recoverable? Or should we just > re-install everything from scratch?" Re-install. You can't use dd(1) to copy a disk image to a smaller physical drive: the disk size is encoded in various structures on disk and used at boot time; copying a filesystem with dd(8) and truncating it (even if the used space is less than the target partition size) just doesn't work. If you have work you've done on the original disk images that you'ld like to copy to the new ones, then use a file-system level copy program. There are any number of suitable candidates, most of which have the ability to write across a network link if needed: * dump(8) and restore(8) * rsync(1) * tar(1) * find(1) and cpio(1) Even cp(1). Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigD28DF0D1AE674D6101CBF9B5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/AAuUACgkQ8Mjk52CukIywngCdEXdWxFvk4AeSWiAdPY0lqTlP sAQAn2dHSeh8GjgdijH1qrKNdnCn1y5T =y+8K -----END PGP SIGNATURE----- --------------enigD28DF0D1AE674D6101CBF9B5-- From owner-freebsd-fs@FreeBSD.ORG Fri May 25 22:37: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 1DC24106564A; Fri, 25 May 2012 22:37:01 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id EA2AB8FC15; Fri, 25 May 2012 22:37:00 +0000 (UTC) Received: from gypsy.mahan.org (localhost [127.0.0.1]) by ns.mahan.org (8.14.4/8.14.4) with ESMTP id q4PMaxnI053777; Fri, 25 May 2012 15:36:59 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4FC0098C.9060107@mahan.org> Date: Fri, 25 May 2012 15:37:00 -0700 From: Patrick Mahan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Matthew Seaman References: <4FBFEF94.4020407@mahan.org> <4FC002CF.2080702@FreeBSD.org> In-Reply-To: <4FC002CF.2080702@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: GEOM: ada0: corrupt or invalid 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, 25 May 2012 22:37:01 -0000 On 5/25/12 3:08 PM, Matthew Seaman wrote: > On 25/05/2012 22:46, Patrick Mahan wrote: >> But the question is - "Is this recoverable? Or should we just >> re-install everything from scratch?" > > Re-install. You can't use dd(1) to copy a disk image to a smaller > physical drive: the disk size is encoded in various structures on disk > and used at boot time; copying a filesystem with dd(8) and truncating > it (even if the used space is less than the target partition size) just > doesn't work. > > If you have work you've done on the original disk images that you'ld > like to copy to the new ones, then use a file-system level copy program. > There are any number of suitable candidates, most of which have the > ability to write across a network link if needed: > > * dump(8) and restore(8) > > * rsync(1) > > * tar(1) > > * find(1) and cpio(1) > > Even cp(1). > > Cheers, > > Matthew > Thanks, As I expected, it was chock gun, aim at foot, pulled the trigger.... Re-installing now. Patrick From owner-freebsd-fs@FreeBSD.ORG Sat May 26 12:42:21 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 95AFF1065670; Sat, 26 May 2012 12:42:21 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 12A838FC0C; Sat, 26 May 2012 12:42:20 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SYGK2-0005bL-NN; Sat, 26 May 2012 15:42:18 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 811271CC34; Sat, 26 May 2012 15:42:17 +0300 (EEST) Date: Sat, 26 May 2012 15:42:16 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20120526124216.GA1302@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20120524114702.GA38087@pm513-1.comsys.ntu-kpi.kiev.ua> <169170676.853090.1337953018295.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169170676.853090.1337953018295.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-05-26 15:42:18 X-Connected-IP: 10.18.52.101:21679 X-Message-Linecount: 66 X-Body-Linecount: 50 X-Message-Size: 3371 X-Body-Size: 2588 Cc: freebsd-fs@freebsd.org, dfr Subject: Re: NLM uses AUTH_SYS ignoring sec option in mount_nfs 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, 26 May 2012 12:42:21 -0000 On Fri, May 25, 2012 at 09:36:58AM -0400, Rick Macklem wrote: > Andrey Simonenko wrote: > > Hello, > > > > Looks like that NLM always uses AUTH_SYS even if a client specified > > another security flavor in the mount_nfs's "sec" option. Also NLM > > on the server does not verify that NLM client's security flavor > > is allowed by NFS exported file system, security flavors array from > > VFS_CHECKEXP() is ignored in nlm/nlm_prot_impl.c:nlm_get_vfs_state(). > > > > Such behaviour of NLM I see on 10-CURRENT, I added log messages to > > the kernel to see security flavors used by NFSv3 and NLM requests. > > Both NFS client and server are on the same system, NFSv3 mounts are > > from unprivileged users. > > > > According to [1] NLMv4 allows to use different security flavors. > > > > Can somebody comment such behaviour of NLM? > > > Well, as you might know, I wasn't the author of the NLM implementation, > so I'm just commenting based on what little I know about it. (I've > added dfr@ to the cc list, in case he can provide more insight?) > > I think the big problem with using Kerberos with the NLM is > "what happens when the user's TGT ticket expires on the client?". > If this happens and the server requires a valid credential based > on a Kerberos ticket, then the client/user won't be able to unlock > the locks that have been put on the file. It is conceivable > that these file locks could hang around "forever". > (An obvious case here is where the user for a uid isn't actually > prsent to do a fresh kinit when the TGT expires. Another is an > application program that doesn't handle a EACCES error from a > lock syscall well.) I think this problem could be avoided by > allowing AUTH_SYS for unlock operations, so that the unlocking > won't fail. > Also, from a glance at the code, it appears that the client will > re-acquire locks after a server crashes/reboots. What do you do > if this re-acquisition fails, due to a TGT timeout? If such approach is used, then NLM will work only in cases when user credentials on a client system correspond to user credentials on a server system. When a user kinit'ed, then corresponding user's credentials are setup by the server for all NFS RPC requests. When a user opened a file, then is trying to lock it, user's credentials are passed in RPC request (because of AUTH_SYS in NLM) and a server will use them to verify whether a user is allowed to access a file that is being locked. Simple check when local credentials do not correspond to remote user credentials mapping shows that fcntl(F_SETLK) returns EACCES.