From owner-freebsd-fs@FreeBSD.ORG Sun Aug 5 18:25:07 2007 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 976EB16A419 for ; Sun, 5 Aug 2007 18:25:07 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id BA76B13C469 for ; Sun, 5 Aug 2007 18:25:06 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 56502 invoked from network); 5 Aug 2007 15:28:39 -0300 Received: by simscan 1.1.0 ppid: 56487, pid: 56494, t: 1.1537s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.1 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.17.230.107) by capeta.freebsdbrasil.com.br with SMTP; 5 Aug 2007 15:28:38 -0300 Message-ID: <46B615FE.9050803@freebsdbrasil.com.br> Date: Sun, 05 Aug 2007 15:25:02 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Eric Anderson , fs@freebsd.org References: <46B0F505.8090102@freebsdbrasil.com.br> <46B10798.5050504@freebsdbrasil.com.br> <200708011536.37926.matt@ixsystems.com> <46B12D0C.20808@freebsd.org> <46B1D167.4030206@freebsdbrasil.com.br> In-Reply-To: <46B1D167.4030206@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Xsan (Apple) on FreeBSD 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, 05 Aug 2007 18:25:07 -0000 >> I'd love to learn more about OneFS and the FreeBSD integration from >> someone at Isilon. It's a great success story that would be great to >> boast about on the FreeBSD website. > > I have contacted Isilon regarding FreeBSD usage and possibilities. If I > hear good news from someone there, maybe it is a conversation to start > on advocacy@. > >> >> Eric Just am update to this thread, Isilon people have contacted me back mentioning network file system access was the way to go right now, but a shared file system was on the plans. Now, today, I just found from a Seattle Post newspaper link something I really liked to see, a Job opportunity for FreeBSD developers aiming exactly this matter. And with a very, very promissing description: (reproducing) Software Engineer - FreeBSD Kernel Developer Tracking Code 2007136 Job Description Isilon Systems is the Leader in Clustered Storage. Each node in an Isilon Cluster runs an operating system based on FreeBSD. We're looking for FreeBSD Kernel Developers to join our team and build our technology in various areas: Requirements: * Geom, disks and disk scheduling * FreeBSD's TCP/IP stack * Client protocols (NFS/CIFS) * OFED/Infiniband * FreeBSD's UMA allocator * FreeBSD's VFS * Everything else you can imagine a distributed filesystem might need! The ideal candidate: * has more than 5 years of development, with at least two years working on a BSD kernel * has great team skills and likes to work hard and have fun * has a bachelor's degree in a science or mathematics * is a FreeBSD kernel committer Responsibilities include coding, debugging, shipping, maintaining and documenting products. In addition, a kernel committer will act as liaison with the FreeBSD project to commit useful Isilon technologies back to FreeBSD. FreeBSD has been a great choice for Isilon. Help us give back the things that we've improved over the years! Come find out about jobs at isilon!! A non-disclosure agreement must be signed prior to an interview. Isilon Systems is an equal opportunity employer. Relocation Available Job Location Seattle, WA, US. Position Type Full-Time/Regular (end reproducing) The (huge) link: http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&jobid=189932&company_id=15714&version=1&source=ONLINE&jobOwner=977329&aid=1 The very promissing sentence, in my understading: "In addition, a kernel committer will act as liaison with the FreeBSD project to commit useful Isilon technologies back to FreeBSD. FreeBSD has been a great choice for Isilon. Help us give back the things that we've improved over the years! Come find out about jobs at isilon!!" So, now I hope we will read more precise information about development on a shared file system on FreeBSD on the next quarterly report :) I hope interested commiters have already seen this job call. -- Patrick Tracanelli From owner-freebsd-fs@FreeBSD.ORG Sun Aug 5 20:40:13 2007 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 0343816A417 for ; Sun, 5 Aug 2007 20:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB96913C483 for ; Sun, 5 Aug 2007 20:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l75KeC0W056163 for ; Sun, 5 Aug 2007 20:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l75KeCfk056162; Sun, 5 Aug 2007 20:40:12 GMT (envelope-from gnats) Date: Sun, 5 Aug 2007 20:40:12 GMT Message-Id: <200708052040.l75KeCfk056162@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Craig Rodrigues Cc: Subject: Re: bin/115165: [PATCH] amd(8): add functionality of mount_nfs' -L -a -d options to amd X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Craig Rodrigues List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2007 20:40:13 -0000 The following reply was made to PR bin/115165; it has been noted by GNATS. From: Craig Rodrigues To: bug-followup@FreeBSD.org, Andre.Albsmeier@siemens.com Cc: Subject: Re: bin/115165: [PATCH] amd(8): add functionality of mount_nfs' -L -a -d options to amd Date: Sun, 5 Aug 2007 16:37:22 -0400 Hi, These changes need to be submitted to the am-utils maintainer, since FreeBSD imports the am-utils from: http://www.am-utils.org/ -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-fs@FreeBSD.ORG Mon Aug 6 11:08:17 2007 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 D4C2216A469 for ; Mon, 6 Aug 2007 11:08:17 +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 C191713C467 for ; Mon, 6 Aug 2007 11:08:17 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l76B8HAi029849 for ; Mon, 6 Aug 2007 11:08:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l76B8G1k029845 for freebsd-fs@FreeBSD.org; Mon, 6 Aug 2007 11:08:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Aug 2007 11:08:16 GMT Message-Id: <200708061108.l76B8G1k029845@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 you 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, 06 Aug 2007 11:08:18 -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/114856 fs [ntfs] [patch] Bug in NTFS allows bogus file modes. o bin/115165 fs [PATCH] amd(8): add functionality of mount_nfs' -L -a 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/114847 fs [ntfs] [patch] dirmask support for NTFS ala MSDOSFS 1 problem total. From owner-freebsd-fs@FreeBSD.ORG Tue Aug 7 07:40:10 2007 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 AC43816A41A for ; Tue, 7 Aug 2007 07:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7665213C467 for ; Tue, 7 Aug 2007 07:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l777eAXa099828 for ; Tue, 7 Aug 2007 07:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l777eAoQ099824; Tue, 7 Aug 2007 07:40:10 GMT (envelope-from gnats) Date: Tue, 7 Aug 2007 07:40:10 GMT Message-Id: <200708070740.l777eAoQ099824@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andre Albsmeier Cc: Subject: Re: bin/115165: [PATCH] amd(8): add functionality of mount_nfs' -L -a -d options to amd X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andre Albsmeier List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2007 07:40:10 -0000 The following reply was made to PR bin/115165; it has been noted by GNATS. From: Andre Albsmeier To: Craig Rodrigues Cc: bug-followup@FreeBSD.org, Andre.Albsmeier@siemens.com Subject: Re: bin/115165: [PATCH] amd(8): add functionality of mount_nfs' -L -a -d options to amd Date: Tue, 7 Aug 2007 09:17:52 +0200 On Sun, 05-Aug-2007 at 16:37:22 -0400, Craig Rodrigues wrote: > Hi, > > These changes need to be submitted to the am-utils maintainer, > since FreeBSD imports the am-utils from: > > http://www.am-utils.org/ Done, https://bugzilla.fsl.cs.sunysb.edu/show_bug.cgi?id=582 From owner-freebsd-fs@FreeBSD.ORG Tue Aug 7 14:48:12 2007 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 5CC2216A417; Tue, 7 Aug 2007 14:48:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id D67E913C459; Tue, 7 Aug 2007 14:48:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l77Em7OI024496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 00:48:09 +1000 Date: Wed, 8 Aug 2007 00:48:06 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20070804075730.GP2738@deviant.kiev.zoral.com.ua> Message-ID: <20070808004001.O926@besplex.bde.org> References: <20070710233455.O2101@besplex.bde.org> <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070712225324.F9515@besplex.bde.org> <20070712142127.GD2200@deviant.kiev.zoral.com.ua> <20070716195556.P12807@besplex.bde.org> <20070721063434.GI2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bugs@FreeBSD.org, fs@FreeBSD.org Subject: Re: msdosfs not MPSAFE 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, 07 Aug 2007 14:48:12 -0000 On Sat, 4 Aug 2007, Kostik Belousov wrote: > On Sat, Jul 21, 2007 at 11:52:04PM +1000, Bruce Evans wrote: >> On Sat, 21 Jul 2007, Kostik Belousov wrote: >> >>> On Mon, Jul 16, 2007 at 08:18:14PM +1000, Bruce Evans wrote: >> Next try: move locking into the inner loop in msdosfs_lookup(). Unlocking >> is not as ugly as I feared. The following has only been tested at compile >> time: >> ... >> After moving the locking into msdosfs_conv.c and adding assertions there, >> this should be a good enough fix until the mbnambuf interface is changed. >> This bug is in all versions since 5.2-RELEASE. > > Once again, sorry for late answer. > The change seems to be good. Thanks. Here is a cleaned up version for -current for further review. I can't see how to do it cleanly without all the little functions. It also fixes a memory leak on module unload, and some style bugs in msdosfs_vfsops.c. This has been tested lightly runtime. Module unload has not been tested at all (I don't use modules). %%% Index: direntry.h =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/direntry.h,v retrieving revision 1.23 diff -u -2 -r1.23 direntry.h --- direntry.h 24 Oct 2006 11:14:05 -0000 1.23 +++ direntry.h 7 Aug 2007 11:51:16 -0000 @@ -137,6 +137,10 @@ struct msdosfsmount; +void mbnambuf_acquire(void); +void mbnambuf_create(void); +void mbnambuf_destroy(void); char *mbnambuf_flush(struct dirent *dp); void mbnambuf_init(void); +void mbnambuf_release(void); void mbnambuf_write(char *name, int id); int dos2unixfn(u_char dn[11], u_char *un, int lower, Index: msdosfs_conv.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_conv.c,v retrieving revision 1.52 diff -u -2 -r1.52 msdosfs_conv.c --- msdosfs_conv.c 7 Aug 2007 02:11:16 -0000 1.52 +++ msdosfs_conv.c 7 Aug 2007 12:18:03 -0000 @@ -53,6 +53,9 @@ #include #include +#include #include #include +#include +#include #include @@ -68,4 +71,5 @@ static u_int16_t unix2winchr(const u_char **, size_t *, int, struct msdosfsmount *); +static struct sx nambuf_lock; static char *nambuf_ptr; static size_t nambuf_len; @@ -1038,6 +1042,36 @@ /* - * Initialize the temporary concatenation buffer (once) and mark it as - * empty on subsequent calls. + * nambuf is static, so it must be locked for exclusive access even in the + * non-SMP case, since although msdosfs is Giant-locked, calls like bread() + * which can block are made while nambuf is in use. + */ +void +mbnambuf_acquire(void) +{ + + sx_xlock(&nambuf_lock); +} + +void +mbnambuf_create(void) +{ + + KASSERT(nambuf_ptr == NULL, ("mbnambuf_create: already created")); + nambuf_ptr = malloc(MAXNAMLEN + 1, M_MSDOSFSMNT, M_WAITOK); + nambuf_ptr[MAXNAMLEN] = '\0'; + sx_init(&nambuf_lock, "mbnambuf"); +} + +void +mbnambuf_destroy(void) +{ + + free(nambuf_ptr, M_MSDOSFSMNT); + nambuf_ptr = NULL; + sx_destroy(&nambuf_lock); +} + +/* + * Mark the temporary concatenation buffer as empty. */ void @@ -1045,12 +1079,15 @@ { - if (nambuf_ptr == NULL) { - nambuf_ptr = malloc(MAXNAMLEN + 1, M_MSDOSFSMNT, M_WAITOK); - nambuf_ptr[MAXNAMLEN] = '\0'; - } nambuf_len = 0; nambuf_last_id = -1; } +void +mbnambuf_release(void) +{ + + sx_xunlock(&nambuf_lock); +} + /* * Fill out our concatenation buffer with the given substring, at the offset Index: msdosfs_lookup.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v retrieving revision 1.50 diff -u -2 -r1.50 msdosfs_lookup.c --- msdosfs_lookup.c 7 Aug 2007 02:25:56 -0000 1.50 +++ msdosfs_lookup.c 7 Aug 2007 11:51:16 -0000 @@ -186,4 +186,5 @@ */ tdp = NULL; + mbnambuf_acquire(); mbnambuf_init(); /* @@ -200,4 +201,5 @@ if (error == E2BIG) break; + mbnambuf_release(); return (error); } @@ -205,4 +207,5 @@ if (error) { brelse(bp); + mbnambuf_release(); return (error); } @@ -234,4 +237,5 @@ if (dep->deName[0] == SLOT_EMPTY) { brelse(bp); + mbnambuf_release(); goto notfound; } @@ -310,4 +314,5 @@ } + mbnambuf_release(); goto found; } @@ -319,4 +324,5 @@ brelse(bp); } /* for (frcn = 0; ; frcn++) */ + mbnambuf_release(); notfound: Index: msdosfs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vfsops.c,v retrieving revision 1.173 diff -u -2 -r1.173 msdosfs_vfsops.c --- msdosfs_vfsops.c 7 Aug 2007 03:38:36 -0000 1.173 +++ msdosfs_vfsops.c 7 Aug 2007 12:07:37 -0000 @@ -104,9 +104,5 @@ static int mountmsdosfs(struct vnode *devvp, struct mount *mp, struct thread *td); -static vfs_fhtovp_t msdosfs_fhtovp; -static vfs_mount_t msdosfs_mount; static vfs_root_t msdosfs_root; -static vfs_statfs_t msdosfs_statfs; -static vfs_sync_t msdosfs_sync; static vfs_unmount_t msdosfs_unmount; @@ -939,11 +935,29 @@ } +static int +msdosfs_init(struct vfsconf *vfsp) +{ + + mbnambuf_create(); + return (0); +} + +static int +msdosfs_uninit(struct vfsconf *vfsp) +{ + + mbnambuf_destroy(); + return (0); +} + static struct vfsops msdosfs_vfsops = { + .vfs_cmount = msdosfs_cmount, .vfs_fhtovp = msdosfs_fhtovp, + .vfs_init = msdosfs_init, .vfs_mount = msdosfs_mount, - .vfs_cmount = msdosfs_cmount, .vfs_root = msdosfs_root, .vfs_statfs = msdosfs_statfs, .vfs_sync = msdosfs_sync, + .vfs_uninit = msdosfs_uninit, .vfs_unmount = msdosfs_unmount, }; Index: msdosfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v retrieving revision 1.178 diff -u -2 -r1.178 msdosfs_vnops.c --- msdosfs_vnops.c 7 Aug 2007 10:35:27 -0000 1.178 +++ msdosfs_vnops.c 7 Aug 2007 11:55:27 -0000 @@ -1630,4 +1630,5 @@ } + mbnambuf_acquire(); mbnambuf_init(); off = offset; @@ -1646,10 +1647,11 @@ if (error) { brelse(bp); - return (error); + break; } n = min(n, blsize - bp->b_resid); if (n == 0) { brelse(bp); - return (EIO); + error = EIO; + break; } @@ -1765,4 +1767,6 @@ } out: + mbnambuf_release(); + /* Subtract unused cookies */ if (ap->a_ncookies) %%% Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Aug 7 18:01:00 2007 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 B289516A46E; Tue, 7 Aug 2007 18:01:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4C21C13C4B6; Tue, 7 Aug 2007 18:01:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IITMR-0008dw-5t; Tue, 07 Aug 2007 21:00:58 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l77H30lf095871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2007 20:03:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l77H30Y9099979; Tue, 7 Aug 2007 20:03:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l77H2x4g099978; Tue, 7 Aug 2007 20:02:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Aug 2007 20:02:59 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> References: <20070710233455.O2101@besplex.bde.org> <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070712225324.F9515@besplex.bde.org> <20070712142127.GD2200@deviant.kiev.zoral.com.ua> <20070716195556.P12807@besplex.bde.org> <20070721063434.GI2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> <20070808004001.O926@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ISA6zNVXmTIvvkD5" Content-Disposition: inline In-Reply-To: <20070808004001.O926@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 7bc32d9c6161d64a6ed1bdcc9b38fdca X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1351 [August 7 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: bugs@FreeBSD.org, fs@FreeBSD.org Subject: Re: msdosfs not MPSAFE 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, 07 Aug 2007 18:01:00 -0000 --ISA6zNVXmTIvvkD5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 08, 2007 at 12:48:06AM +1000, Bruce Evans wrote: > Here is a cleaned up version for -current for further review. I can't > see how to do it cleanly without all the little functions. It also > fixes a memory leak on module unload, and some style bugs in > msdosfs_vfsops.c. This has been tested lightly runtime. Module unload > has not been tested at all (I don't use modules). Why not allocate nambuf statically ? It seems that using functions for mbnambuf_acquire()/mbnambuf_release() causes unneeded overhead. Macros could be used as well. Anyway, these notes are not objections against patch. >=20 > %%% > Index: direntry.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/fs/msdosfs/direntry.h,v > retrieving revision 1.23 > diff -u -2 -r1.23 direntry.h > --- direntry.h 24 Oct 2006 11:14:05 -0000 1.23 > +++ direntry.h 7 Aug 2007 11:51:16 -0000 > @@ -137,6 +137,10 @@ > struct msdosfsmount; >=20 > +void mbnambuf_acquire(void); > +void mbnambuf_create(void); > +void mbnambuf_destroy(void); > char *mbnambuf_flush(struct dirent *dp); > void mbnambuf_init(void); > +void mbnambuf_release(void); > void mbnambuf_write(char *name, int id); > int dos2unixfn(u_char dn[11], u_char *un, int lower, > Index: msdosfs_conv.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_conv.c,v > retrieving revision 1.52 > diff -u -2 -r1.52 msdosfs_conv.c > --- msdosfs_conv.c 7 Aug 2007 02:11:16 -0000 1.52 > +++ msdosfs_conv.c 7 Aug 2007 12:18:03 -0000 > @@ -53,6 +53,9 @@ > #include > #include > +#include > #include > #include > +#include > +#include >=20 > #include > @@ -68,4 +71,5 @@ > static u_int16_t unix2winchr(const u_char **, size_t *, int, struct=20 > msdosfsmount *); >=20 > +static struct sx nambuf_lock; > static char *nambuf_ptr; > static size_t nambuf_len; > @@ -1038,6 +1042,36 @@ >=20 > /* > - * Initialize the temporary concatenation buffer (once) and mark it as > - * empty on subsequent calls. > + * nambuf is static, so it must be locked for exclusive access even in t= he > + * non-SMP case, since although msdosfs is Giant-locked, calls like brea= d() > + * which can block are made while nambuf is in use. > + */ > +void > +mbnambuf_acquire(void) > +{ > + > + sx_xlock(&nambuf_lock); > +} > + > +void > +mbnambuf_create(void) > +{ > + > + KASSERT(nambuf_ptr =3D=3D NULL, ("mbnambuf_create: already created")); > + nambuf_ptr =3D malloc(MAXNAMLEN + 1, M_MSDOSFSMNT, M_WAITOK); > + nambuf_ptr[MAXNAMLEN] =3D '\0'; > + sx_init(&nambuf_lock, "mbnambuf"); > +} > + > +void > +mbnambuf_destroy(void) > +{ > + > + free(nambuf_ptr, M_MSDOSFSMNT); > + nambuf_ptr =3D NULL; > + sx_destroy(&nambuf_lock); > +} > + > +/* > + * Mark the temporary concatenation buffer as empty. > */ > void > @@ -1045,12 +1079,15 @@ > { >=20 > - if (nambuf_ptr =3D=3D NULL) {=20 > - nambuf_ptr =3D malloc(MAXNAMLEN + 1, M_MSDOSFSMNT, M_WAITOK); > - nambuf_ptr[MAXNAMLEN] =3D '\0'; > - } > nambuf_len =3D 0; > nambuf_last_id =3D -1; > } >=20 > +void > +mbnambuf_release(void) > +{ > + > + sx_xunlock(&nambuf_lock); > +} > + > /* > * Fill out our concatenation buffer with the given substring, at the=20 > offset > Index: msdosfs_lookup.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v > retrieving revision 1.50 > diff -u -2 -r1.50 msdosfs_lookup.c > --- msdosfs_lookup.c 7 Aug 2007 02:25:56 -0000 1.50 > +++ msdosfs_lookup.c 7 Aug 2007 11:51:16 -0000 > @@ -186,4 +186,5 @@ > */ > tdp =3D NULL; > + mbnambuf_acquire(); > mbnambuf_init(); > /* > @@ -200,4 +201,5 @@ > if (error =3D=3D E2BIG) > break; > + mbnambuf_release(); > return (error); > } > @@ -205,4 +207,5 @@ > if (error) { > brelse(bp); > + mbnambuf_release(); > return (error); > } > @@ -234,4 +237,5 @@ > if (dep->deName[0] =3D=3D SLOT_EMPTY) { > brelse(bp); > + mbnambuf_release(); > goto notfound; > } > @@ -310,4 +314,5 @@ > } >=20 > + mbnambuf_release(); > goto found; > } > @@ -319,4 +324,5 @@ > brelse(bp); > } /* for (frcn =3D 0; ; frcn++) */ > + mbnambuf_release(); >=20 > notfound: > Index: msdosfs_vfsops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vfsops.c,v > retrieving revision 1.173 > diff -u -2 -r1.173 msdosfs_vfsops.c > --- msdosfs_vfsops.c 7 Aug 2007 03:38:36 -0000 1.173 > +++ msdosfs_vfsops.c 7 Aug 2007 12:07:37 -0000 > @@ -104,9 +104,5 @@ > static int mountmsdosfs(struct vnode *devvp, struct mount *mp, > struct thread *td); > -static vfs_fhtovp_t msdosfs_fhtovp; > -static vfs_mount_t msdosfs_mount; > static vfs_root_t msdosfs_root; > -static vfs_statfs_t msdosfs_statfs; > -static vfs_sync_t msdosfs_sync; > static vfs_unmount_t msdosfs_unmount; >=20 > @@ -939,11 +935,29 @@ > } >=20 > +static int > +msdosfs_init(struct vfsconf *vfsp) > +{ > + > + mbnambuf_create(); > + return (0); > +} > + > +static int > +msdosfs_uninit(struct vfsconf *vfsp) > +{ > + > + mbnambuf_destroy(); > + return (0); > +} > + > static struct vfsops msdosfs_vfsops =3D { > + .vfs_cmount =3D msdosfs_cmount, > .vfs_fhtovp =3D msdosfs_fhtovp, > + .vfs_init =3D msdosfs_init, > .vfs_mount =3D msdosfs_mount, > - .vfs_cmount =3D msdosfs_cmount, > .vfs_root =3D msdosfs_root, > .vfs_statfs =3D msdosfs_statfs, > .vfs_sync =3D msdosfs_sync, > + .vfs_uninit =3D msdosfs_uninit, > .vfs_unmount =3D msdosfs_unmount, > }; > Index: msdosfs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v > retrieving revision 1.178 > diff -u -2 -r1.178 msdosfs_vnops.c > --- msdosfs_vnops.c 7 Aug 2007 10:35:27 -0000 1.178 > +++ msdosfs_vnops.c 7 Aug 2007 11:55:27 -0000 > @@ -1630,4 +1630,5 @@ > } >=20 > + mbnambuf_acquire(); > mbnambuf_init(); > off =3D offset; > @@ -1646,10 +1647,11 @@ > if (error) { > brelse(bp); > - return (error); > + break; > } > n =3D min(n, blsize - bp->b_resid); > if (n =3D=3D 0) { > brelse(bp); > - return (EIO); > + error =3D EIO; > + break; > } >=20 > @@ -1765,4 +1767,6 @@ > } > out: > + mbnambuf_release(); > + > /* Subtract unused cookies */ > if (ap->a_ncookies) > %%% >=20 > Bruce --ISA6zNVXmTIvvkD5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGuKXDC3+MBN1Mb4gRAoTVAKCOgm0BH7z4eg8bFyNwNBsI3AXs4gCcDUIt j0zTe8jwWllTzfvTyRH0z/k= =/kNT -----END PGP SIGNATURE----- --ISA6zNVXmTIvvkD5-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 03:54:56 2007 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 3BA1316A41A; Fri, 10 Aug 2007 03:54:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9611C13C469; Fri, 10 Aug 2007 03:54:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l7A3smCF003227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:54:52 +1000 Date: Fri, 10 Aug 2007 13:54:48 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> Message-ID: <20070810133946.H769@besplex.bde.org> References: <20070710233455.O2101@besplex.bde.org> <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070712225324.F9515@besplex.bde.org> <20070712142127.GD2200@deviant.kiev.zoral.com.ua> <20070716195556.P12807@besplex.bde.org> <20070721063434.GI2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> <20070808004001.O926@besplex.bde.org> <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE 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, 10 Aug 2007 03:54:56 -0000 On Tue, 7 Aug 2007, Kostik Belousov wrote: > On Wed, Aug 08, 2007 at 12:48:06AM +1000, Bruce Evans wrote: >> Here is a cleaned up version for -current for further review. I can't >> see how to do it cleanly without all the little functions. It also >> fixes a memory leak on module unload, and some style bugs in >> msdosfs_vfsops.c. This has been tested lightly runtime. Module unload >> has not been tested at all (I don't use modules). > > Why not allocate nambuf statically ? No reason. I just move the allocation to the init function without noticing that this made dynamic allocation completely bogus. (When the allocation was only done on first use, it saved about 256 bytes of data space until first use, at a costs of < 256 bytes of code, except with the memory leak it sometimes gave a negative savings for data space too.) > It seems that using functions for mbnambuf_acquire()/mbnambuf_release() > causes unneeded overhead. Macros could be used as well. Efficiency is not important here, and macros would require a lot of namespace pollution. > Anyway, these notes are not objections against patch. I wrote yet another patch, with allocation on the stack so that no locking is required. This is simpler and doesn't require any new functions. Unfortunately, it is larger because it changes the interfaces for most functions. The interface changes are routine, so this is probably better. Note that 'struct dirent's are already allocated on the stack. This patch adds allocation of 'struct mbnambuf's which are slightly smaller (~256 bytes). I think this is just small enough for stack allocation. % Index: direntry.h % =================================================================== % RCS file: /home/ncvs/src/sys/fs/msdosfs/direntry.h,v % retrieving revision 1.23 % diff -u -2 -r1.23 direntry.h % --- direntry.h 24 Oct 2006 11:14:05 -0000 1.23 % +++ direntry.h 9 Aug 2007 01:59:52 -0000 % @@ -134,10 +134,16 @@ % % #ifdef _KERNEL % +struct mbnambuf { % + size_t nb_len; % + int nb_last_id; % + char nb_buf[WIN_MAXLEN + 1]; % +}; % + % struct dirent; % struct msdosfsmount; % % -char *mbnambuf_flush(struct dirent *dp); % -void mbnambuf_init(void); % -void mbnambuf_write(char *name, int id); % +char *mbnambuf_flush(struct mbnambuf *nbp, struct dirent *dp); % +void mbnambuf_init(struct mbnambuf *nbp); % +void mbnambuf_write(struct mbnambuf *nbp, char *name, int id); % int dos2unixfn(u_char dn[11], u_char *un, int lower, % struct msdosfsmount *pmp); % @@ -146,7 +152,8 @@ % int unix2winfn(const u_char *un, size_t unlen, struct winentry *wep, int cnt, % int chksum, struct msdosfsmount *pmp); % -int winChkName(const u_char *un, size_t unlen, int chksum, % +int winChkName(struct mbnambuf *nbp, const u_char *un, size_t unlen, % + int chksum, struct msdosfsmount *pmp); % +int win2unixfn(struct mbnambuf *nbp, struct winentry *wep, int chksum, % struct msdosfsmount *pmp); % -int win2unixfn(struct winentry *wep, int chksum, struct msdosfsmount *pmp); % u_int8_t winChksum(struct direntry *dep); % int winSlotCnt(const u_char *un, size_t unlen, struct msdosfsmount *pmp); % Index: msdosfs_conv.c % =================================================================== % RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_conv.c,v % retrieving revision 1.52 % diff -u -2 -r1.52 msdosfs_conv.c % --- msdosfs_conv.c 7 Aug 2007 02:11:16 -0000 1.52 % +++ msdosfs_conv.c 9 Aug 2007 02:28:00 -0000 % @@ -53,5 +53,4 @@ % #include % #include % -#include % #include % % @@ -68,8 +67,4 @@ % static u_int16_t unix2winchr(const u_char **, size_t *, int, struct msdosfsmount *); % % -static char *nambuf_ptr; % -static size_t nambuf_len; % -static int nambuf_last_id; % - % /* % * 0 - character disallowed in long file name. % @@ -602,5 +597,6 @@ % */ % int % -winChkName(un, unlen, chksum, pmp) % +winChkName(nbp, un, unlen, chksum, pmp) % + struct mbnambuf *nbp; % const u_char *un; % size_t unlen; % @@ -614,7 +610,7 @@ % % /* % - * We alread have winentry in mbnambuf % + * We already have winentry in *nbp. % */ % - if (!mbnambuf_flush(&dirbuf) || !dirbuf.d_namlen) % + if (!mbnambuf_flush(nbp, &dirbuf) || dirbuf.d_namlen == 0) % return -1; % % @@ -651,5 +647,6 @@ % */ % int % -win2unixfn(wep, chksum, pmp) % +win2unixfn(nbp, wep, chksum, pmp) % + struct mbnambuf *nbp; % struct winentry *wep; % int chksum; % @@ -684,5 +681,5 @@ % case 0: % *np = '\0'; % - mbnambuf_write(name, (wep->weCnt & WIN_CNT) - 1); % + mbnambuf_write(nbp, name, (wep->weCnt & WIN_CNT) - 1); % return chksum; % case '/': % @@ -703,5 +700,5 @@ % case 0: % *np = '\0'; % - mbnambuf_write(name, (wep->weCnt & WIN_CNT) - 1); % + mbnambuf_write(nbp, name, (wep->weCnt & WIN_CNT) - 1); % return chksum; % case '/': % @@ -722,5 +719,5 @@ % case 0: % *np = '\0'; % - mbnambuf_write(name, (wep->weCnt & WIN_CNT) - 1); % + mbnambuf_write(nbp, name, (wep->weCnt & WIN_CNT) - 1); % return chksum; % case '/': % @@ -737,5 +734,5 @@ % } % *np = '\0'; % - mbnambuf_write(name, (wep->weCnt & WIN_CNT) - 1); % + mbnambuf_write(nbp, name, (wep->weCnt & WIN_CNT) - 1); % return chksum; % } % @@ -1038,17 +1035,13 @@ % % /* % - * Initialize the temporary concatenation buffer (once) and mark it as % - * empty on subsequent calls. % + * Initialize the temporary concatenation buffer. % */ % void % -mbnambuf_init(void) % +mbnambuf_init(struct mbnambuf *nbp) % { % % - if (nambuf_ptr == NULL) { % - nambuf_ptr = malloc(MAXNAMLEN + 1, M_MSDOSFSMNT, M_WAITOK); % - nambuf_ptr[MAXNAMLEN] = '\0'; % - } % - nambuf_len = 0; % - nambuf_last_id = -1; % + nbp->nb_len = 0; % + nbp->nb_last_id = -1; % + nbp->nb_buf[sizeof(nbp->nb_buf) - 1] = '\0'; % } % % @@ -1063,28 +1056,29 @@ % */ % void % -mbnambuf_write(char *name, int id) % +mbnambuf_write(struct mbnambuf *nbp, char *name, int id) % { % - size_t count; % char *slot; % + size_t count, newlen; % % - KASSERT(nambuf_len == 0 || id == nambuf_last_id - 1, % - ("non-decreasing id, id %d last id %d", id, nambuf_last_id)); % + KASSERT(nbp->nb_len == 0 || id == nbp->nb_last_id - 1, % + ("non-decreasing id: id %d, last id %d", id, nbp->nb_last_id)); % % - /* Store this substring in a WIN_CHAR-aligned slot. */ % - slot = nambuf_ptr + (id * WIN_CHARS); % + /* Will store this substring in a WIN_CHARS-aligned slot. */ % + slot = &nbp->nb_buf[id * WIN_CHARS]; % count = strlen(name); % - if (nambuf_len + count > MAXNAMLEN) { % - printf("msdosfs: file name %zu too long\n", nambuf_len + count); % + newlen = nbp->nb_len + count; % + if (newlen > WIN_MAXLEN || newlen > MAXNAMLEN) { % + printf("msdosfs: file name length %zu too large\n", newlen); % return; % } % % /* Shift suffix upwards by the amount length exceeds WIN_CHARS. */ % - if (count > WIN_CHARS && nambuf_len != 0) % - bcopy(slot + WIN_CHARS, slot + count, nambuf_len); % + if (count > WIN_CHARS && nbp->nb_len != 0) % + bcopy(slot + WIN_CHARS, slot + count, nbp->nb_len); % % /* Copy in the substring to its slot and update length so far. */ % bcopy(name, slot, count); % - nambuf_len += count; % - nambuf_last_id = id; % + nbp->nb_len = newlen; % + nbp->nb_last_id = id; % } % % @@ -1097,16 +1091,16 @@ % */ % char * % -mbnambuf_flush(struct dirent *dp) % +mbnambuf_flush(struct mbnambuf *nbp, struct dirent *dp) % { % % - if (nambuf_len > sizeof(dp->d_name) - 1) { % - mbnambuf_init(); % + if (nbp->nb_len > sizeof(dp->d_name) - 1) { % + mbnambuf_init(nbp); % return (NULL); % } % - bcopy(nambuf_ptr, dp->d_name, nambuf_len); % - dp->d_name[nambuf_len] = '\0'; % - dp->d_namlen = nambuf_len; % + bcopy(&nbp->nb_buf[0], dp->d_name, nbp->nb_len); % + dp->d_name[nbp->nb_len] = '\0'; % + dp->d_namlen = nbp->nb_len; % % - mbnambuf_init(); % + mbnambuf_init(nbp); % return (dp->d_name); % } % Index: msdosfs_lookup.c % =================================================================== % RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v % retrieving revision 1.50 % diff -u -2 -r1.50 msdosfs_lookup.c % --- msdosfs_lookup.c 7 Aug 2007 02:25:56 -0000 1.50 % +++ msdosfs_lookup.c 9 Aug 2007 01:56:31 -0000 % @@ -85,4 +85,5 @@ % } */ *ap; % { % + struct mbnambuf nb; % struct vnode *vdp = ap->a_dvp; % struct vnode **vpp = ap->a_vpp; % @@ -186,5 +187,5 @@ % */ % tdp = NULL; % - mbnambuf_init(); % + mbnambuf_init(&nb); % /* % * The outer loop ranges over the clusters that make up the % @@ -226,5 +227,5 @@ % */ % chksum = -1; % - mbnambuf_init(); % + mbnambuf_init(&nb); % % if (slotcount < wincnt) { % @@ -251,14 +252,13 @@ % continue; % % - chksum = win2unixfn((struct winentry *)dep, % - chksum, % - pmp); % + chksum = win2unixfn(&nb, % + (struct winentry *)dep, chksum, % + pmp); % continue; % } % % - chksum = winChkName((const u_char *)cnp->cn_nameptr, % - unlen, % - chksum, % - pmp); % + chksum = winChkName(&nb, % + (const u_char *)cnp->cn_nameptr, unlen, % + chksum, pmp); % if (chksum == -2) { % chksum = -1; % Index: msdosfs_vnops.c % =================================================================== % RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v % retrieving revision 1.178 % diff -u -2 -r1.178 msdosfs_vnops.c % --- msdosfs_vnops.c 7 Aug 2007 10:35:27 -0000 1.178 % +++ msdosfs_vnops.c 9 Aug 2007 02:25:37 -0000 % @@ -1511,4 +1511,5 @@ % } */ *ap; % { % + struct mbnambuf nb; % int error = 0; % int diff; % @@ -1630,5 +1631,5 @@ % } % % - mbnambuf_init(); % + mbnambuf_init(&nb); % off = offset; % while (uio->uio_resid > 0) { % @@ -1646,10 +1647,11 @@ % if (error) { % brelse(bp); % - return (error); % + break; % } % n = min(n, blsize - bp->b_resid); % if (n == 0) { % brelse(bp); % - return (EIO); % + error = EIO; % + break; % } % This hunk is no longer needed for deallocation, but might be needed to fix an old bug. % @@ -1677,5 +1679,5 @@ % if (dentp->deName[0] == SLOT_DELETED) { % chksum = -1; % - mbnambuf_init(); % + mbnambuf_init(&nb); % continue; % } % @@ -1687,6 +1689,6 @@ % if (pmp->pm_flags & MSDOSFSMNT_SHORTNAME) % continue; % - chksum = win2unixfn((struct winentry *)dentp, % - chksum, pmp); % + chksum = win2unixfn(&nb, % + (struct winentry *)dentp, chksum, pmp); % continue; % } % @@ -1697,5 +1699,5 @@ % if (dentp->deAttributes & ATTR_VOLUME) { % chksum = -1; % - mbnambuf_init(); % + mbnambuf_init(&nb); % continue; % } % @@ -1739,7 +1741,7 @@ % (LCASE_BASE | LCASE_EXT) : 0), % pmp); % - mbnambuf_init(); % + mbnambuf_init(&nb); % } else % - mbnambuf_flush(&dirbuf); % + mbnambuf_flush(&nb, &dirbuf); % chksum = -1; % dirbuf.d_reclen = GENERIC_DIRSIZ(&dirbuf); % @@ -1765,4 +1767,5 @@ % } % out: % + % /* Subtract unused cookies */ % if (ap->a_ncookies) Last hunk is certainly no longer needed (was cleanup for deallocation). Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 08:13:58 2007 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 7E11516A418 for ; Fri, 10 Aug 2007 08:13:58 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.freebsd.org (Postfix) with ESMTP id 471E113C459 for ; Fri, 10 Aug 2007 08:13:58 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id B74E9244C19; Fri, 10 Aug 2007 16:49:17 +0900 (JST) Message-ID: <46BC187C.6030209@freebsd.org> Date: Fri, 10 Aug 2007 16:49:16 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: nowickis References: <53617a56.fdaa6fb.469fde4f.a6f89@o2.pl> In-Reply-To: <53617a56.fdaa6fb.469fde4f.a6f89@o2.pl> Content-Type: multipart/mixed; boundary="------------090508060300040507090805" Cc: freebsd-fs@freebsd.org Subject: Re: unionfs problem 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, 10 Aug 2007 08:13:58 -0000 This is a multi-part message in MIME format. --------------090508060300040507090805 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit nowickis wrote: > Hi. > > I'm having problems using unionfs on freebsd. > Scenario is like this: On one machine (m1) I’m having /usr/ports dir with is updated every day. > On another machine (m2) I’m mounting /usr/ports from m1 by nfs to /usr/ports on m2. > Of course on m2 /usr/ports is read-only. So, I was starting to using unionfs on m2. > I have create dir (/tmp/somedir) and use unionfs as root mount_unionfs /tmp/somedir /usr/ports For now everything works fine, > I have writing privileges to /use/ports on m2. > I'm mono (http://www.go-mono.com) user, so I want to install the latest version of this port. > I need to use mono-merge script (which you can get from http://forge.novell.com/modules/xfmod/project/?bsd-sharp) to merge mono > ports tree witch /usr/ports tree. (this is the way do get the latest version of mono’s ports). > When I run this script, after couple of seconds, my machine (m2) is freezing, completely no response. > Only what I can do is reset it. This freezing is occurring when mono-merge is recursion deleting some folders > in /usr/ports. Of course, then when /use/ports is on local machine (no mounted) mono-merge works fine. > This problem is occurring on freebsd 6.2 and 7.0. I have try traditional, transparent and masquerade mode. Result is the same. > Do you have any idea what I’m doing wrong? > Maybe there is a bug in unionfs. > > Regards > > Nowicki Sebastian > After long-long tests, at last, we had found the same problem you reported. Our research says that the issue depends on implementation bug of nfs_readdir of nfsclient or nfs4client. (for detail, it ignores eofflag request). I include a patch that prevent that issue. Would you try please. And we haveno plan to get it merged because this issue is not of unionfs. It should be fixed on nfs_readdir of nfsclient. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi --------------090508060300040507090805 Content-Type: text/x-patch; name="unionfs-nfs-hangup.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="unionfs-nfs-hangup.diff" diff -urBN /usr/src.orig/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c --- /usr/src.orig/sys/fs/unionfs/union_subr.c 2007-07-09 19:27:08.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_subr.c 2007-08-08 01:19:58.000000000 +0900 @@ -1129,7 +1129,7 @@ uio.uio_resid = iov.iov_len; error = VOP_READDIR(lvp, &uio, cred, &eofflag, NULL, NULL); - if (error) + if (error || uio.uio_resid == sizeof(buf)) break; edp = (struct dirent*)&buf[sizeof(buf) - uio.uio_resid]; --------------090508060300040507090805-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 12:42:56 2007 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 B19F216A417; Fri, 10 Aug 2007 12:42:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 513BD13C4A8; Fri, 10 Aug 2007 12:42:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IJTpA-0007Yh-Sd; Fri, 10 Aug 2007 15:42:49 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7ACful1085230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 15:41:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7ACftex030981; Fri, 10 Aug 2007 15:41:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l7ACfrKI030980; Fri, 10 Aug 2007 15:41:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Aug 2007 15:41:53 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20070810124153.GW2738@deviant.kiev.zoral.com.ua> References: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070712225324.F9515@besplex.bde.org> <20070712142127.GD2200@deviant.kiev.zoral.com.ua> <20070716195556.P12807@besplex.bde.org> <20070721063434.GI2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> <20070808004001.O926@besplex.bde.org> <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> <20070810133946.H769@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KCLoHzx0Ylaw/v4x" Content-Disposition: inline In-Reply-To: <20070810133946.H769@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 3140350ce96b4815fe22a3a842dc7b15 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1373 [August 10 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE 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, 10 Aug 2007 12:42:56 -0000 --KCLoHzx0Ylaw/v4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 10, 2007 at 01:54:48PM +1000, Bruce Evans wrote: > I wrote yet another patch, with allocation on the stack so that no locking > is required. This is simpler and doesn't require any new functions. > Unfortunately, it is larger because it changes the interfaces for most > functions. The interface changes are routine, so this is probably better. > Note that 'struct dirent's are already allocated on the stack. This > patch adds allocation of 'struct mbnambuf's which are slightly smaller > (~256 bytes). I think this is just small enough for stack allocation. I agree that this is the best approach. The size of the on-stack structure still make me worry, although ~270 bytes seems to be not too large for 3-pages stack. --KCLoHzx0Ylaw/v4x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGvF0RC3+MBN1Mb4gRAnFJAKCJAn0rxD4oSFwYYvFYx2lxSiaUugCfd9xH 4hVyy0x0GC2lo9Grux6PNj0= =2CQF -----END PGP SIGNATURE----- --KCLoHzx0Ylaw/v4x-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 15:28:21 2007 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 B823D16A46C for ; Fri, 10 Aug 2007 15:28:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from ccshst09.cs.uoguelph.ca (ccshst09.cs.uoguelph.ca [131.104.94.206]) by mx1.freebsd.org (Postfix) with ESMTP id 630FD13C4E8 for ; Fri, 10 Aug 2007 15:28:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by ccshst09.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l7AFSGrx002293 for ; Fri, 10 Aug 2007 11:28:19 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l7AFXMW27807 for ; Fri, 10 Aug 2007 11:33:22 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 10 Aug 2007 11:33:22 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: freebsd-fs@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.206 Subject: multiplexing TCP sockets in the NFS client 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, 10 Aug 2007 15:28:21 -0000 Long long ago, I felt it might be better to use a separate TCP socket for each mount to the same server. The argument was along the lines of: Some mounts might be much busier than others and, as such, the separate TCP socket would provide feedback to the client w.r.t. load on that mount. The assumption w.r.t. busier mount points tacitly assumed separate disks with some disks experiencing heavy I/O loads. It seems to me that these days, what with SANs, RAIDs, GEOM,... that a mount point probably isn't going to reflect a different disk subsystem so much as an administrative boundary. Also, it's not obvious that the feedback argument is relevant anyhow, since clients will still receive replies when the server gets around to doing the RPC, in any case. So, I'm thinking that it might be better to change the client code so that it shares one TCP connection between all mounts to the same server. This reduces the number of TCP connections (possibly an issue if clients use an automounter to do a lot of mounts). It might also help w.r.t transport performance by increasing the volume of data being transferred on the TCP connection? (I don't know enough about current TCP stacks to know if this is the case or not?) Any comments? rick From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 15:49:24 2007 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 DA49C16A418 for ; Fri, 10 Aug 2007 15:49:24 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by mx1.freebsd.org (Postfix) with ESMTP id A8CE813C45D for ; Fri, 10 Aug 2007 15:49:24 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 6F92752A8; Fri, 10 Aug 2007 11:33:00 -0400 (EDT) From: Greg Troxel To: Rick Macklem References: X-Hashcash: 1:20:070810:rmacklem@uoguelph.ca::6V7Cv3GpoIRux/i7:000000000000000000000000000000000000000003yM6 X-Hashcash: 1:20:070810:freebsd-fs@freebsd.org::yY1qfiWT/G2YRJ97:0000000000000000000000000000000000000002ZoN Date: Fri, 10 Aug 2007 11:33:00 -0400 In-Reply-To: (Rick Macklem's message of "Fri, 10 Aug 2007 11:33:22 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: multiplexing TCP sockets in the NFS client 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, 10 Aug 2007 15:49:24 -0000 So, I'm thinking that it might be better to change the client code so that it shares one TCP connection between all mounts to the same server. My quick reaction is that this is an interesting question and that it is likely that different choices work better in different environments. So if it's at all reasonable, I'd lean towards making a run-time option to change behavior, exposed as sysctl, and invite benchmarking. From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 17:30:48 2007 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 A9D9C16A41A for ; Fri, 10 Aug 2007 17:30:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4C41D13C4A5 for ; Fri, 10 Aug 2007 17:30:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l7AGwoRh057242; Fri, 10 Aug 2007 10:58:51 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46BC9944.9010408@samsco.org> Date: Fri, 10 Aug 2007 10:58:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Rick Macklem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 10 Aug 2007 10:58:51 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-fs@freebsd.org Subject: Re: multiplexing TCP sockets in the NFS client 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, 10 Aug 2007 17:30:48 -0000 Rick Macklem wrote: > Long long ago, I felt it might be better to use a separate TCP socket > for each mount to the same server. The argument was along the lines of: > > Some mounts might be much busier than others and, as such, the > separate TCP socket would provide feedback to the client w.r.t. > load on that mount. The assumption w.r.t. busier mount points > tacitly assumed separate disks with some disks experiencing > heavy I/O loads. > > It seems to me that these days, what with SANs, RAIDs, GEOM,... that a > mount point probably isn't going to reflect a different disk subsystem > so much as an administrative boundary. Also, it's not obvious that the > feedback argument is relevant anyhow, since clients will still receive > replies when the server gets around to doing the RPC, in any case. > > So, I'm thinking that it might be better to change the client code so that > it shares one TCP connection between all mounts to the same server. This > reduces the number of TCP connections (possibly an issue if clients use > an automounter to do a lot of mounts). It might also help w.r.t transport > performance by increasing the volume of data being transferred on the TCP > connection? (I don't know enough about current TCP stacks to know if this > is the case or not?) > > Any comments? rick > Is SCTP of any interest in the NFS world? Scott From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 18:07:57 2007 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 8C17716A417 for ; Fri, 10 Aug 2007 18:07:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from ccshst09.cs.uoguelph.ca (ccshst09.cs.uoguelph.ca [131.104.94.206]) by mx1.freebsd.org (Postfix) with ESMTP id 352DB13C45D for ; Fri, 10 Aug 2007 18:07:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by ccshst09.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l7AI7tKM019554; Fri, 10 Aug 2007 14:07:55 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l7AICxH19931; Fri, 10 Aug 2007 14:13:00 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 10 Aug 2007 14:12:59 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: Scott Long In-Reply-To: <46BC9944.9010408@samsco.org> Message-ID: References: <46BC9944.9010408@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.206 Cc: freebsd-fs@freebsd.org Subject: Re: multiplexing TCP sockets in the NFS client 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, 10 Aug 2007 18:07:57 -0000 On Fri, 10 Aug 2007, Scott Long wrote: > > Is SCTP of any interest in the NFS world? > > Scott > Good question, for which I don't have a good answer. Maybe I'll ask on the IETF mailing list... It is mentioned as an alternative to TCP in the NFSv4 (or is it the 4.1 draft) RFC, but I don't know of anyone with an implementation. rick From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 19:10:52 2007 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 6891916A41A for ; Fri, 10 Aug 2007 19:10:52 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by mx1.freebsd.org (Postfix) with ESMTP id 327F713C45A for ; Fri, 10 Aug 2007 19:10:52 +0000 (UTC) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id D4AC852A8; Fri, 10 Aug 2007 15:10:50 -0400 (EDT) From: Greg Troxel To: Rick Macklem References: <46BC9944.9010408@samsco.org> X-Hashcash: 1:20:070810:rmacklem@uoguelph.ca::PKJ3ugrSOPYA+XU/:000000000000000000000000000000000000000000Wr1 X-Hashcash: 1:20:070810:freebsd-fs@freebsd.org::vM3E4mpJAwyCaCNP:00000000000000000000000000000000000000086Uj X-Hashcash: 1:20:070810:scottl@samsco.org::yae0zwvijsbnvHQO:00000000000000000000000000000000000000000000C+hG Date: Fri, 10 Aug 2007 15:10:50 -0400 In-Reply-To: (Rick Macklem's message of "Fri, 10 Aug 2007 14:12:59 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: multiplexing TCP sockets in the NFS client 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, 10 Aug 2007 19:10:52 -0000 I would say SCTP is of interest; it allows a number of interactions to be treated together for addressing, authentication and congestion control, but to be decoupled from each other in terms of flow control. Coda has homegrown RPC2, which almost starts to feel like its trying to do what SCTP does. But, SCTP is not yet very widely implemented. So while I think it's a good goal, it's not an answer to how many TCP streams :-) From owner-freebsd-fs@FreeBSD.ORG Sat Aug 11 09:12:59 2007 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 0A12316A418 for ; Sat, 11 Aug 2007 09:12:59 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E43C13C458 for ; Sat, 11 Aug 2007 09:12:58 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [80.177.232.250] (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l7B9Curr000968; Sat, 11 Aug 2007 10:12:56 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: Rick Macklem In-Reply-To: References: <46BC9944.9010408@samsco.org> Content-Type: text/plain Date: Sat, 11 Aug 2007 10:12:56 +0100 Message-Id: <1186823576.99911.21.camel@herring.rabson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/3923/Sat Aug 11 09:03:45 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: multiplexing TCP sockets in the NFS client 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, 11 Aug 2007 09:12:59 -0000 On Fri, 2007-08-10 at 14:12 -0400, Rick Macklem wrote: > > On Fri, 10 Aug 2007, Scott Long wrote: > > > > > Is SCTP of any interest in the NFS world? > > > > Scott > > > Good question, for which I don't have a good answer. Maybe I'll ask on > the IETF mailing list... > > It is mentioned as an alternative to TCP in the NFSv4 (or is it the 4.1 > draft) RFC, but I don't know of anyone with an implementation. I'm sure I remember reading something about SCTP in one of the NFS over RDMA drafts.