Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755474Ab3COTLY (ORCPT ); Fri, 15 Mar 2013 15:11:24 -0400 Received: from mail-vb0-f50.google.com ([209.85.212.50]:54889 "EHLO mail-vb0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755156Ab3COTLX (ORCPT ); Fri, 15 Mar 2013 15:11:23 -0400 MIME-Version: 1.0 In-Reply-To: <20079.1363324154@jrobl> References: <1363184193-1796-1-git-send-email-miklos@szeredi.hu> <20130313160854.54ac0491044371b4db214698@linux-foundation.org> <20130315012541.GU21522@ZenIV.linux.org.uk> <19058.1363320936@jrobl> <20130315044411.GW21522@ZenIV.linux.org.uk> <20079.1363324154@jrobl> Date: Fri, 15 Mar 2013 12:11:21 -0700 X-Google-Sender-Auth: 5T9SglnIhd73Lm_oanjQjAZK7g8 Message-ID: Subject: Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17) From: Linus Torvalds To: "J. R. Okajima" Cc: Al Viro , Miklos Szeredi , Andrew Morton , linux-fsdevel , Linux Kernel Mailing List , Christoph Hellwig , Robo Bot , Felix Fietkau , Neil Brown , Jordi Pujol , ezk@fsl.cs.sunysb.edu, David Howells , Sedat Dilek , Miklos Szeredi Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1660 Lines: 35 On Thu, Mar 14, 2013 at 10:09 PM, J. R. Okajima wrote: > > "no inodes at all"? > Are you assuming the implementation in dcache only (with a new d_type > flag)? And it is up to the real fs (layer or branch) whether it consumes > inode or not? Yes. That would be lovely. And trivial for most filesystems to support. Sure, you could have an inode if you need to (not all filesystems may have a flag in the directory entry), so it would look like "mknod()" for the filesystem. But the filesystem might decide to never actually create the inode at all if it reconizes the node as a whiteout node. I think we should do this. Yes, it requires filesystem work, but in the long run it's the right thing to do, and the filesystem work is likely very very simple. Besides, we probably only need to support a few filesystems for it to be already useful. What filesystems do the people who use unionfs actually use today? Also note that it's only the "upper layer" filesystem that needs whiteout nodes. So it's not "all filesystems involved with overlayfs", it's only the upper ones. And they have to already support xattr, so I'm assuming in practice we're talking only a few cases, right? Just tmpfs, ext3, ext4 probably covers most cases.. And it would get rid of all the horrible security check changes for xattrs, no? So we'd really end up with a noticeably cleaner model. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/