Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755866Ab3CPN4A (ORCPT ); Sat, 16 Mar 2013 09:56:00 -0400 Received: from mail01-md.ns.itscom.net ([175.177.155.111]:57189 "EHLO mail01-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755842Ab3CPNz6 (ORCPT ); Sat, 16 Mar 2013 09:55:58 -0400 From: "J. R. Okajima" Subject: Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17) To: Al Viro Cc: James Bottomley , Miklos Szeredi , Andrew Morton , torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hch@infradead.org, apw@canonical.com, nbd@openwrt.org, neilb@suse.de, jordipujolp@gmail.com, ezk@fsl.cs.sunysb.edu, dhowells@redhat.com, sedat.dilek@googlemail.com, mszeredi@suse.cz In-Reply-To: <20130315203018.GZ21522@ZenIV.linux.org.uk> References: <20130313160854.54ac0491044371b4db214698@linux-foundation.org> <20130315012541.GU21522@ZenIV.linux.org.uk> <19058.1363320936@jrobl> <20130315044411.GW21522@ZenIV.linux.org.uk> <20079.1363324154@jrobl> <20130315051322.GX21522@ZenIV.linux.org.uk> <1363335318.2459.4.camel@dabdike> <20130315121220.GY21522@ZenIV.linux.org.uk> <29608.1363373838@jrobl> <20130315203018.GZ21522@ZenIV.linux.org.uk> Date: Sat, 16 Mar 2013 22:55:53 +0900 Message-ID: <8431.1363442153@jrobl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1474 Lines: 34 Al Viro: > Sure - btrfs happens to have an interesting limit on the number of > links to the same object located in one directory. It doesn't matter. On every filesystem, the link count has its upper limit eventually. When vfs_link() for whiteout returns EMLINK, aufs removes the whiteout-src file and creates a new one internally and asynchronously. Completing a new whiteout-src, aufs will go back to the link approach. The actual link count when EMLINK returned does not matter. Some filesystems don't support link(2). For such fs, user should tell aufs that the layer-fs has no link, and aufs will always create whiteout as a size-zeroed regular file instead of hardlink. Otherwise user cannot remove a file logically (rm(1) will return ENOTSUP or EPERM.). > And yes, it is an independent primitive. What I really don't understand > is WTF is so attractive about not having to touch individual filesystems; > it's not particulary hard to do for any fs we might care about... Hmm, aufs might have lived too long time as outside mainline. The whiteout approach aufs took is non-modifying the underlying fs. And I thought it is essentially important for new fs, otherwise it would be harder to be merged. J. R. Okajima -- 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/