From owner-freebsd-fs@FreeBSD.ORG Mon Mar 17 02:02:05 2008 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B9AF1065676 for ; Mon, 17 Mar 2008 02:02:05 +0000 (UTC) (envelope-from lists@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id 086888FC31 for ; Mon, 17 Mar 2008 02:02:04 +0000 (UTC) (envelope-from lists@adam.gs) Received: from [127.0.0.1] (localhost.adam.gs [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id BEEDBF3CB09 for ; Sun, 16 Mar 2008 21:44:30 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mail; d=adam.gs; b=GgihC/s6S39tGkCZS6ekK/3m4b6ZgimKAExmJpp78j8SnDqFKbgCPExhLuNDVUwtUMzchrWYn2cjjuUIkAjlTi8ZrqGjgtSEbRjEfcCXjuSQYbfaZJ6qqQXjuIKdIMHyz948yfUglg8XH21LGDHTVudl3PLvQCFci1mNUP7XcIU=; Received: from [10.0.7.125] (unknown [64.111.192.110]) (Authenticated sender: adam@adam.gs) by mail.adam.gs (Postfix) with ESMTP id 6ECDBF3C3EA; Sun, 16 Mar 2008 21:44:30 -0400 (EDT) Message-Id: <5D026085-BA3C-4A9C-88C4-E229837E0F90@adam.gs> From: Adam Jacob Muller To: Alfred Perlstein In-Reply-To: <20080314100155.GW67856@elvis.mu.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 16 Mar 2008 21:44:27 -0400 References: <20080314100155.GW67856@elvis.mu.org> X-Mailer: Apple Mail (2.919.2) Cc: ups@freebsd.org, jhb@freebsd.org, fs@freebsd.org Subject: Re: nfs no longer reconnects for udp sockets 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, 17 Mar 2008 02:02:05 -0000 Ah, Very nice, I have been hitting this issue for a while now but had not completely realized what was causing it. Will have to set aside some time to test this but the patch looks good (it's 50% comments so I can understand what you are doing anyway :)). "Please don't break this, it's annoying." Indeed, this bug is quite annoying. Thanks for your work on this (and, obviously, the work you did on the reconnect support prior). -Adam On Mar 14, 2008, at 6:01 AM, Alfred Perlstein wrote: > Hey guys, someone was having issues with NFS mounts and > I happened to notice that it appears that the > "reconnect if socket went south" semantics I added a few > years ago were basically disabled by the nfs optimizations > added for "recv side processing". > > The problem is as such: > > You have an NFS mount on UDP. > Somehow the route goes bad. > The UDP socket is now "broken" as the route will remain > hosed forever. This is particularly bad when an interface > flaps and loses its IP address as the UDP socket's route is > then set to nul or loopback or something and never gets fixed. > Your nfs mount goes dead even if the routing issues is > resolved (interface brought back up). > > Please see attached patch. > > Easy way to reproduce problem: > > mount an nfs filesystem using UDP. > ifconfig interface down > try to access mount > ifconfig interface up > mount should still be dead. > > Please review. > > -- > - Alfred Perlstein > < > nfs_reconnect_udp.diff>_______________________________________________ > 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 Mon Mar 17 02:24:31 2008 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1CC6106564A; Mon, 17 Mar 2008 02:24:31 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D81A18FC15; Mon, 17 Mar 2008 02:24:31 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E06351A4D83; Sun, 16 Mar 2008 19:23:19 -0700 (PDT) Date: Sun, 16 Mar 2008 19:23:19 -0700 From: Alfred Perlstein To: Adam Jacob Muller Message-ID: <20080317022319.GH67856@elvis.mu.org> References: <20080314100155.GW67856@elvis.mu.org> <5D026085-BA3C-4A9C-88C4-E229837E0F90@adam.gs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D026085-BA3C-4A9C-88C4-E229837E0F90@adam.gs> User-Agent: Mutt/1.4.2.3i Cc: ups@freebsd.org, jhb@freebsd.org, fs@freebsd.org Subject: Re: nfs no longer reconnects for udp sockets 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, 17 Mar 2008 02:24:32 -0000 * Adam Jacob Muller [080316 18:43] wrote: > Ah, Very nice, I have been hitting this issue for a while now but had > not completely realized what was causing it. > Will have to set aside some time to test this but the patch looks good > (it's 50% comments so I can understand what you are doing anyway :)). > > "Please don't break this, it's annoying." > Indeed, this bug is quite annoying. > > Thanks for your work on this (and, obviously, the work you did on the > reconnect support prior). Can you give me an ETA on testing? If it's soon I can hold off committing for your feedback and that would help much. Don't forget you need to use UDP. :) -Alfred > > -Adam > > > On Mar 14, 2008, at 6:01 AM, Alfred Perlstein wrote: > > >Hey guys, someone was having issues with NFS mounts and > >I happened to notice that it appears that the > >"reconnect if socket went south" semantics I added a few > >years ago were basically disabled by the nfs optimizations > >added for "recv side processing". > > > >The problem is as such: > > > >You have an NFS mount on UDP. > >Somehow the route goes bad. > >The UDP socket is now "broken" as the route will remain > >hosed forever. This is particularly bad when an interface > >flaps and loses its IP address as the UDP socket's route is > >then set to nul or loopback or something and never gets fixed. > >Your nfs mount goes dead even if the routing issues is > >resolved (interface brought back up). > > > >Please see attached patch. > > > >Easy way to reproduce problem: > > > >mount an nfs filesystem using UDP. > >ifconfig interface down > >try to access mount > >ifconfig interface up > >mount should still be dead. > > > >Please review. > > > >-- > >- Alfred Perlstein > >< > >nfs_reconnect_udp.diff>_______________________________________________ > >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" -- - Alfred Perlstein From owner-freebsd-fs@FreeBSD.ORG Mon Mar 17 11:07:03 2008 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 363901065677 for ; Mon, 17 Mar 2008 11:07:03 +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 2DD788FC30 for ; Mon, 17 Mar 2008 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2HB737k055083 for ; Mon, 17 Mar 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2HB72pC055079 for freebsd-fs@FreeBSD.org; Mon, 17 Mar 2008 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Mar 2008 11:07:02 GMT Message-Id: <200803171107.m2HB72pC055079@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, 17 Mar 2008 11:07:03 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o kern/116170 fs [panic] Kernel panic when mounting /tmp o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o bin/118249 fs mv(1): moving a directory changes its mtime 6 problems total. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 20 13:28:21 2008 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 5DD33106564A for ; Thu, 20 Mar 2008 13:28:21 +0000 (UTC) (envelope-from ruud@il.fontys.nl) Received: from mx1.stack.nl (meestal-mk5.stack.nl [IPv6:2001:610:1108:5010::149]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0238FC28 for ; Thu, 20 Mar 2008 13:28:20 +0000 (UTC) (envelope-from ruud@il.fontys.nl) Received: by mx1.stack.nl (Postfix, from userid 65534) id E512A3F547; Thu, 20 Mar 2008 14:28:19 +0100 (CET) X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on meestal-mk5.stack.nl X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Relay-Country: Received: from mail.il.fontys.nl (mail.il.fontys.nl [IPv6:2001:4128:1000:1000::7]) by mailhost.stack.nl (Postfix) with ESMTP id 63520441F8 for ; Thu, 20 Mar 2008 14:28:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.il.fontys.nl (Postfix/VSRI) with ESMTP id 3DD4317042 for ; Thu, 20 Mar 2008 14:28:13 +0100 (CET) X-Virus-Scanned: amavisd-new at il.fontys.nl Received: from mail.il.fontys.nl ([127.0.0.1]) by localhost (sukke.il.fontys.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ui5w7cqFUZ4 for ; Thu, 20 Mar 2008 14:28:12 +0100 (CET) Received: from penguin (penguin.il.fontys.nl [IPv6:2001:4128:1000:1000::35]) by mail.il.fontys.nl (Postfix) with SMTP for ; Thu, 20 Mar 2008 14:28:12 +0100 (CET) Received: by penguin (sSMTP sendmail emulation); Thu, 20 Mar 2008 14:28:12 +0100 From: "Ruud Althuizen" Date: Thu, 20 Mar 2008 14:28:12 +0100 To: freebsd-fs@freebsd.org Message-ID: <20080320132812.GL511@il.fontys.nl> References: <20080320093401.GJ511@il.fontys.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="54ZiyWcDhi/7bWb8" Content-Disposition: inline In-Reply-To: <20080320093401.GJ511@il.fontys.nl> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: ZFS + NFS problems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ruud Althuizen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 13:28:21 -0000 --54ZiyWcDhi/7bWb8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello People, I have also posted this message on freebsd-questions, but this list probably is more appropriate. I have a webserver with a ZFS pool for storing all the user data. So all the users have their own filesystem with a quota set. With exporting the system I ran into some problems with NFS though. At other machines I can mount the user specific shares resulting in an 80-line fstab per machine or mount a higher dir. But that last option results in all the dirs and files in it mapped to root. So is there a solution to that last problem or will I need to use something else? As the share also gets mounted with Linux machines a server-side solution is prefered. --=20 Greetings, Ruud Althuizen --54ZiyWcDhi/7bWb8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH4mZskqncCMFskRURArZeAJ9/mEAVBydwU6uxfjJYQnDrATxgRACfcwXi +ZFdNppZI3HmLKx75ncNBHY= =PPi0 -----END PGP SIGNATURE----- --54ZiyWcDhi/7bWb8-- From owner-freebsd-fs@FreeBSD.ORG Thu Mar 20 16:20:19 2008 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 1DB271065748 for ; Thu, 20 Mar 2008 16:20:18 +0000 (UTC) (envelope-from ruud@il.fontys.nl) Received: from mx1.stack.nl (meestal-mk5.stack.nl [131.155.140.149]) by mx1.freebsd.org (Postfix) with ESMTP id E52F98FC29 for ; Thu, 20 Mar 2008 16:20:17 +0000 (UTC) (envelope-from ruud@il.fontys.nl) Received: by mx1.stack.nl (Postfix, from userid 65534) id 8C6FD455A6; Thu, 20 Mar 2008 16:59:50 +0100 (CET) X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on meestal-mk5.stack.nl X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Relay-Country: Received: from mail.il.fontys.nl (mail.il.fontys.nl [IPv6:2001:4128:1000:1000::7]) by mailhost.stack.nl (Postfix) with ESMTP id 135FD43FD5; Thu, 20 Mar 2008 16:59:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.il.fontys.nl (Postfix/VSRI) with ESMTP id C692C17046; Thu, 20 Mar 2008 16:59:43 +0100 (CET) X-Virus-Scanned: amavisd-new at il.fontys.nl Received: from mail.il.fontys.nl ([127.0.0.1]) by localhost (sukke.il.fontys.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq7Stc0As487; Thu, 20 Mar 2008 16:59:43 +0100 (CET) Received: from penguin (penguin.il.fontys.nl [IPv6:2001:4128:1000:1000::35]) by mail.il.fontys.nl (Postfix) with SMTP; Thu, 20 Mar 2008 16:59:43 +0100 (CET) Received: by penguin (sSMTP sendmail emulation); Thu, 20 Mar 2008 16:59:43 +0100 From: "Ruud Althuizen" Date: Thu, 20 Mar 2008 16:59:43 +0100 To: JH Message-ID: <20080320155943.GM511@il.fontys.nl> References: <20080320093401.GJ511@il.fontys.nl> <20080320132812.GL511@il.fontys.nl> <47E27F19.8000109@sector6.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tu8ztk+XgTAiG9Id" Content-Disposition: inline In-Reply-To: <47E27F19.8000109@sector6.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS + NFS problems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ruud Althuizen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 16:20:19 -0000 --Tu8ztk+XgTAiG9Id Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu 20 Mar 2008 04:13 PM, JH wrote: > Ruud Althuizen wrote: >> I can mount the user specific shares resulting in an >> 80-line fstab per machine or mount a higher dir. > > If I interpreted your remarks correctly, maintaining an 80-line fstab on= =20 > each client is undesirable. Very undesirable. > Have you considered using the amd automounter? It is a possibility. But I need to look for something that works with Linux as well. So a server-side solution is prefered. --=20 Greetings, Ruud Althuizen --Tu8ztk+XgTAiG9Id Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH4onvkqncCMFskRURAnmyAKCAEd97FGnw/+p+JUH/lEdWUuK+LACfQDTw BdCwzGzx/R7gghPQ25HzJ7A= =4abW -----END PGP SIGNATURE----- --Tu8ztk+XgTAiG9Id-- From owner-freebsd-fs@FreeBSD.ORG Thu Mar 20 18:50:59 2008 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 8F4B31065678 for ; Thu, 20 Mar 2008 18:50:59 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mh0.csub.edu (mh0.csub.edu [136.168.1.94]) by mx1.freebsd.org (Postfix) with ESMTP id 627F18FC29 for ; Thu, 20 Mar 2008 18:50:59 +0000 (UTC) (envelope-from raj@csub.edu) Received: from cserv65.csub.edu (strider.its.csub.edu [136.168.10.65]) by mh0.csub.edu (8.13.8/8.13.8) with ESMTP id m2KIIFak063869; Thu, 20 Mar 2008 11:18:16 -0700 (PDT) (envelope-from raj@csub.edu) Message-ID: <47E2AA67.5050604@csub.edu> Date: Thu, 20 Mar 2008 11:18:15 -0700 From: Russell Jackson User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: Ruud Althuizen References: <20080320093401.GJ511@il.fontys.nl> <20080320132812.GL511@il.fontys.nl> <47E27F19.8000109@sector6.net> <20080320155943.GM511@il.fontys.nl> In-Reply-To: <20080320155943.GM511@il.fontys.nl> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010902030301030703070003" Cc: freebsd-fs@freebsd.org, JH Subject: Re: ZFS + NFS problems 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, 20 Mar 2008 18:50:59 -0000 This is a cryptographically signed message in MIME format. --------------ms010902030301030703070003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ruud Althuizen wrote: > On Thu 20 Mar 2008 04:13 PM, JH wrote: >> Ruud Althuizen wrote: >>> I can mount the user specific shares resulting in an >>> 80-line fstab per machine or mount a higher dir. >> If I interpreted your remarks correctly, maintaining an 80-line fstab on >> each client is undesirable. > Very undesirable. > >> Have you considered using the amd automounter? > It is a possibility. But I need to look for something that works with Linux > as well. So a server-side solution is prefered. > Use amd(8) or autofs on linux. Not server side though. -- Russell A. Jackson Network Analyst California State University, Bakersfield Do you think that when they asked George Washington for ID that he just whipped out a quarter? -- Steven Wright --------------ms010902030301030703070003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2DCC BegwggTQoAMCAQICCQC2yYqf6jv75zANBgkqhkiG9w0BAQUFADCB1DELMAkGA1UEBhMCVVMx EzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC0Jha2Vyc2ZpZWxkMTEwLwYDVQQKEyhD YWxpZm9ybmlhIFN0YXRlIFVuaXZlcnNpdHksIEJha2Vyc2ZpZWxkMRkwFwYDVQQLExBOZXR3 b3JrIFNlcnZpY2VzMS8wLQYDVQQDEyZDU1UsIEJha2Vyc2ZpZWxkIENlcnRpZmljYXRlIEF1 dGhvcml0eTEbMBkGCSqGSIb3DQEJARYMbm9jQGNzdWIuZWR1MB4XDTA3MTAxMjAyMDY0MFoX DTA4MTAxMTAyMDY0MFowgcAxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQw EgYDVQQHEwtCYWtlcnNmaWVsZDExMC8GA1UEChMoQ2FsaWZvcm5pYSBTdGF0ZSBVbml2ZXJz aXR5LCBCYWtlcnNmaWVsZDEZMBcGA1UECxMQTmV0d29yayBTZXJ2aWNlczEbMBkGA1UEAxMS UnVzc2VsbCBBLiBKYWNrc29uMRswGQYJKoZIhvcNAQkBFgxyYWpAY3N1Yi5lZHUwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCcVWSj+BnEwxMg9hhRoZJaxsJOWTsC4rngKU7T BjDEW+uHeakW6n8Y5Slqk3qarMeUeGD6YYFiq5EiKIVyqQfSPTbnXoUe2JAG9rCFGzh0Tvd0 KEGfiKfpS8scjCOkwOjLGizAJmHKqIwi7+p356Ot/2DnLxILA6z11bcIakU2piiNOL8327wz gfkyk5Soi98UlFE5D/A9HCEmOsqEsb2NjL+lAN+eETCa3TWCQ7CyQaJbXooId4UlWcceJNU8 /fhA7iZSn0BiKZu7BZHR+pv3IEnhoxRR1KTXHk+JzbYwAq7hVE9lfo79Xy8qLsrIXi5ziokr gTrlIFXSj2h3+Mw/AgMBAAGjggHNMIIByTAMBgNVHRMEBTADAQH/MDgGCWCGSAGG+EIBDQQr FilDZXJ0aWZpY2F0ZSBpc3N1ZWQgYnkgaHR0cHM6Ly9jYS5jc3ViLmVkdTAdBgNVHQ4EFgQU /RDecfNP15wwCVG5LcIHILSaljswggEKBgNVHSMEggEBMIH+gBT/QjTuzr/iBeVSlKbffggx 7zJ3H6GB2qSB1zCB1DELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNV BAcTC0Jha2Vyc2ZpZWxkMTEwLwYDVQQKEyhDYWxpZm9ybmlhIFN0YXRlIFVuaXZlcnNpdHks IEJha2Vyc2ZpZWxkMRkwFwYDVQQLExBOZXR3b3JrIFNlcnZpY2VzMS8wLQYDVQQDEyZDU1Us IEJha2Vyc2ZpZWxkIENlcnRpZmljYXRlIEF1dGhvcml0eTEbMBkGCSqGSIb3DQEJARYMbm9j QGNzdWIuZWR1ggkAtsmKn+o7++EwLQYJYIZIAYb4QgEEBCAWHmh0dHBzOi8vY2EuY3N1Yi5l ZHUvY2EtY3JsLnBlbTAjBglghkgBhvhCAQIEFhYUaHR0cHM6Ly9jYS5jc3ViLmVkdS8wDQYJ KoZIhvcNAQEFBQADggEBAIfQnz4aGpPLFTiXoAU+yFyT6cbyFO3KX7cwd9QS3TDEXgqMJgTE A8YFC8s6zLF0YGK6QIqI8Ia9f0iWrcm4huZdODBzaRdHauoiIDHbwcWR93dCK5vG8vqLRLWo OaZrElJ6QsEdiarCh7MCKs5vCY9MaPYcVqSpBPWNV0tvJvfZTE//xiD30I8kGuu27urBxCoj JSepB219HMQHcJ+RFjcA87BVhRfy2ZAOz+Kt73Sdnb6zW86qSZAjGzM2OTvu23f+hIRGiTBx idWs/qVWId1wo8xUyd32wZ9+8Ns8pbwtBi0cjb9HWIYJurqcKY8bW3uS/ydisGoPVXVZKLRv A6YwggXoMIIE0KADAgECAgkAtsmKn+o7++cwDQYJKoZIhvcNAQEFBQAwgdQxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtCYWtlcnNmaWVsZDExMC8GA1UE ChMoQ2FsaWZvcm5pYSBTdGF0ZSBVbml2ZXJzaXR5LCBCYWtlcnNmaWVsZDEZMBcGA1UECxMQ TmV0d29yayBTZXJ2aWNlczEvMC0GA1UEAxMmQ1NVLCBCYWtlcnNmaWVsZCBDZXJ0aWZpY2F0 ZSBBdXRob3JpdHkxGzAZBgkqhkiG9w0BCQEWDG5vY0Bjc3ViLmVkdTAeFw0wNzEwMTIwMjA2 NDBaFw0wODEwMTEwMjA2NDBaMIHAMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLQmFrZXJzZmllbGQxMTAvBgNVBAoTKENhbGlmb3JuaWEgU3RhdGUgVW5p dmVyc2l0eSwgQmFrZXJzZmllbGQxGTAXBgNVBAsTEE5ldHdvcmsgU2VydmljZXMxGzAZBgNV BAMTElJ1c3NlbGwgQS4gSmFja3NvbjEbMBkGCSqGSIb3DQEJARYMcmFqQGNzdWIuZWR1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnFVko/gZxMMTIPYYUaGSWsbCTlk7AuK5 4ClO0wYwxFvrh3mpFup/GOUpapN6mqzHlHhg+mGBYquRIiiFcqkH0j02516FHtiQBvawhRs4 dE73dChBn4in6UvLHIwjpMDoyxoswCZhyqiMIu/qd+ejrf9g5y8SCwOs9dW3CGpFNqYojTi/ N9u8M4H5MpOUqIvfFJRROQ/wPRwhJjrKhLG9jYy/pQDfnhEwmt01gkOwskGiW16KCHeFJVnH HiTVPP34QO4mUp9AYimbuwWR0fqb9yBJ4aMUUdSk1x5Pic22MAKu4VRPZX6O/V8vKi7KyF4u c4qJK4E65SBV0o9od/jMPwIDAQABo4IBzTCCAckwDAYDVR0TBAUwAwEB/zA4BglghkgBhvhC AQ0EKxYpQ2VydGlmaWNhdGUgaXNzdWVkIGJ5IGh0dHBzOi8vY2EuY3N1Yi5lZHUwHQYDVR0O BBYEFP0Q3nHzT9ecMAlRuS3CByC0mpY7MIIBCgYDVR0jBIIBATCB/oAU/0I07s6/4gXlUpSm 334IMe8ydx+hgdqkgdcwgdQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQw EgYDVQQHEwtCYWtlcnNmaWVsZDExMC8GA1UEChMoQ2FsaWZvcm5pYSBTdGF0ZSBVbml2ZXJz aXR5LCBCYWtlcnNmaWVsZDEZMBcGA1UECxMQTmV0d29yayBTZXJ2aWNlczEvMC0GA1UEAxMm Q1NVLCBCYWtlcnNmaWVsZCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxGzAZBgkqhkiG9w0BCQEW DG5vY0Bjc3ViLmVkdYIJALbJip/qO/vhMC0GCWCGSAGG+EIBBAQgFh5odHRwczovL2NhLmNz dWIuZWR1L2NhLWNybC5wZW0wIwYJYIZIAYb4QgECBBYWFGh0dHBzOi8vY2EuY3N1Yi5lZHUv MA0GCSqGSIb3DQEBBQUAA4IBAQCH0J8+GhqTyxU4l6AFPshck+nG8hTtyl+3MHfUEt0wxF4K jCYExAPGBQvLOsyxdGBiukCKiPCGvX9Ilq3JuIbmXTgwc2kXR2rqIiAx28HFkfd3QiubxvL6 i0S1qDmmaxJSekLBHYmqwoezAirObwmPTGj2HFakqQT1jVdLbyb32UxP/8Yg99CPJBrrtu7q wcQqIyUnqQdtfRzEB3CfkRY3APOwVYUX8tmQDs/ire90nZ2+s1vOqkmQIxszNjk77tt3/oSE RokwcYnVrP6lViHdcKPMVMnd9sGffvDbPKW8LQYtHI2/R1iGCbq6nCmPG1t7kv8nYrBqD1V1 WSi0bwOmMYIErTCCBKkCAQEwgeIwgdQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9y bmlhMRQwEgYDVQQHEwtCYWtlcnNmaWVsZDExMC8GA1UEChMoQ2FsaWZvcm5pYSBTdGF0ZSBV bml2ZXJzaXR5LCBCYWtlcnNmaWVsZDEZMBcGA1UECxMQTmV0d29yayBTZXJ2aWNlczEvMC0G A1UEAxMmQ1NVLCBCYWtlcnNmaWVsZCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxGzAZBgkqhkiG 9w0BCQEWDG5vY0Bjc3ViLmVkdQIJALbJip/qO/vnMAkGBSsOAwIaBQCgggKfMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDMyMDE4MTgxNVowIwYJKoZI hvcNAQkEMRYEFA9IZ7aSqo7J2EWf42qvZz1wTJ07MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHzBgkrBgEEAYI3EAQxgeUwgeIwgdQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpD YWxpZm9ybmlhMRQwEgYDVQQHEwtCYWtlcnNmaWVsZDExMC8GA1UEChMoQ2FsaWZvcm5pYSBT dGF0ZSBVbml2ZXJzaXR5LCBCYWtlcnNmaWVsZDEZMBcGA1UECxMQTmV0d29yayBTZXJ2aWNl czEvMC0GA1UEAxMmQ1NVLCBCYWtlcnNmaWVsZCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxGzAZ BgkqhkiG9w0BCQEWDG5vY0Bjc3ViLmVkdQIJALbJip/qO/vnMIH1BgsqhkiG9w0BCRACCzGB 5aCB4jCB1DELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC0Jh a2Vyc2ZpZWxkMTEwLwYDVQQKEyhDYWxpZm9ybmlhIFN0YXRlIFVuaXZlcnNpdHksIEJha2Vy c2ZpZWxkMRkwFwYDVQQLExBOZXR3b3JrIFNlcnZpY2VzMS8wLQYDVQQDEyZDU1UsIEJha2Vy c2ZpZWxkIENlcnRpZmljYXRlIEF1dGhvcml0eTEbMBkGCSqGSIb3DQEJARYMbm9jQGNzdWIu ZWR1AgkAtsmKn+o7++cwDQYJKoZIhvcNAQEBBQAEggEAVtbQ0IxbeQNtDbKcgby8tjZgyLsD eeA6wOd4jRW0rJIfPK8c5+800cXoLcUoSkRCbdMvGEklja7GQmnaEPlpdeViqJahMEh1joMx l5L+gLZjWobput+lHJfLdl0+bsrSyCOnLAha/ksM70FsFpa2pXtsgqdmqC+s346zhDI+EFKc QLakx8UL73BpxAd5h0pIk+AeY0O5ArS2fTH+oAaZNNNr6pzBuKb4CggapeqK0GnSFoZLdwiS EA3wPGRApxrJwGb559aQFPBjT8I1cb3VeLM9v8ibFPagdtIuimFKH6F1ipkh2XOjFKh7GPcY 0F/UWvf+dxACichMQAnr/BhFwAAAAAAAAA== --------------ms010902030301030703070003-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 21 22:20:57 2008 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 BD2DE1065674 for ; Fri, 21 Mar 2008 22:20:57 +0000 (UTC) (envelope-from V.Haisman@sh.cvut.cz) Received: from service2.sh.cvut.cz (service2.sh.cvut.cz [IPv6:2001:718:2:0:217:a4ff:fe3f:b3d4]) by mx1.freebsd.org (Postfix) with ESMTP id C07018FC13 for ; Fri, 21 Mar 2008 22:20:56 +0000 (UTC) (envelope-from V.Haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service2.sh.cvut.cz (Postfix) with ESMTP id C311713778A; Fri, 21 Mar 2008 23:20:55 +0100 (CET) Received: from service2.sh.cvut.cz ([127.0.0.1]) by localhost (service2.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08048-08; Fri, 21 Mar 2008 23:20:49 +0100 (CET) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by service2.sh.cvut.cz (Postfix) with ESMTP id 7481E1377DF; Fri, 21 Mar 2008 23:20:49 +0100 (CET) Received: from [192.168.1.2] (localhost [127.0.0.1]) by logout.sh.cvut.cz (Postfix) with ESMTP id 1D82361C31; Fri, 21 Mar 2008 23:20:49 +0100 (CET) Message-ID: <47E43496.5080201@sh.cvut.cz> Date: Fri, 21 Mar 2008 23:20:06 +0100 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 0.95.6 OpenPGP: id=1204AF05; url=http://logout.sh.cvut.cz/~wilx/Vaclav_Haisman_(0x63B6B297)_pub.asc Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUnMzWJm5S+0864pn5r blp/hnW2up7X7uqftbNRVUrW1LGBdGfHwJqPi3ScoYtBQzhDxGEwAAAAB3RJTUUH1QoQDDgyQtx8 HQAAAkNJREFUeJzFU0toU0EUPYu66CpGdCUUmoUJkpUDQUoNBVEUrBJsq1Ki2EIKIUZ8mydBhYi0 wVUXJVCLCrFN4DIEQdxIqdBIFsMkWD9YJClCRGKjJaviynjfe8RPogtXPcObuXPOPXd+PHj+Aeyo QNmobGLXVeANGM+GsP0B2yqHHNVoCD2LwLglVGZx7yXSlADR0uZu9C4Bpy3hUxPvH/cuUw6UoPCL h64I8KAJuMpwRU8uUMJy0OIpHVeXmulZoCc/t0LlTbJLEY1EudPRcnVjgAP5Osdl4K5HVP4+2bAI okaUA0Iq6Q59+Zy2eMWN6EpFTsa3+uD1+JKj4TPHuYTSMaLScLAaqk94YJqG4ds30hojOVgYoNJc NTztNU2TBYbhu9Aafnq08ORja37da1NwBrN/b7NVEc+b8yecuYkp08vNvLYneVZRaSH1vS0UnfHm OUPzWaZufHPmCWSdWrfeGVQQKmcsO4If8pAdXJ/xF4QQAeOVY1AQQcfirwkLUWeWVTgi6vaGt2xe BGzBEIMQorru8RxgPqY1V6uxYnwVBRZEI1ytCm3dE8mC2DgcbzCJGHdBEVDKuWDSwsrSGoqzJmNt 2jJpNueIH0qS8/0JrDKnVBdvOzIsdVr4zaX9dn9xcLLKdCtQGfutVacLE9Ja+yfbDvO4aMWrklfK /JYv15C8Kw9S10kup5Bys0N1bLdcn4HvTl/Xlh6Fpllwj5/XpH9BUXn/ym0Dvv7Rt2MywojpYiSi i7Hsscaa19zZ//y/hR+BT/ns80nmJAAAAABJRU5ErkJggg== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF74110CD873584BE0BE507C2" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at service2.sh.cvut.cz X-Spam-Status: No, hits=-2.2 tagged_above=-255.0 required=5.0 tests=AWL, CRM114_HAM_50, JR_RCVD_HOST_PROBS1, JR_RCVD_TOO_FEW_HOPS X-Spam-Level: Subject: Indication of extended attributes availability. 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, 21 Mar 2008 22:20:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF74110CD873584BE0BE507C2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I would like to have some sort of indication of extended attributes=20 availability for given FS. It seems that things like this (MAC, ACLs etc.= )=20 are indicated using mount flags and those are available through statfs() = call. The following is tentative patch that would expose extended attribu= tes=20 availability as mount flag. It is completely untested. I would just like = to=20 know if it is a viable approach to the problem or should I scratch it and= try=20 something else? --- ./sys/mount.h~ 2007-04-10 12:12:44.000000000 +0200 +++ ./sys/mount.h 2008-03-21 22:48:04.436630277 +0100 @@ -218,7 +218,6 @@ void __mnt_vnode_markerfree(str #define MNT_SYNCHRONOUS 0x00000002 /* filesystem written synchronously = */ #define MNT_NOEXEC 0x00000004 /* can't exec from filesystem */ #define MNT_NOSUID 0x00000008 /* don't honor setuid bits on fs */ -#define MNT_NODEV 0 /* Deprecated option */ #define MNT_UNION 0x00000020 /* union with underlying filesystem */ #define MNT_ASYNC 0x00000040 /* filesystem written asynchronously */ #define MNT_SUIDDIR 0x00100000 /* special handling of SUID on dirs */ @@ -246,6 +245,7 @@ void __mnt_vnode_markerfree(str * but visible to the user. * XXX some of these are not quite right.. (I've never seen the root fl= ag set) */ +#define MNT_EXTATTR 0x00000010 /* filesystem with extended attributes */= #define MNT_LOCAL 0x00001000 /* filesystem is stored locally */ #define MNT_QUOTA 0x00002000 /* quotas are enabled on filesystem */ #define MNT_ROOTFS 0x00004000 /* identifies the root filesystem */ @@ -265,7 +265,8 @@ void __mnt_vnode_markerfree(str MNT_ROOTFS | MNT_NOATIME | MNT_NOCLUSTERR| \ MNT_NOCLUSTERW | MNT_SUIDDIR | MNT_SOFTDEP | \ MNT_IGNORE | MNT_EXPUBLIC | MNT_NOSYMFOLLOW | \ - MNT_JAILDEVFS | MNT_MULTILABEL | MNT_ACLS) + MNT_JAILDEVFS | MNT_MULTILABEL | MNT_ACLS | \ + MNT_EXTATTR) /* Mask of flags that can be updated. */ #define MNT_UPDATEMASK (MNT_NOSUID | MNT_NOEXEC | \ --- ./ufs/ufs/ufs_extattr.c~ 2006-03-13 04:08:08.000000000 +0100 +++ ./ufs/ufs/ufs_extattr.c 2008-03-21 22:59:50.766939565 +0100 @@ -220,6 +220,10 @@ ufs_extattr_start(struct mount *mp, stru ump->um_extattr.uepm_ucred =3D crhold(td->td_ucred); + MNT_ILOCK(mp); + mp->f_flags |=3D MNT_EXTATTR; + MNT_IUNLOCK(mp); + unlock: ufs_extattr_uepm_unlock(ump, td); @@ -549,6 +553,10 @@ ufs_extattr_stop(struct mount *mp, struc uele->uele_attrname, td); } + MNT_ILOCK(mp); + mp->f_flags &=3D ~MNT_EXTATTR; + MNT_IUNLOCK(mp); + ump->um_extattr.uepm_flags &=3D ~UFS_EXTATTR_UEPM_STARTED; crfree(ump->um_extattr.uepm_ucred); -- VH --------------enigF74110CD873584BE0BE507C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5DSfoUFWwtEPkHIRCAEFAJ4uLX92ZBGnGvEw0laJw3Pc09PxlgCeM1RF T+Vv3VW0ngwqaYTxq3T2NVc= =uVTE -----END PGP SIGNATURE----- --------------enigF74110CD873584BE0BE507C2-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 21 22:50:42 2008 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 B97091065674 for ; Fri, 21 Mar 2008 22:50:42 +0000 (UTC) (envelope-from engywook@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 649998FC1C for ; Fri, 21 Mar 2008 22:50:42 +0000 (UTC) (envelope-from engywook@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1966232wxd.7 for ; Fri, 21 Mar 2008 15:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=fzMVqD/rrKqrzgAaUJngwES1d01qEGeN6dU1j9qvNDs=; b=kQEIQtPMnN2TRJsw8Z11BR1LpnSNqngsmr67B3FemsG4NSAPRT6YT2dQCLomMFWTN3YTvodP2VDRVq20liJua4XgLG6SxNZh4G0XuDp+wLwyBzm0GI5j6rJ+3z/+e1ZFiAEkgB5SJ5qPNexjxK062ngK7JY2jiiwZWXwOrgBYcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type; b=dbTdv8PWglVx4WH93KHhURDD3R5m3NAkQ5eabS1ubKAYfE+wj9RaB5YGs6to/Br9vElRkOPOKGTL0XNRHbas7aV7yY/R4cQj4vXYOE/CMKYEme/iYy2j8xt7ow7ud+ANT0+N/Wcuwzm03K/12VqNGwKEJoarbCd6V+fcQM52nW4= Received: by 10.70.50.3 with SMTP id x3mr4562386wxx.72.1206138089274; Fri, 21 Mar 2008 15:21:29 -0700 (PDT) Received: by 10.70.35.20 with HTTP; Fri, 21 Mar 2008 15:21:28 -0700 (PDT) Message-ID: <24adbbc00803211521t26b271e5wc8e3a27f228e29e4@mail.gmail.com> Date: Fri, 21 Mar 2008 23:21:28 +0100 From: "Daniel Andersson" To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A few questions about ZFS 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, 21 Mar 2008 22:50:43 -0000 Hiya! I've been thinking about trying out zfs for a while now. But as it is still kind of experimental I'm not sure if it'll be worth it. I'm currently running FBSD 7.0 i386 but if I go with zfs I'll probably reinstall to amd64. Anyhow, the box acts primarily as a fileserver/fw/router. It has only 1gb ram though, which seems to be the minimum according to things I've read. If rtorrent uses 900+mb ram, and zfs needs 1gb to run properly, what will happen? crash? Even if I got another gb of ram, would it work under heavy writing/reading? I would probably set up a /zfs for it and leave the root, usr, etc partitions to UFS2. http://groups.google.com/group/muc.lists.freebsd.current/browse_thread/thread/436fa863a6be7f24/a245a67bc6423b62?lnk=raot Doesn't seem promising, I rarely hash stuff though. If it starts crashing I would have to. Would I be better of setting up some softraid or vinum? dmesg: http://pastebin.org/24780 Cheers, Daniel Andersson P.S. How do I reply? RE: A few questions about ZFS in the subject? From owner-freebsd-fs@FreeBSD.ORG Sat Mar 22 00:54:12 2008 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 50A971065674 for ; Sat, 22 Mar 2008 00:54:12 +0000 (UTC) (envelope-from ender@enderzone.com) Received: from www.ksdhost.com (www.ksdhost.com [75.126.66.82]) by mx1.freebsd.org (Postfix) with ESMTP id E7BE78FC1F for ; Sat, 22 Mar 2008 00:54:11 +0000 (UTC) (envelope-from ender@enderzone.com) Received: (qmail 20609 invoked from network); 21 Mar 2008 19:54:11 -0500 Received: from 62.92.144.216.westtel.ky (HELO ?192.168.2.6?) (216.144.92.62) by www.ksdhost.com with SMTP; 21 Mar 2008 19:54:10 -0500 Message-ID: <47E45891.5010004@enderzone.com> Date: Fri, 21 Mar 2008 20:53:37 -0400 From: Ender User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Daniel Andersson References: <24adbbc00803211521t26b271e5wc8e3a27f228e29e4@mail.gmail.com> In-Reply-To: <24adbbc00803211521t26b271e5wc8e3a27f228e29e4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: A few questions about ZFS 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, 22 Mar 2008 00:54:12 -0000 Daniel Andersson wrote: > Hiya! > > I've been thinking about trying out zfs for a while now. But as it is still > kind of > experimental I'm not sure if it'll be worth it. I'm currently running FBSD > 7.0 i386 > but if I go with zfs I'll probably reinstall to amd64. Anyhow, the box acts > primarily as a fileserver/fw/router. It has only 1gb ram though, which seems > > to be the minimum according to things I've read. If rtorrent uses 900+mb > ram, > and zfs needs 1gb to run properly, what will happen? crash? Even if I got > another gb of ram, would it work under heavy writing/reading? I would > probably > set up a /zfs for it and leave the root, usr, etc partitions to UFS2. > > http://groups.google.com/group/muc.lists.freebsd.current/browse_thread/thread/436fa863a6be7f24/a245a67bc6423b62?lnk=raot > Doesn't seem promising, I rarely hash stuff though. If it starts crashing I > would have to. > > Would I be better of setting up some softraid or vinum? > > dmesg: > http://pastebin.org/24780 > > Cheers, > Daniel Andersson > > P.S. How do I reply? RE: A few questions about ZFS in the subject? > Even with AMD64 and a massive amount of ram (8+G) zfs will still crash under heavy load. Experimentation is always worth it, just do not use it for anything important. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 22 15:13:43 2008 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 39ECB1065672 for ; Sat, 22 Mar 2008 15:13:43 +0000 (UTC) (envelope-from engywook@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id EC42F8FC1E for ; Sat, 22 Mar 2008 15:13:42 +0000 (UTC) (envelope-from engywook@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so2284273wxd.7 for ; Sat, 22 Mar 2008 08:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=aZFczUxYW96/5B8NVWTWrEBNjBzsh/GI/pAK3tpbxMM=; b=lOSqxYg05S3ZYXtUhXGsQfse8q96EqZOuwfUXqku3OI9CMWOaRE3L11j/tE3rSubgEjmFr4/1xs9bo9eBmv0l7Drq29OAxrU0Gaw41sxZ82mWMu4lU7/mWwk3KwO3noN3r3Thdjot8G1SE2VkD+xadCF0fYnZgMSNry+udgZJ5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aTAMkR946Ed6oqSfzUXDzukn3gRtx2ds+ja7aw0naeZ6vjSmT7sEl46mSAyb5bcdeQfdTnlCtr/GJDgGnFHT4HZmyL7k+geLFkXEK5V6sG76cBrAOzPrn4cquzFCi1IEZKYQVCVKZwFTP0FkrSzddf97kJF2VrXJaoXfCD0wblI= Received: by 10.70.29.14 with SMTP id c14mr5848963wxc.86.1206198822011; Sat, 22 Mar 2008 08:13:42 -0700 (PDT) Received: by 10.70.35.20 with HTTP; Sat, 22 Mar 2008 08:13:41 -0700 (PDT) Message-ID: <24adbbc00803220813n5d0e4cd6r2f896e16365c6b36@mail.gmail.com> Date: Sat, 22 Mar 2008 16:13:41 +0100 From: "Daniel Andersson" To: Ender In-Reply-To: <47E45891.5010004@enderzone.com> MIME-Version: 1.0 References: <24adbbc00803211521t26b271e5wc8e3a27f228e29e4@mail.gmail.com> <47E45891.5010004@enderzone.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: A few questions about ZFS 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, 22 Mar 2008 15:13:43 -0000 Thanks for the reply! Would it still crash if I added two more disks to even out the load on the disks? Or will it still be a memory issue? On 22/03/2008, Ender wrote: > > Daniel Andersson wrote: > > Hiya! > > > > I've been thinking about trying out zfs for a while now. But as it is > still > > kind of > > experimental I'm not sure if it'll be worth it. I'm currently running > FBSD > > 7.0 i386 > > but if I go with zfs I'll probably reinstall to amd64. Anyhow, the box > acts > > primarily as a fileserver/fw/router. It has only 1gb ram though, which > seems > > > > to be the minimum according to things I've read. If rtorrent uses 900+mb > > ram, > > and zfs needs 1gb to run properly, what will happen? crash? Even if I > got > > another gb of ram, would it work under heavy writing/reading? I would > > probably > > set up a /zfs for it and leave the root, usr, etc partitions to UFS2. > > > > > http://groups.google.com/group/muc.lists.freebsd.current/browse_thread/thread/436fa863a6be7f24/a245a67bc6423b62?lnk=raot > > Doesn't seem promising, I rarely hash stuff though. If it starts > crashing I > > would have to. > > > > Would I be better of setting up some softraid or vinum? > > > > dmesg: > > http://pastebin.org/24780 > > > > Cheers, > > Daniel Andersson > > > > P.S. How do I reply? RE: A few questions about ZFS in the subject? > > > > > Even with AMD64 and a massive amount of ram (8+G) zfs will still crash > under heavy load. Experimentation is always worth it, just do not use it > for anything important. > From owner-freebsd-fs@FreeBSD.ORG Sat Mar 22 18:05:54 2008 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 2F6A81065672 for ; Sat, 22 Mar 2008 18:05:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E0E548FC1E for ; Sat, 22 Mar 2008 18:05:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8373046B3D; Sat, 22 Mar 2008 14:05:53 -0400 (EDT) Date: Sat, 22 Mar 2008 18:05:53 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= In-Reply-To: <47E43496.5080201@sh.cvut.cz> Message-ID: <20080322180253.B27442@fledge.watson.org> References: <47E43496.5080201@sh.cvut.cz> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1182643006-1206209153=:27442" Cc: freebsd-fs@freebsd.org Subject: Re: Indication of extended attributes availability. 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, 22 Mar 2008 18:05:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1182643006-1206209153=:27442 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 21 Mar 2008, V=E1clav Haisman wrote: > I would like to have some sort of indication of extended attributes=20 > availability for given FS. It seems that things like this (MAC, ACLs etc.= )=20 > are indicated using mount flags and those are available through statfs()= =20 > call. The following is tentative patch that would expose extended attribu= tes=20 > availability as mount flag. It is completely untested. I would just like = to=20 > know if it is a viable approach to the problem or should I scratch it and= =20 > try something else? I think the preferred programmatic approach is actually via fpathconf(2). = I=20 don't know if any other OS's have assigned a _PC constant for extended=20 attributes, but if they have we should probably use the same one. However,= I=20 guess there's a meta-question: is your goal to allow programs to be able to= =20 tell if extended attributes are available, or for administrators to be able= to=20 tell? Robert N M Watson Computer Laboratory University of Cambridge > > > --- ./sys/mount.h~=092007-04-10 12:12:44.000000000 +0200 > +++ ./sys/mount.h=092008-03-21 22:48:04.436630277 +0100 > @@ -218,7 +218,6 @@ void __mnt_vnode_markerfree(str > #define=09MNT_SYNCHRONOUS=090x00000002=09/* filesystem written=20 > synchronously */ > #define=09MNT_NOEXEC=090x00000004=09/* can't exec from filesystem=20 > */ > #define=09MNT_NOSUID=090x00000008=09/* don't honor setuid bits on=20 > fs */ > -#define=09MNT_NODEV=090=09=09/* Deprecated option */ > #define=09MNT_UNION=090x00000020=09/* union with underlying=20 > filesystem */ > #define=09MNT_ASYNC=090x00000040=09/* filesystem written=20 > asynchronously */ > #define=09MNT_SUIDDIR=090x00100000=09/* special handling of SUID=20 > on dirs */ > @@ -246,6 +245,7 @@ void __mnt_vnode_markerfree(str > * but visible to the user. > * XXX some of these are not quite right.. (I've never seen the root flag= =20 > set) > */ > +#define MNT_EXTATTR=090x00000010=09/* filesystem with extended=20 > attributes */ > #define=09MNT_LOCAL=090x00001000=09/* filesystem is stored=20 > locally */ > #define=09MNT_QUOTA=090x00002000=09/* quotas are enabled on=20 > filesystem */ > #define=09MNT_ROOTFS=090x00004000=09/* identifies the root=20 > filesystem */ > @@ -265,7 +265,8 @@ void __mnt_vnode_markerfree(str > =09=09=09MNT_ROOTFS=09| MNT_NOATIME=09| MNT_NOCLUSTERR| \ > =09=09=09MNT_NOCLUSTERW=09| MNT_SUIDDIR=09| MNT_SOFTDEP=09| \ > =09=09=09MNT_IGNORE=09| MNT_EXPUBLIC=09| MNT_NOSYMFOLLOW | \ > -=09=09=09MNT_JAILDEVFS=09| MNT_MULTILABEL | MNT_ACLS) > +=09=09=09MNT_JAILDEVFS=09| MNT_MULTILABEL | MNT_ACLS | \ > +=09=09=09MNT_EXTATTR) > > /* Mask of flags that can be updated. */ > #define=09MNT_UPDATEMASK (MNT_NOSUID=09| MNT_NOEXEC=09| \ > --- ./ufs/ufs/ufs_extattr.c~=092006-03-13 04:08:08.000000000 +0100 > +++ ./ufs/ufs/ufs_extattr.c=092008-03-21 22:59:50.766939565 +0100 > @@ -220,6 +220,10 @@ ufs_extattr_start(struct mount *mp, stru > > =09ump->um_extattr.uepm_ucred =3D crhold(td->td_ucred); > > +=09MNT_ILOCK(mp); > +=09mp->f_flags |=3D MNT_EXTATTR; > +=09MNT_IUNLOCK(mp); > + > unlock: > =09ufs_extattr_uepm_unlock(ump, td); > > @@ -549,6 +553,10 @@ ufs_extattr_stop(struct mount *mp, struc > =09=09 uele->uele_attrname, td); > =09} > > +=09MNT_ILOCK(mp); > +=09mp->f_flags &=3D ~MNT_EXTATTR; > +=09MNT_IUNLOCK(mp); > + > =09ump->um_extattr.uepm_flags &=3D ~UFS_EXTATTR_UEPM_STARTED; > > =09crfree(ump->um_extattr.uepm_ucred); > > -- > VH > > --621616949-1182643006-1206209153=:27442-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 22 19:41:49 2008 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 DABF71065672; Sat, 22 Mar 2008 19:41:49 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service1.sh.cvut.cz (service1.sh.cvut.cz [147.32.127.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2418FC1A; Sat, 22 Mar 2008 19:41:49 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service1.sh.cvut.cz (Postfix) with ESMTP id 7BF1B123723; Sat, 22 Mar 2008 20:19:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at service1.sh.cvut.cz X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-255 required=5 tests=[AWL=0.323, CRM114_HAM_00=, JR_RCVD_TOO_FEW_HOPS=0.6] Received: from service1.sh.cvut.cz ([127.0.0.1]) by localhost (service1.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Imynv7Eu5DFt; Sat, 22 Mar 2008 20:19:35 +0100 (CET) Received: from [192.168.1.2] (r4v24.net.upc.cz [84.42.149.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by service1.sh.cvut.cz (Postfix) with ESMTP id 38BB6123725; Sat, 22 Mar 2008 20:19:35 +0100 (CET) Message-ID: <47E55BC1.9080707@sh.cvut.cz> Date: Sat, 22 Mar 2008 20:19:29 +0100 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Robert Watson References: <47E43496.5080201@sh.cvut.cz> <20080322180253.B27442@fledge.watson.org> In-Reply-To: <20080322180253.B27442@fledge.watson.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig94CD03F1E67C4A600BF661CD" Cc: freebsd-fs@freebsd.org Subject: Re: Indication of extended attributes availability. 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, 22 Mar 2008 19:41:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig94CD03F1E67C4A600BF661CD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Robert Watson wrote, On 22.3.2008 19:05: >=20 > On Fri, 21 Mar 2008, V=C3=A1clav Haisman wrote: >=20 >> I would like to have some sort of indication of extended attributes=20 >> availability for given FS. It seems that things like this (MAC, ACLs=20 >> etc.) are indicated using mount flags and those are available through = >> statfs() call. The following is tentative patch that would expose=20 >> extended attributes availability as mount flag. It is completely=20 >> untested. I would just like to know if it is a viable approach to the = >> problem or should I scratch it and try something else? >=20 > I think the preferred programmatic approach is actually via=20 > fpathconf(2). I don't know if any other OS's have assigned a _PC=20 > constant for extended attributes, but if they have we should probably=20 > use the same one. However, I guess there's a meta-question: is your=20 > goal to allow programs to be able to tell if extended attributes are=20 > available, or for administrators to be able to tell? >=20 My original intent was to just extend /bin/cp with switch that would allo= w=20 copying of extended attributes together with the contents of files. When = I=20 looked at its source I noticed that it uses fpathconf() for querying for = ACLs=20 capability. Because I have not found extended attributes in fpathconf(2) = I=20 have looked at statfs(2) but there is nothing there either. So I thought = the=20 information would have to be conveyed to either of the syscalls somehow. = The=20 mnt_flag field of struct mount seems like a logical place to put the=20 information into. From there it seems it could be used by either fpathcon= f()=20 or statfs() or both. So, to answer the question, the goal is to allow programs to detect exten= ded=20 attributes availability. As to what other OSes do, Solaris mentions _PC_XATTR_ENABLED and=20 _PC_XATTR_EXISTS in fpathconf(2). -- VH --------------enig94CD03F1E67C4A600BF661CD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5VvIoUFWwtEPkHIRCACQAJ9fbZi+VN0qAEAhTKcNqiEFcaP/MACfdNXf wBW21UqyQWN0aPGr5yhEfPU= =75tu -----END PGP SIGNATURE----- --------------enig94CD03F1E67C4A600BF661CD-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 22 20:00:32 2008 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 043591065676 for ; Sat, 22 Mar 2008 20:00:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF92F8FC18 for ; Sat, 22 Mar 2008 20:00:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 29C7646B42; Sat, 22 Mar 2008 16:00:31 -0400 (EDT) Date: Sat, 22 Mar 2008 20:00:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= In-Reply-To: <47E55BC1.9080707@sh.cvut.cz> Message-ID: <20080322195758.K32322@fledge.watson.org> References: <47E43496.5080201@sh.cvut.cz> <20080322180253.B27442@fledge.watson.org> <47E55BC1.9080707@sh.cvut.cz> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1646158922-1206216031=:32322" Cc: freebsd-fs@freebsd.org Subject: Re: Indication of extended attributes availability. 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, 22 Mar 2008 20:00:32 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1646158922-1206216031=:32322 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 22 Mar 2008, V=E1clav Haisman wrote: >> I think the preferred programmatic approach is actually via fpathconf(2)= =2E I=20 >> don't know if any other OS's have assigned a _PC constant for extended= =20 >> attributes, but if they have we should probably use the same one.=20 >> However, I guess there's a meta-question: is your goal to allow programs= to=20 >> be able to tell if extended attributes are available, or for administrat= ors=20 >> to be able to tell? > > My original intent was to just extend /bin/cp with switch that would allo= w=20 > copying of extended attributes together with the contents of files. When = I=20 > looked at its source I noticed that it uses fpathconf() for querying for= =20 > ACLs capability. Because I have not found extended attributes in=20 > fpathconf(2) I have looked at statfs(2) but there is nothing there either= =2E=20 > So I thought the information would have to be conveyed to either of the= =20 > syscalls somehow. The mnt_flag field of struct mount seems like a logical= =20 > place to put the information into. From there it seems it could be used b= y=20 > either fpathconf() or statfs() or both. > > So, to answer the question, the goal is to allow programs to detect exten= ded=20 > attributes availability. > > As to what other OSes do, Solaris mentions _PC_XATTR_ENABLED and=20 > _PC_XATTR_EXISTS in fpathconf(2). mount flags are normally used for places where there is a desire to report = an=20 administrative setting, and on the whole, extended attributes are a propert= y=20 of the file system type, and not a per-mount setting. UFS1 extended=20 attributes are intended to be the exception rather than the rule. The way= =20 fpathconf() works inside the kernel is that the request is delivered direct= ly=20 to the file system that implements the target of the path provided, so it c= an=20 return information on whatever granularity it wants -- be it per-mount,=20 per-volume, etc. I think the Solaris model sounds pretty sensible, althoug= h=20 one thing worth considering is that Solari's extended attributes may, in fa= ct,=20 be file forks or streams, and called extended attributes due to NFSv4 using= =20 that terminology (an unfortunate overloading inconsistent with the use in m= any=20 OS's). In which case we might want to use a different name. It would be= =20 worth checking Linux and Mac OS X as well. Robert N M Watson Computer Laboratory University of Cambridge --621616949-1646158922-1206216031=:32322-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 22 20:49:29 2008 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 4A6F2106564A; Sat, 22 Mar 2008 20:49:29 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service1.sh.cvut.cz (service1.sh.cvut.cz [147.32.127.214]) by mx1.freebsd.org (Postfix) with ESMTP id BD06C8FC13; Sat, 22 Mar 2008 20:49:28 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service1.sh.cvut.cz (Postfix) with ESMTP id 40E3D12375B; Sat, 22 Mar 2008 21:49:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at service1.sh.cvut.cz X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-255 required=5 tests=[AWL=0.317, CRM114_HAM_00=, JR_RCVD_TOO_FEW_HOPS=0.6] Received: from service1.sh.cvut.cz ([127.0.0.1]) by localhost (service1.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWfExSKOA4-q; Sat, 22 Mar 2008 21:49:19 +0100 (CET) Received: from [192.168.1.2] (r4v24.net.upc.cz [84.42.149.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by service1.sh.cvut.cz (Postfix) with ESMTP id 26F1D1237A0; Sat, 22 Mar 2008 21:49:19 +0100 (CET) Message-ID: <47E570D2.8010502@sh.cvut.cz> Date: Sat, 22 Mar 2008 21:49:22 +0100 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Robert Watson References: <47E43496.5080201@sh.cvut.cz> <20080322180253.B27442@fledge.watson.org> <47E55BC1.9080707@sh.cvut.cz> <20080322195758.K32322@fledge.watson.org> In-Reply-To: <20080322195758.K32322@fledge.watson.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig54B26AFB8CBA7B89DA286B4A" Cc: freebsd-fs@freebsd.org Subject: Re: Indication of extended attributes availability. 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, 22 Mar 2008 20:49:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig54B26AFB8CBA7B89DA286B4A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Robert Watson wrote, On 22.3.2008 21:00: >[...] > mount flags are normally used for places where there is a desire to=20 > report an administrative setting, and on the whole, extended attributes= =20 > are a property of the file system type, and not a per-mount setting. =20 > UFS1 extended attributes are intended to be the exception rather than=20 > the rule. The way fpathconf() works inside the kernel is that the=20 > request is delivered directly to the file system that implements the=20 > target of the path provided, so it can return information on whatever=20 > granularity it wants -- be it per-mount, per-volume, etc. I think the = > Solaris model sounds pretty sensible, although one thing worth=20 > considering is that Solari's extended attributes may, in fact, be file = > forks or streams, and called extended attributes due to NFSv4 using tha= t=20 > terminology (an unfortunate overloading inconsistent with the use in=20 > many OS's). In which case we might want to use a different name. It=20 > would be worth checking Linux and Mac OS X as well. >=20 I have done some digging using the Man pages mirrors on www.freebsd.org. 1. Only Solaris has the _PC_XATTR_*. According to=20 =20 _PC_XATTR_* are really about extended attributes. Citation from the pag= e: "Not all implementations are able to, or want to, support the full model.= For=20 example, the implementation for the UFS file system allows only regular f= iles=20 as attributes (for example, no sub-directories) and rejects attempts to p= lace=20 attributes on attributes." This sounds close enough to what FreeBSD has. 2. Neither Linux nor Darwin seem to support querying availability of exte= nded=20 attributes even though they support their use using getxattr() etc. -- VH --------------enig54B26AFB8CBA7B89DA286B4A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5XDaoUFWwtEPkHIRCHjdAKCApzngtIyer0wOpwnnn2dbW7f08gCeO9Nf FWDhAt3gbuoEVsuHs8VUa+0= =CZeq -----END PGP SIGNATURE----- --------------enig54B26AFB8CBA7B89DA286B4A--