From owner-freebsd-current@FreeBSD.ORG Thu Jan 27 10:44:59 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 4A4AA16A4CE for ; Thu, 27 Jan 2005 10:44:59 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BF9B43D66 for ; Thu, 27 Jan 2005 10:44:58 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0RAivZb015035 for ; Thu, 27 Jan 2005 11:44:57 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Thu, 27 Jan 2005 11:44:57 +0100 Message-ID: <15034.1106822697@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: 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 10:44:59 -0000 I cannot test all the weird edge-cases of the stacked filesystems myself, so I need somebody to help test them for me. Here's the deal as seen from my side: 1. It should not take more of my time to deal with the testers than it would to test the stuff myself. 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. 3. The tests should result in stuff going into the src/tools/regression framework so it can be reused in the future. I'm looking for testers who: - can think out things to test and write scripts/programs that tests it. - will spend the time producing a minimal testcase for the failures they encounter. If this sounds like you, just go right ahead and send me reports when you find something which doesn't work. The code I want you to test is in the p4 branch "phk_bufwork" if you don't have access to perforce you can pull down a patch relative to -current here: http://phk.freebsd.dk/patch/buf_work.patch Poul-Henning [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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.