From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 00:40:54 2010 Return-Path: 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 48A6810656AA; Thu, 19 Aug 2010 00:40:54 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD6D8FC0A; Thu, 19 Aug 2010 00:40:53 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 2015A12543B; Thu, 19 Aug 2010 09:23:35 +0900 (JST) Message-ID: <4C6C797C.5000409@ongs.co.jp> Date: Thu, 19 Aug 2010 09:23:24 +0900 From: Daichi GOTO User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100724 Thunderbird/3.0.6 MIME-Version: 1.0 To: ed@80386.nl, freebsd-current@freebsd.org, freebsd-fs@freebsd.org, ozawa@ongs.co.jp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: unionfs a little improvement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Aug 2010 00:40:54 -0000 Hi Ed and unionfs fan gyus. Ed pointed out a contradict behavior between current unionfs implementation and its manual, and sent me a patch. Thanks Ed ;) ---- Index: sys/fs/unionfs/union_vfsops.c =================================================================== --- sys/fs/unionfs/union_vfsops.c (revision 211093) +++ sys/fs/unionfs/union_vfsops.c (working copy) @@ -89,7 +89,6 @@ u_short ufile; unionfs_copymode copymode; unionfs_whitemode whitemode; - struct componentname fakecn; struct nameidata nd, *ndp; struct vattr va; @@ -280,26 +279,6 @@ mp->mnt_flag |= ump->um_uppervp->v_mount->mnt_flag & MNT_RDONLY; /* - * Check whiteout - */ - if ((mp->mnt_flag & MNT_RDONLY) == 0) { - memset(&fakecn, 0, sizeof(fakecn)); - fakecn.cn_nameiop = LOOKUP; - fakecn.cn_thread = td; - error = VOP_WHITEOUT(ump->um_uppervp, &fakecn, LOOKUP); - if (error) { - if (below) { - VOP_UNLOCK(ump->um_uppervp, 0); - vrele(upperrootvp); - } else - vput(ump->um_uppervp); - free(ump, M_UNIONFSMNT); - mp->mnt_data = NULL; - return (error); - } - } - - /* * Unlock the node */ VOP_UNLOCK(ump->um_uppervp, 0); ---- Ed's message here: ---- Just for fun I was hacking on a writable bootcd, using unionfs and tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents unionfs from mounting tmpfs on top. I do want to be able to use tmpfs, even if it means we can't get any whiteouts. The manpage says the following: Without whiteout support from the file system backing the upper layer, there is no way that delete and rename operations on lower layer objects can be done. EROFS is returned for this kind of operations along with any others which would make modifications to the lower layer, such as chmod(1). This seems to contradict the current behaviour, which is to deny the mount altogether. The attached patch makes it work, but instead of EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT(). ---- It looks like reasonable and patch is simple and effective I guess. If you unionfs guys or fs guys have some ideas around this patch, please teach me. After some tests and a couple of weeks after, I'll commit ed's patch if there is no objections. -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto