From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 09:10: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 853BE1065695; Wed, 18 Aug 2010 09:10:54 +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 55C188FC23; Wed, 18 Aug 2010 09:10:54 +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 12B6E12543B; Wed, 18 Aug 2010 17:52:34 +0900 (JST) Message-ID: <4C6B9F51.1060009@freebsd.org> Date: Wed, 18 Aug 2010 17:52:33 +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: Wed, 18 Aug 2010 09:10: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 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto