From owner-freebsd-current@FreeBSD.ORG Thu Jan 27 13:16:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D42616A4CE for ; Thu, 27 Jan 2005 13:16:26 +0000 (GMT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 378AB43D2D for ; Thu, 27 Jan 2005 13:16:25 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cu9VY-0005Lr-00 for ; Thu, 27 Jan 2005 14:16:24 +0100 Received: from dhcp193.ifado.de ([195.253.22.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Jan 2005 14:16:23 +0100 Received: from wb by dhcp193.ifado.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Jan 2005 14:16:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wilhelm B. Kloke" Date: Thu, 27 Jan 2005 13:16:17 +0000 (UTC) Organization: InstArbPhysUniDo Lines: 39 Message-ID: References: <15034.1106822697@critter.freebsd.dk> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dhcp193.ifado.de User-Agent: slrn/0.9.8.0 (FreeBSD) Cache-Post-Path: vestein!unknown@yorikke X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Sender: news Subject: Re: Looking for competent nullfs/umapfs/unionfs testers.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 13:16:26 -0000 Poul-Henning Kamp schrieb: > > I cannot test all the weird edge-cases of the stacked filesystems > myself, so I need somebody to help test them for me. I am sufficiently interested in getting unionfs working to do some work. Though, I cannot consider me competent in testing. > 2. I'm not promising to fix all known problems, some of them may > be architecturally unfixable [1], I am merely trying to not break > them any further. A comprehensive list of these problems could help making people interested. > [1] In unionfs: a file is opened R/O and taken from the bottom > layer, and then mmap'ed. Subsequently, the file is opened R/W > and mmaped by another process. The R/W open copies the file > to the upper layer. I have no idea if the two processes will > see a consistent mmap of the file, and if they don't I have > no idea how to fix it, short of always creating a vm_object > for the vnode thereby loosing the caching advantage of the > lower vnode (unless some VM system COW magic can be used ?). > In particular I don't intend to try to fix this problem. If the semantics of a Unix file defines the behaviour in case of plain files (I don't know. Perhaps the behaviour is defined as "undefined" already.) it is essential that the semantics conforms to this definition. Otherwise, it there is clearly no need to have the 2 mmaps consistent. RW-opening of already open files should be restricted in some form. How about return EOPNOTSUPP, if not overwritten by some flag? The man page of flock(2) says that consistent behaviour is not guaranteed by locking. I conclude that without locking it is neither. So the necessity for consistent behaviour has to be announced from the process opening the file by using O_SHLOCK, IMHO. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257