From owner-freebsd-fs@FreeBSD.ORG Sun Mar 23 10:03:23 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 75A1F1065670; Sun, 23 Mar 2008 10:03:23 +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 2056B8FC12; Sun, 23 Mar 2008 10:03:22 +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 CB1041237E3; Sun, 23 Mar 2008 11:03:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at service1.sh.cvut.cz X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-255 required=5 tests=[AWL=0.311, 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 xEK0ObyaV5nC; Sun, 23 Mar 2008 11:03:14 +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 E60141237E1; Sun, 23 Mar 2008 11:03:13 +0100 (CET) Message-ID: <47E62AB7.60300@sh.cvut.cz> Date: Sun, 23 Mar 2008 11:02:31 +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> <47E570D2.8010502@sh.cvut.cz> In-Reply-To: <47E570D2.8010502@sh.cvut.cz> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE9809CD5F3EDF331F4E842C6" 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: Sun, 23 Mar 2008 10:03:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE9809CD5F3EDF331F4E842C6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable What about ? It exte= nds=20 ufs_pathconf() with handling of _PC_XATTR_ENABLED. The patch is untested.= -- VH --------------enigE9809CD5F3EDF331F4E842C6 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 iD8DBQFH5irCoUFWwtEPkHIRCD7+AJ0ZcLjtRkgJwGJVQ7tYq2EBobtd9wCfXLAb 3JVmslaOkJEkrQS/F0w3I/U= =gYtn -----END PGP SIGNATURE----- --------------enigE9809CD5F3EDF331F4E842C6-- From owner-freebsd-fs@FreeBSD.ORG Sun Mar 23 11:05:41 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 D498D1065673; Sun, 23 Mar 2008 11:05:41 +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 A26218FC12; Sun, 23 Mar 2008 11:05:41 +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 22F9746B65; Sun, 23 Mar 2008 07:05:41 -0400 (EDT) Date: Sun, 23 Mar 2008 11:05:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= In-Reply-To: <47E62AB7.60300@sh.cvut.cz> Message-ID: <20080323110257.O80582@fledge.watson.org> References: <47E43496.5080201@sh.cvut.cz> <20080322180253.B27442@fledge.watson.org> <47E55BC1.9080707@sh.cvut.cz> <20080322195758.K32322@fledge.watson.org> <47E570D2.8010502@sh.cvut.cz> <47E62AB7.60300@sh.cvut.cz> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1592165432-1206270341=:80582" Cc: freebsd-fs@freebsd.org, pjd@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: Sun, 23 Mar 2008 11:05:41 -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-1592165432-1206270341=:80582 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 23 Mar 2008, V=E1clav Haisman wrote: > What about ? It exte= nds=20 > ufs_pathconf() with handling of _PC_XATTR_ENABLED. The patch is untested. I think it sounds fairly reasonable. However, the switch for ufs_pathconf(= )=20 appears to be missing the _PC_XATTR_EXISTS case? I'd probably panic rather than KASSERT() there. I'll also need to update the fpathconf(2) man page to list _PC_XATTR_*. Finally, I'm not convinced, having reread the fsattr man page on Solaris, t= hat=20 what they mean by XATTR is what we mean by extended attribute. However, I= =20 think that's a confusion fairly specific to Solaris and that we do have and= =20 apply a consistent meaning for extended attribute. A question for Pawel wo= uld=20 be how he plans to expose ZFS "extended attributes" (file streams) in FreeB= SD,=20 so I've CC'd him. Robert N M Watson Computer Laboratory University of Cambridge --621616949-1592165432-1206270341=:80582-- From owner-freebsd-fs@FreeBSD.ORG Sun Mar 23 12:25: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 719731065670 for ; Sun, 23 Mar 2008 12:25:59 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2108C8FC16 for ; Sun, 23 Mar 2008 12:25:58 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from shop.chemikals.org ([75.182.2.94]) by cdptpa-omta01.mail.rr.com with ESMTP id <20080323120029.CUOU13750.cdptpa-omta01.mail.rr.com@shop.chemikals.org>; Sun, 23 Mar 2008 12:00:29 +0000 Received: from volatile.chemikals.org (root@r74-193-170-223.bssrcmta01.bscyla.by.dh.suddenlink.net [74.193.170.223] (may be forged)) by shop.chemikals.org (8.14.1/8.14.1) with ESMTP id m2NC0S2v084026; Sun, 23 Mar 2008 08:00:28 -0400 (EDT) (envelope-from morganw@chemikals.org) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.2/8.14.2) with ESMTP id m2NC0QUd016775; Sun, 23 Mar 2008 07:00:27 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Sun, 23 Mar 2008 07:00:26 -0500 (CDT) From: Wes Morgan To: Daniel Andersson In-Reply-To: <24adbbc00803220813n5d0e4cd6r2f896e16365c6b36@mail.gmail.com> Message-ID: References: <24adbbc00803211521t26b271e5wc8e3a27f228e29e4@mail.gmail.com> <47E45891.5010004@enderzone.com> <24adbbc00803220813n5d0e4cd6r2f896e16365c6b36@mail.gmail.com> User-Agent: Alpine 1.00 (BSF 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sun, 23 Mar 2008 12:25:59 -0000 On Sat, 22 Mar 2008, Daniel Andersson wrote: > 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. I am using zfs with a 6-disk raidz (2.5tb) pool and another non-replicated pool as root. It is used as a media server/gateway/firewall. I've had no zfs related panics since moving to a core 2 cpu with 4gb ram. I think I've encountered the zfs/nfs deadlock twice, requiring a reboot each time. The load isn't stellar, but I was using it to rip/encode DVDs, download a dozen or so torrents and stream several media files all at the same time. The only instance where there was a hiccup was if I was extracting several large archives simultaneously, the media streamer would hiccup once or twice until the system compensated better for the sudden increase in disk I/O. All in all, with zfs, I feel like the two times I did have to reboot I avoided a lengthy fsck. The ability to scrub the disks and detect data corruption (which has not occurred) as well as the plusses of pooled storage without spending far too much on a raid controller outweigh any potential downsides. Now if only I could find a PCIe SATA controller with 4 or 8 ports that isn't one of those expensive RAIDs (prefer to invest more in disks than controllers). From owner-freebsd-fs@FreeBSD.ORG Sun Mar 23 22:36:10 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 5ED30106566B for ; Sun, 23 Mar 2008 22:36:10 +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 11C538FC24 for ; Sun, 23 Mar 2008 22:36:09 +0000 (UTC) (envelope-from engywook@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so2919665wxd.7 for ; Sun, 23 Mar 2008 15:36:09 -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:in-reply-to:mime-version:content-type:references; bh=rM5f1melRDlcI85H2/qfLOoH7DXNw72kHOHxpjO6C5A=; b=RZLlhagNINiI/PuE/KPPnCQp7x5tOJB3PB+Ueuydd/iFAHXbFM8sEqMzX+UjdYrqoJiARCjZV+39rjKHfiR7UmJfbln4/87xQe57iah5cQSi9SdFhO/PXp4O3tSqcnanMOlayYWYlReYGyDptr3ZNCO09mi5g0wTwWauH+DqzWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=n7QY+EOMgqFUepZqEfByHXr53tUWqp1NGEV1UMZLFWzXzGfbRY0rUsQ9cUkOpVsYPrrME6yjhsUKq9bFkm4SAmK+qq6oSdb2YpqNVN5iYrYx3Q/qtBuH68wxIyTVAUWjMQ3OCBfO308+hOic5Cn/lN28IovNv1eX246qAwnJsDU= Received: by 10.70.75.12 with SMTP id x12mr7917672wxa.68.1206311768916; Sun, 23 Mar 2008 15:36:08 -0700 (PDT) Received: by 10.70.35.20 with HTTP; Sun, 23 Mar 2008 15:36:08 -0700 (PDT) Message-ID: <24adbbc00803231536h7dd6cddey7a0244e1df9a48b9@mail.gmail.com> Date: Sun, 23 Mar 2008 23:36:08 +0100 From: "Daniel Andersson" To: freebsd-fs@freebsd.org In-Reply-To: <24adbbc00803211521t26b271e5wc8e3a27f228e29e4@mail.gmail.com> MIME-Version: 1.0 References: <24adbbc00803211521t26b271e5wc8e3a27f228e29e4@mail.gmail.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 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: Sun, 23 Mar 2008 22:36:10 -0000 That sounds promising! Too bad my server doesn't have that kind of hardware. =D Might try zfs after all. Got any recommendations on disks? preferrably 500gb. Then again, the size and make of the disks doesn't matter with zfs, does it? " I am using zfs with a 6-disk raidz (2.5tb) pool and another non-replicated pool as root. It is used as a media server/gateway/firewall. I've had no zfs related panics since moving to a core 2 cpu with 4gb ram. I think I've encountered the zfs/nfs deadlock twice, requiring a reboot each time. The load isn't stellar, but I was using it to rip/encode DVDs, download a dozen or so torrents and stream several media files all at the same time. The only instance where there was a hiccup was if I was extracting several large archives simultaneously, the media streamer would hiccup once or twice until the system compensated better for the sudden increase in disk I/O. All in all, with zfs, I feel like the two times I did have to reboot I avoided a lengthy fsck. The ability to scrub the disks and detect data corruption (which has not occurred) as well as the plusses of pooled storage without spending far too much on a raid controller outweigh any potential downsides. Now if only I could find a PCIe SATA controller with 4 or 8 ports that isn't one of those expensive RAIDs (prefer to invest more in disks than controllers)." From owner-freebsd-fs@FreeBSD.ORG Mon Mar 24 11:07:04 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 53BB41065678 for ; Mon, 24 Mar 2008 11:07:04 +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 524ED8FC20 for ; Mon, 24 Mar 2008 11:07:04 +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 m2OB74dk087769 for ; Mon, 24 Mar 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2OB73hV087765 for freebsd-fs@FreeBSD.org; Mon, 24 Mar 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2008 11:07:03 GMT Message-Id: <200803241107.m2OB73hV087765@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 11:07:04 -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 Mon Mar 24 19:07:14 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 D00021065674; Mon, 24 Mar 2008 19:07:14 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 710EB8FC1D; Mon, 24 Mar 2008 19:07:14 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2OIku98040601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Mar 2008 11:46:56 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <47E7F720.5080004@freebsd.org> Date: Mon, 24 Mar 2008 11:46:56 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Alfred Perlstein References: <20080314100155.GW67856@elvis.mu.org> In-Reply-To: <20080314100155.GW67856@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist 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, 24 Mar 2008 19:07:15 -0000 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. > This patch doesn't apply against HEAD. There are also gratuitous style changes. Looks fine, but please re-spin (and test against HEAD). Sam From owner-freebsd-fs@FreeBSD.ORG Mon Mar 24 20:55:05 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 E9192106566C for ; Mon, 24 Mar 2008 20:55:05 +0000 (UTC) (envelope-from qapf@qapf.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id C078A8FC26 for ; Mon, 24 Mar 2008 20:55:05 +0000 (UTC) (envelope-from qapf@qapf.com) Received: by wa-out-1112.google.com with SMTP id k17so3523803waf.3 for ; Mon, 24 Mar 2008 13:55:04 -0700 (PDT) Received: by 10.114.173.15 with SMTP id v15mr12248280wae.63.1206390604919; Mon, 24 Mar 2008 13:30:04 -0700 (PDT) Received: from ?192.168.1.139? ( [24.199.37.206]) by mx.google.com with ESMTPS id t1sm15104400poh.13.2008.03.24.13.30.03 (version=SSLv3 cipher=OTHER); Mon, 24 Mar 2008 13:30:04 -0700 (PDT) Message-Id: <1B17BAE7-D770-4035-8B56-35BD0A20EB3C@qapf.com> To: freebsd-fs@freebsd.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: Mon, 24 Mar 2008 13:30:02 -0700 X-Mailer: Apple Mail (2.919.2) From: Alex Frangis Subject: RE: ZFS zvol write speed incredibly slow X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 20:55:06 -0000 I just wanted to check in and say that I myself am encountering the same problem. I just got 7.0-Release online and working and I am seeing similar numbers to yours on a box that performed quite well running solaris. Configuration: AMD Semperon 3100+ 64bit Enabled 2gb Ram 3x 750GB Drives in a single Raid-Z Thanks, Alex Hi guys! I just got 7.0-RELEASE installed and running on my home server, and I've noticed incredibly slow write speeds to a ZFS zvol. Reading speeds seem normal. It may be related to the OpenSolaris bug #6428639: http://bugs.opensolaris.org/view_bug.do?bug_id=6428639 >> To another zpool: # dd if=junk of=/tank2/junk bs=65536 1024+0 records in 1024+0 records out 67108864 bytes transferred in 0.331802 secs (202255676 bytes/sec) >> To a zvol in the same pool: dd if=junk of=/dev/zvol/tank/tempvol bs=65536 1024+0 records in 1024+0 records out 67108864 bytes transferred in 11.575167 secs (5797658 bytes/sec) Using smaller block sizes exacerbates the problem (444606 bytes/sec with 4096-byte blocks!) From owner-freebsd-fs@FreeBSD.ORG Tue Mar 25 07:05:48 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 990091065675 for ; Tue, 25 Mar 2008 07:05:48 +0000 (UTC) (envelope-from cjc2007a@xemaps.com) Received: from web01-nyc.clicvu.com (web01-nyc.clicvu.com [69.18.197.228]) by mx1.freebsd.org (Postfix) with ESMTP id 434AF8FC27 for ; Tue, 25 Mar 2008 07:05:48 +0000 (UTC) (envelope-from cjc2007a@xemaps.com) Received: from [192.168.0.11] by web01-nyc.clicvu.com (Post.Office MTA v3.5.3 release 223 ID# 0-64039U1000L100S0V35) with SMTP id com for ; Tue, 25 Mar 2008 00:59:26 -0500 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id 5Hd31Z0041GXsucA702000; Tue, 25 Mar 2008 05:57:44 +0000 Received: from koalavm ([68.59.182.71]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 5Hyo1Z0021Yq1QL8T00000; Tue, 25 Mar 2008 05:58:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=UYSjntfoyeiAjeupoN8A:9 a=DFG7GC7o4CMMfoBRC1LptXrWTh4A:4 a=b8hG5vVbyAkA:10 From: cjc2007a@xemaps.com To: References: <20080321120012.CB3CA10656A4@hub.freebsd.org> Date: Tue, 25 Mar 2008 01:58:47 -0400 Message-ID: <001301c88e3d$4b1648c0$7f01000a@koalavm> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080321120012.CB3CA10656A4@hub.freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciLSydoJGKkP2pQR/mXNhWXsu0+yQC3nLJg Subject: ftp user cannot access ZFS partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 07:05:48 -0000 Hello, I have an AMD3800 box running FreeBSD-7.0-RELEASE, 2 x 80GB SATA drives (ad4 ad6) mirrored with geom_mirror for the OS, and 4 x 320GB SATA drives (ad10 ad12 ad14 ad16) all configured as ZFS - RAIDZ mode. This seems to work great, creating/deleting filesystems, snapshots, copying files to and from zfs, etc. The only problem is this is an ftp box (vsftpd at the moment), and I cannot get vsftpd to access a directory on the RAIDZ partition. $ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT zpool0 744G 2.3G 742G 0% ONLINE - $ zfs list NAME USED AVAIL REFER MOUNTPOINT zpool0 11.8G 536G 28.4K /zpool0 zpool0/data2 1.76G 536G 1.72G /zpool0/data2 (I have a subdir under data2 called ftp) The test user's home directory is /zpool0/data2/ftp When I ftp to the server, as soon as I enter the user's password I get: 500 OOPS: cannot change directory:/zpool/data2/ftp I don't get any more enlightening info from the vsftpd log. This is apparently a permissions issue, but the home directory belongs to this user, and I've opened permissions up to 777 on /zpool0/data2 and subdirs at the moment for testing. I can ftp in OK with a normal user chrooted to a home directory on the UFS partitions. Also if I disable chrooting for a user, I can login to a UFS folder OK, cd everywhere in the file tree, except I cannot cd to /zpool0/data2. I have tried another ftp server, PureFTP, with identical results, so the problem here is the ftp server won't cd to a directory on the ZRAID partition. I have Googled everything I can think of, with no hits on this topic. I've looked at ACLs, which are not implemented yet on FreeBSD. Any help on this problem would be appreciated. Thanks, Chris From owner-freebsd-fs@FreeBSD.ORG Tue Mar 25 18:47:45 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 3A014106564A; Tue, 25 Mar 2008 18:47:45 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id E12F68FC13; Tue, 25 Mar 2008 18:47:44 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from ws.su29.net (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 2B18037582E; Tue, 25 Mar 2008 18:29:36 +0000 (UTC) Message-ID: <47E9448F.1010304@ipfw.ru> Date: Tue, 25 Mar 2008 21:29:35 +0300 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.12 (X11/20080321) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 18:47:45 -0000 Hello people! At this moment unionfs has got at least following problems: 1) File systems cannot mount onto upper/lower unionfs layer (partially described in kern/117829) 2) There are problems with multithreaded programs accessing(writing) files on unionfs (kern/109950) 3) As well there are problems with accessing unix sockets created on upper/lower unionfs layers (kern/118346) 4) Doing mv filename same-filename causes kernel to panic on 6.X (and printing warning about VOP_RENAME in 7+) 5) Making 'loops' when mounting unionfs causes kernel panic (kern/121385) I have made patches solving first 4 problems These patches are available at http://ipfw.ru/patches/ unionfs2.diff fixes fs mounting onto upper layer, unionfs_lmount.diff fixes lower unionfs_threads.diff and unionfs_unix.diff fixes cases 2) and 3) unionfs_rename.diff fixes case with renaming Can anybody comment/review ? -- Alexander V. Chernikov MELI-RIPE From owner-freebsd-fs@FreeBSD.ORG Tue Mar 25 21:14:16 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 19C70106564A; Tue, 25 Mar 2008 21:14:16 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (unknown [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id C0E548FC18; Tue, 25 Mar 2008 21:14:15 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JeGTH-0006o7-M4; Tue, 25 Mar 2008 22:14:15 +0100 Date: Tue, 25 Mar 2008 22:14:15 +0100 From: Kurt Jaeger To: "Alexander V. Chernikov" Message-ID: <20080325211415.GD3180@home.opsec.eu> References: <47E9448F.1010304@ipfw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E9448F.1010304@ipfw.ru> Cc: freebsd-fs@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 21:14:16 -0000 Hi! > At this moment unionfs has got at least following problems: > 1) File systems cannot mount onto upper/lower unionfs layer (partially > described in kern/117829) I tested your patch as described in http://lists.freebsd.org/pipermail/freebsd-stable/2007-June/035798.html and /dev works for me now. Nice work! > 2) There are problems with multithreaded programs accessing(writing) files > on unionfs (kern/109950) > 3) As well there are problems with accessing unix sockets created on > upper/lower unionfs layers (kern/118346) > 4) Doing mv filename same-filename causes kernel to panic on 6.X (and > printing warning about VOP_RENAME in 7+) I tested this bug on a 6.3-REL with a 6.2 unionfs (20070213) and it does not panic. I tested it on a 6.3-REL with your patch and did also did not panic. So, from my point of view, it's an improvement. -- pi@opsec.eu +49 171 3101372 12 years to go ! From owner-freebsd-fs@FreeBSD.ORG Wed Mar 26 14:52: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 7E7E1106564A for ; Wed, 26 Mar 2008 14:52:21 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1B79F8FC16 for ; Wed, 26 Mar 2008 14:52:21 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id EFCD210D701C for ; Wed, 26 Mar 2008 15:23:34 +0100 (CET) Received: from chiller by eschew.pusen.org with local (Exim 4.67) (envelope-from ) id 1JeWXa-0004Mq-GT for freebsd-fs@freebsd.org; Wed, 26 Mar 2008 15:23:46 +0100 Date: Wed, 26 Mar 2008 15:23:46 +0100 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: freebsd-fs@freebsd.org Message-ID: <20080326142346.GA16062@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-PGP-Key: http://folk.uio.no/stalk/stalk.asc User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Strange ZFS behaviour when a drive fail. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 14:52:21 -0000 Hi, I have a a zpool containing two raidz-set, and one of the drive died. After a reboot the controller removed the disk and renumbered the other: NAME STATE READ WRITE CKSUM media DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 mfid1 ONLINE 0 0 0 6496191869544847902 FAULTED 0 0 0 was /dev/mfid2 mfid2 ONLINE 0 0 0 mfid3 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid4 ONLINE 0 0 0 mfid5 ONLINE 0 0 0 mfid6 ONLINE 0 0 0 mfid7 ONLINE 0 0 0 I have since gotten the drive online (as mfid8) and now strangely zfs reports that it is resilvering: scrub: resilver in progress, 1,11% done, 307445734561825779h49m to go But to what drive? zpool iostat shows that it reads alot from all the drives in the first raidz: capacity operations bandwidth pool used avail read write read write ----------------------- ----- ----- ----- ----- ----- ----- media 3,87T 949G 299 11 35,5M 51,4K raidz1 3,39T 253G 283 9 35,4M 46,8K mfid1 - - 148 15 11,8M 33,9K 6496191869544847902 - - 0 0 2,49K 0 mfid2 - - 147 15 11,8M 33,5K mfid3 - - 147 16 11,8M 32,3K raidz1 495G 695G 16 1 111K 4,63K mfid4 - - 10 1 336K 2,70K mfid5 - - 10 1 344K 2,70K mfid6 - - 11 1 385K 2,64K mfid7 - - 11 1 390K 2,22K This seems strange to me. PS: I then ran zpool replace media 6496191869544847902 mfid8 and got back: cannot replace 6496191869544847902 with mfid8: mfid8 is busy when I then ran zpool status I got: scrub: resilver completed with 0 errors on Wed Mar 26 15:15:50 2008 Why did it start to resilver onto "nothing", and why can't I replace it with mfid8 (even with -f)? -- Ståle Kristoffersen From owner-freebsd-fs@FreeBSD.ORG Wed Mar 26 14:53:26 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 B3E5D106566B; Wed, 26 Mar 2008 14:53:26 +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 649518FC1F; Wed, 26 Mar 2008 14:53:26 +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 2808C46B04; Wed, 26 Mar 2008 10:53:25 -0400 (EDT) Date: Wed, 26 Mar 2008 14:53:25 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Alexander V. Chernikov" In-Reply-To: <47E9448F.1010304@ipfw.ru> Message-ID: <20080326142115.K34007@fledge.watson.org> References: <47E9448F.1010304@ipfw.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 14:53:26 -0000 On Tue, 25 Mar 2008, Alexander V. Chernikov wrote: > I have made patches solving first 4 problems These patches are available at > http://ipfw.ru/patches/ unionfs2.diff fixes fs mounting onto upper layer, > unionfs_lmount.diff fixes lower unionfs_threads.diff and unionfs_unix.diff > fixes cases 2) and 3) unionfs_rename.diff fixes case with renaming > > Can anybody comment/review ? Dear Alexander, Unfortunately, I don't know too much about unionfs. However, I can comment on the UNIX domain socket patch: > --- sys/fs/unionfs/union_subr.c.orig 2008-03-13 23:10:32.000000000 +0300 > +++ sys/fs/unionfs/union_subr.c 2008-03-13 23:17:34.000000000 +0300 > @@ -160,6 +160,8 @@ > unp->un_path[cnp->cn_namelen] = '\0'; > } > vp->v_type = (uppervp != NULLVP ? uppervp->v_type : lowervp->v_type); > + if (vp->v_type == VSOCK) > + vp->v_socket = (uppervp != NULLVP) ? uppervp->v_socket : lowervp->v_socket; > if ((lowervp != NULLVP) && (lowervp->v_type == VDIR)) > vp->v_mountedhere = lowervp->v_mountedhere; > vp->v_data = unp; I'm a bit worried about this assignment, as it represents an untracked alias for the socket. Let me explain why: UNIX domain sockets may have file system bindings, allowing them to use the file system namespace as a rendezvous for communication. Typical use is that a socket is created, bind() is called on it with a path in some location like /var/run/log. Other processes turn up and connect() to the path, causing a file system lookup to reach the vnode of the socket, and then the socket code follows vp->v_socket to find the socket to connect to. When a bound socket is closed, we follow a back-pointer from the UNIX domain socket to the vnode, and then clear the pointer. Doing this in a race-free manner is somewhat tricky, and I'm not 100% convinced it's correct currently, although it appears to be somewhat close to right. The upshot of all this is that if you copy the pointer value to other vnodes, such as vnodes on upper layer, the UNIX domain socket code won't clear those pointers before freeing the socket they point at. This means that the above code snippet may lead to a v_socket pointer on a higher layer vnode pointing at the right socket, the wrong socket, or possibly some other bit of freed and maybe reused memory. You can imagine a number of schemes to replicate pointer changes around or track the various outstanding references, but I think a more fundamental question is whether this is in fact the right behavior at all. The premise of is that writes flow up, but not down, and "connections" to sockets are read-write events, not read events, most typically. If you're using unionfs to take a template system and "broadcast it" to many jails, you probably don't want all the jails talking to the same syslogd, you want them each talking to their own. When syslogd in a jail finds a disconnected socket, which is effectively what a NULL v_socket pointer means, in /var/run/log, it should be unlinking it and creating a new socket, not reusing the existing file on disk. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Wed Mar 26 15:10:07 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 A029E106564A for ; Wed, 26 Mar 2008 15:10:07 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 965ED8FC12 for ; Wed, 26 Mar 2008 15:10:07 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 75FA31CC068; Wed, 26 Mar 2008 08:10:07 -0700 (PDT) Date: Wed, 26 Mar 2008 08:10:07 -0700 From: Jeremy Chadwick To: =?iso-8859-1?Q?St=E5le?= Kristoffersen Message-ID: <20080326151007.GA87075@eos.sc1.parodius.com> References: <20080326142346.GA16062@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080326142346.GA16062@eschew.pusen.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-fs@freebsd.org Subject: Re: Strange ZFS behaviour when a drive fail. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 15:10:07 -0000 On Wed, Mar 26, 2008 at 03:23:46PM +0100, Ståle Kristoffersen wrote: > when I then ran zpool status I got: > scrub: resilver completed with 0 errors on Wed Mar 26 15:15:50 2008 > > Why did it start to resilver onto "nothing", and why can't I replace it with mfid8 (even with -f)? I believe this problem was stated back in January (see the 2nd half of the post), although Joe's problem showed an incremented CHKSUM, not an actual drive in FAULTED mode: http://lists.freebsd.org/pipermail/freebsd-fs/2008-January/004241.html Either way, the situation sounds very familiar (failure + reboot resulting in the pool silvering for strange reasons). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Wed Mar 26 15:59:01 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 A695F106566B; Wed, 26 Mar 2008 15:59:01 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA3F8FC12; Wed, 26 Mar 2008 15:59:01 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTP id 8F299125438; Thu, 27 Mar 2008 00:39:20 +0900 (JST) Message-ID: <47EA6E27.3060006@freebsd.org> Date: Thu, 27 Mar 2008 00:39:19 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.12 (X11/20080325) MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <47E9448F.1010304@ipfw.ru> In-Reply-To: <47E9448F.1010304@ipfw.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Kurt Jaeger , freebsd-current@FreeBSD.org, Robert Watson , dindin@yandex-team.ru Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 15:59:01 -0000 I should say that so sorry of my slow response. so sorry. We are developing unionfs step by step and still have 5 next patches. http://people.freebsd.org/~daichi/unionfs/experiments/ http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-1.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-2.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-3.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-4.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-5.diff p20-1: leads panic when "no error happens, eofflag is 0, response data is empty and DIAGNOSTIC is defined" while involving VOP_READDIR(9) from unionfs. This change fixes system hang-up using with NFS. p20-2: fixed fs access issue mounting on devfs. p20-3: fixed kern/109377. p20-4: fixed rename panic issue p20-5: fixed unix socket connection issue On our long unionfs running test, It looks like works very well. Would you try above patches? So sorry of my slow response. Please accept my deepest apology. We are planing to commit above patches to 8-current. 7-release has been done. It is good time to commit it to current ;) Alexander V. Chernikov wrote: > Hello people! > > At this moment unionfs has got at least following problems: > 1) File systems cannot mount onto upper/lower unionfs layer (partially > described in kern/117829) > 2) There are problems with multithreaded programs accessing(writing) > files on unionfs (kern/109950) > 3) As well there are problems with accessing unix sockets created on > upper/lower unionfs layers (kern/118346) > 4) Doing mv filename same-filename causes kernel to panic on 6.X (and > printing warning about VOP_RENAME in 7+) > 5) Making 'loops' when mounting unionfs causes kernel panic (kern/121385) > > I have made patches solving first 4 problems > These patches are available at http://ipfw.ru/patches/ > unionfs2.diff fixes fs mounting onto upper layer, unionfs_lmount.diff > fixes lower > unionfs_threads.diff and unionfs_unix.diff fixes cases 2) and 3) > unionfs_rename.diff fixes case with renaming > > Can anybody comment/review ? -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-fs@FreeBSD.ORG Wed Mar 26 23:23:34 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 623DD106566B for ; Wed, 26 Mar 2008 23:23:34 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 20A468FC1F for ; Wed, 26 Mar 2008 23:23:33 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id D79AC10D4BB6; Thu, 27 Mar 2008 00:23:19 +0100 (CET) Received: from chiller by eschew.pusen.org with local (Exim 4.67) (envelope-from ) id 1Jeexq-0005vD-Nj; Thu, 27 Mar 2008 00:23:26 +0100 Date: Thu, 27 Mar 2008 00:23:26 +0100 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Jeremy Chadwick Message-ID: <20080326232326.GG16062@eschew.pusen.org> References: <20080326142346.GA16062@eschew.pusen.org> <20080326151007.GA87075@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080326151007.GA87075@eos.sc1.parodius.com> X-PGP-Key: http://folk.uio.no/stalk/stalk.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-fs@freebsd.org Subject: Re: Strange ZFS behaviour when a drive fail. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 23:23:34 -0000 On 2008-03-26 at 08:10, Jeremy Chadwick wrote: > On Wed, Mar 26, 2008 at 03:23:46PM +0100, Ståle Kristoffersen wrote: > > when I then ran zpool status I got: > > scrub: resilver completed with 0 errors on Wed Mar 26 15:15:50 2008 > > > > Why did it start to resilver onto "nothing", and why can't I replace it with mfid8 (even with -f)? > > I believe this problem was stated back in January (see the 2nd half of > the post), although Joe's problem showed an incremented CHKSUM, not an > actual drive in FAULTED mode: > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-January/004241.html > > Either way, the situation sounds very familiar (failure + reboot > resulting in the pool silvering for strange reasons). Yeah, it looks like it could be the same thing. However, I fixed the last problem by writing over the last part of the drive with dd: dd if=/dev/zero of=/dev/mfid8 bs=1M seek=953300 I could then replace it and it started to resilver. Why didn't this happen automatically when I ran zpool replace -f? -- Ståle Kristoffersen From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 00:29:31 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 1DF021065672; Thu, 27 Mar 2008 00:29:31 +0000 (UTC) (envelope-from root@tao.org.uk) Received: from mailhost.tao.org.uk (tao.uscs.susx.ac.uk [139.184.131.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB368FC21; Thu, 27 Mar 2008 00:29:30 +0000 (UTC) (envelope-from root@tao.org.uk) Received: by mailhost.tao.org.uk (Postfix, from userid 0) id 0867D8ED7; Wed, 26 Mar 2008 23:58:19 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mailhost.tao.org.uk (Postfix) with ESMTP id A30AC7EC0 for ; Wed, 26 Mar 2008 14:55:17 +0000 (GMT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2B1C51A5CA0; Wed, 26 Mar 2008 14:53:39 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5C08410656EB; Wed, 26 Mar 2008 14:53:38 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E5D106566B; Wed, 26 Mar 2008 14:53:26 +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 649518FC1F; Wed, 26 Mar 2008 14:53:26 +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 2808C46B04; Wed, 26 Mar 2008 10:53:25 -0400 (EDT) Date: Wed, 26 Mar 2008 14:53:25 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Alexander V. Chernikov" In-Reply-To: <47E9448F.1010304@ipfw.ru> Message-ID: <20080326142115.K34007@fledge.watson.org> References: <47E9448F.1010304@ipfw.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-taoresearch-MailScanner-Information: Please contact Tao Research for more information X-taoresearch-MailScanner: Found to be clean X-MailScanner-From: root@tao.org.uk Cc: freebsd-fs@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 00:29:31 -0000 On Tue, 25 Mar 2008, Alexander V. Chernikov wrote: > I have made patches solving first 4 problems These patches are available at > http://ipfw.ru/patches/ unionfs2.diff fixes fs mounting onto upper layer, > unionfs_lmount.diff fixes lower unionfs_threads.diff and unionfs_unix.diff > fixes cases 2) and 3) unionfs_rename.diff fixes case with renaming > > Can anybody comment/review ? Dear Alexander, Unfortunately, I don't know too much about unionfs. However, I can comment on the UNIX domain socket patch: > --- sys/fs/unionfs/union_subr.c.orig 2008-03-13 23:10:32.000000000 +0300 > +++ sys/fs/unionfs/union_subr.c 2008-03-13 23:17:34.000000000 +0300 > @@ -160,6 +160,8 @@ > unp->un_path[cnp->cn_namelen] = '\0'; > } > vp->v_type = (uppervp != NULLVP ? uppervp->v_type : lowervp->v_type); > + if (vp->v_type == VSOCK) > + vp->v_socket = (uppervp != NULLVP) ? uppervp->v_socket : lowervp->v_socket; > if ((lowervp != NULLVP) && (lowervp->v_type == VDIR)) > vp->v_mountedhere = lowervp->v_mountedhere; > vp->v_data = unp; I'm a bit worried about this assignment, as it represents an untracked alias for the socket. Let me explain why: UNIX domain sockets may have file system bindings, allowing them to use the file system namespace as a rendezvous for communication. Typical use is that a socket is created, bind() is called on it with a path in some location like /var/run/log. Other processes turn up and connect() to the path, causing a file system lookup to reach the vnode of the socket, and then the socket code follows vp->v_socket to find the socket to connect to. When a bound socket is closed, we follow a back-pointer from the UNIX domain socket to the vnode, and then clear the pointer. Doing this in a race-free manner is somewhat tricky, and I'm not 100% convinced it's correct currently, although it appears to be somewhat close to right. The upshot of all this is that if you copy the pointer value to other vnodes, such as vnodes on upper layer, the UNIX domain socket code won't clear those pointers before freeing the socket they point at. This means that the above code snippet may lead to a v_socket pointer on a higher layer vnode pointing at the right socket, the wrong socket, or possibly some other bit of freed and maybe reused memory. You can imagine a number of schemes to replicate pointer changes around or track the various outstanding references, but I think a more fundamental question is whether this is in fact the right behavior at all. The premise of is that writes flow up, but not down, and "connections" to sockets are read-write events, not read events, most typically. If you're using unionfs to take a template system and "broadcast it" to many jails, you probably don't want all the jails talking to the same syslogd, you want them each talking to their own. When syslogd in a jail finds a disconnected socket, which is effectively what a NULL v_socket pointer means, in /var/run/log, it should be unlinking it and creating a new socket, not reusing the existing file on disk. Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 00:59: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 1AA88106564A; Thu, 27 Mar 2008 00:59:32 +0000 (UTC) (envelope-from root@tao.org.uk) Received: from mailhost.tao.org.uk (tao.uscs.susx.ac.uk [139.184.131.101]) by mx1.freebsd.org (Postfix) with ESMTP id A077C8FC22; Thu, 27 Mar 2008 00:59:31 +0000 (UTC) (envelope-from root@tao.org.uk) Received: by mailhost.tao.org.uk (Postfix, from userid 0) id 9CBEC8EC7; Wed, 26 Mar 2008 23:58:18 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mailhost.tao.org.uk (Postfix) with ESMTP id 9E01F7A3C for ; Wed, 26 Mar 2008 15:59:43 +0000 (GMT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C94811A58FA; Wed, 26 Mar 2008 15:59:16 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 00F33106568A; Wed, 26 Mar 2008 15:59:16 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A695F106566B; Wed, 26 Mar 2008 15:59:01 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA3F8FC12; Wed, 26 Mar 2008 15:59:01 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTP id 8F299125438; Thu, 27 Mar 2008 00:39:20 +0900 (JST) Message-ID: <47EA6E27.3060006@freebsd.org> Date: Thu, 27 Mar 2008 00:39:19 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.12 (X11/20080325) MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <47E9448F.1010304@ipfw.ru> In-Reply-To: <47E9448F.1010304@ipfw.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-taoresearch-MailScanner-Information: Please contact Tao Research for more information X-taoresearch-MailScanner: Found to be clean X-MailScanner-From: root@tao.org.uk Cc: freebsd-fs@freebsd.org, freebsd-current@FreeBSD.org, Kurt Jaeger , Robert Watson , dindin@yandex-team.ru Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 00:59:32 -0000 I should say that so sorry of my slow response. so sorry. We are developing unionfs step by step and still have 5 next patches. http://people.freebsd.org/~daichi/unionfs/experiments/ http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-1.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-2.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-3.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-4.diff http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-p20-5.diff p20-1: leads panic when "no error happens, eofflag is 0, response data is empty and DIAGNOSTIC is defined" while involving VOP_READDIR(9) from unionfs. This change fixes system hang-up using with NFS. p20-2: fixed fs access issue mounting on devfs. p20-3: fixed kern/109377. p20-4: fixed rename panic issue p20-5: fixed unix socket connection issue On our long unionfs running test, It looks like works very well. Would you try above patches? So sorry of my slow response. Please accept my deepest apology. We are planing to commit above patches to 8-current. 7-release has been done. It is good time to commit it to current ;) Alexander V. Chernikov wrote: > Hello people! > > At this moment unionfs has got at least following problems: > 1) File systems cannot mount onto upper/lower unionfs layer (partially > described in kern/117829) > 2) There are problems with multithreaded programs accessing(writing) > files on unionfs (kern/109950) > 3) As well there are problems with accessing unix sockets created on > upper/lower unionfs layers (kern/118346) > 4) Doing mv filename same-filename causes kernel to panic on 6.X (and > printing warning about VOP_RENAME in 7+) > 5) Making 'loops' when mounting unionfs causes kernel panic (kern/121385) > > I have made patches solving first 4 problems > These patches are available at http://ipfw.ru/patches/ > unionfs2.diff fixes fs mounting onto upper layer, unionfs_lmount.diff > fixes lower > unionfs_threads.diff and unionfs_unix.diff fixes cases 2) and 3) > unionfs_rename.diff fixes case with renaming > > Can anybody comment/review ? -- Daichi GOTO, http://people.freebsd.org/~daichi _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 05:40:05 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 9878C1065671 for ; Thu, 27 Mar 2008 05:40:05 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 562908FC25 for ; Thu, 27 Mar 2008 05:40:05 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JekqI-0004LB-Oi for freebsd-fs@freebsd.org; Thu, 27 Mar 2008 05:40:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 05:40:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 05:40:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.current Date: Thu, 27 Mar 2008 05:36:15 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 22 Message-ID: References: <47E9448F.1010304@ipfw.ru> <20080326142115.K34007@fledge.watson.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Robert Watson User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-current@freebsd.org Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 05:40:05 -0000 Hi Robert Watson! On Wed, 26 Mar 2008 14:53:25 +0000 (GMT); Robert Watson wrote about 'Re: unionfs status': > You can imagine a number of schemes to replicate pointer changes around or > track the various outstanding references, but I think a more fundamental > question is whether this is in fact the right behavior at all. The premise of > is that writes flow up, but not down, and "connections" to sockets are > read-write events, not read events, most typically. If you're using unionfs > to take a template system and "broadcast it" to many jails, you probably don't > want all the jails talking to the same syslogd, you want them each talking to > their own. When syslogd in a jail finds a disconnected socket, which is > effectively what a NULL v_socket pointer means, in /var/run/log, it should be > unlinking it and creating a new socket, not reusing the existing file on disk. This code's use in jails is primarily intended for mysql (and the like daemons), not syslogd (for which you said it right). Such daemons really require broadcasting, yep - so unionfs should support it... -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 06:25:58 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 02E45106566C; Thu, 27 Mar 2008 06:25:58 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (unknown [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id B34128FC15; Thu, 27 Mar 2008 06:25:57 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JelYi-000CgM-Qt; Thu, 27 Mar 2008 07:25:56 +0100 Date: Thu, 27 Mar 2008 07:25:56 +0100 From: Kurt Jaeger To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20080327062556.GE3180@home.opsec.eu> References: <47E9448F.1010304@ipfw.ru> <20080326142115.K34007@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 06:25:58 -0000 Vadim Goncharov wrote: > Robert Watson wrote: > > If you're using unionfs > > to take a template system and "broadcast it" to many jails, you probably don't > > want all the jails talking to the same syslogd, you want them each talking to > > their own. When syslogd in a jail finds a disconnected socket, which is > > effectively what a NULL v_socket pointer means, in /var/run/log, it should be > > unlinking it and creating a new socket, not reusing the existing file on disk. > This code's use in jails is primarily intended for mysql (and the like > daemons), not syslogd (for which you said it right). Such daemons really > require broadcasting, yep - so unionfs should support it... Thanks for this description. So we basically have two different uses for UNIX sockets in unionfs with jails ? 1) socket in jail to communicate only inside one jail (syslog-case) 2) socket in jail as a means of IPC between different jails (mysql-case) Is 2) really supposed to work like this ? -- pi@opsec.eu +49 171 3101372 12 years to go ! From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 07:00:05 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 9AF3D106566C for ; Thu, 27 Mar 2008 07:00:05 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 555E78FC28 for ; Thu, 27 Mar 2008 07:00:05 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Jem5j-0007XQ-2m for freebsd-fs@freebsd.org; Thu, 27 Mar 2008 07:00:03 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 07:00:03 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 07:00:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.current Date: Thu, 27 Mar 2008 06:51:37 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 30 Message-ID: References: <47E9448F.1010304@ipfw.ru> <20080326142115.K34007@fledge.watson.org> <20080327062556.GE3180@home.opsec.eu> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Kurt Jaeger User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-current@freebsd.org Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 07:00:05 -0000 Hi Kurt Jaeger! On Thu, 27 Mar 2008 07:25:56 +0100; Kurt Jaeger wrote about 'Re: unionfs status': >>> If you're using unionfs >>> to take a template system and "broadcast it" to many jails, you probably don't >>> want all the jails talking to the same syslogd, you want them each talking to >>> their own. When syslogd in a jail finds a disconnected socket, which is >>> effectively what a NULL v_socket pointer means, in /var/run/log, it should be >>> unlinking it and creating a new socket, not reusing the existing file on disk. >> This code's use in jails is primarily intended for mysql (and the like >> daemons), not syslogd (for which you said it right). Such daemons really >> require broadcasting, yep - so unionfs should support it... > Thanks for this description. So we basically have two different > uses for UNIX sockets in unionfs with jails ? > 1) socket in jail to communicate only inside one jail (syslog-case) > 2) socket in jail as a means of IPC between different jails (mysql-case) > Is 2) really supposed to work like this ? This is user's/admin's point of view, that it should work this way: one mysql with one socket for several jails. I don't know all gory details about how code really works. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 13:56:41 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 B67951065676; Thu, 27 Mar 2008 13:56:41 +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 72A898FC34; Thu, 27 Mar 2008 13:56:41 +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 4949846B96; Thu, 27 Mar 2008 09:56:40 -0400 (EDT) Date: Thu, 27 Mar 2008 13:56:40 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vadim Goncharov In-Reply-To: Message-ID: <20080327135318.R73942@fledge.watson.org> References: <47E9448F.1010304@ipfw.ru> <20080326142115.K34007@fledge.watson.org> <20080327062556.GE3180@home.opsec.eu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 13:56:41 -0000 On Thu, 27 Mar 2008, Vadim Goncharov wrote: >> Thanks for this description. So we basically have two different uses for >> UNIX sockets in unionfs with jails ? > >> 1) socket in jail to communicate only inside one jail (syslog-case) 2) >> socket in jail as a means of IPC between different jails (mysql-case) > >> Is 2) really supposed to work like this ? > > This is user's/admin's point of view, that it should work this way: one > mysql with one socket for several jails. I don't know all gory details about > how code really works. As I see it, nullfs should provide a shared socket, it is intended to provide access to the same object, and unionfs should provide independent sockets, as unionfs is intended to provide isolation. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 19:32:38 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 374611065670 for ; Thu, 27 Mar 2008 19:32:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 243968FC26 for ; Thu, 27 Mar 2008 19:32:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 27 Mar 2008 17:44:19 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 4EAA12D6010; Thu, 27 Mar 2008 12:22:12 -0700 (PDT) Message-ID: <47EBF3E4.4000607@elischer.org> Date: Thu, 27 Mar 2008 12:22:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Kurt Jaeger References: <47E9448F.1010304@ipfw.ru> <20080326142115.K34007@fledge.watson.org> <20080327062556.GE3180@home.opsec.eu> In-Reply-To: <20080327062556.GE3180@home.opsec.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: unionfs status X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 19:32:38 -0000 Kurt Jaeger wrote: > Vadim Goncharov wrote: >> Robert Watson wrote: > >>> If you're using unionfs >>> to take a template system and "broadcast it" to many jails, you probably don't >>> want all the jails talking to the same syslogd, you want them each talking to >>> their own. When syslogd in a jail finds a disconnected socket, which is >>> effectively what a NULL v_socket pointer means, in /var/run/log, it should be >>> unlinking it and creating a new socket, not reusing the existing file on disk. > >> This code's use in jails is primarily intended for mysql (and the like >> daemons), not syslogd (for which you said it right). Such daemons really >> require broadcasting, yep - so unionfs should support it... > > Thanks for this description. So we basically have two different > uses for UNIX sockets in unionfs with jails ? > > 1) socket in jail to communicate only inside one jail (syslog-case) > 2) socket in jail as a means of IPC between different jails (mysql-case) > > Is 2) really supposed to work like this ? think about it.. the socket is a file interface to a process. if you are reading the same socket, you expect to get the same process. in (1) you put the socket somewhere not shared. in (2) you put the socket somewhere shared. in nullfs you are allowing access to the same vnode via several namespaces positions. A new socket is visible to all jails. In unionfs a new socket would replace the old one and thus be only locally visible (refers to a different vnode to those accessed by the same name in other mounts). >