From: OGAWA Hirofumi Subject: Re: [RFC] st_nlink after rmdir() and rename() Date: Fri, 04 Mar 2011 05:46:27 +0900 Message-ID: <87tyfk7x0c.fsf@devron.myhome.or.jp> References: <20110303032454.GI22723@ZenIV.linux.org.uk> <20110303060352.GK22723@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Linus Torvalds Return-path: In-Reply-To: (Linus Torvalds's message of "Thu, 3 Mar 2011 12:05:43 -0800") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Linus Torvalds writes: > On Wed, Mar 2, 2011 at 10:03 PM, Al Viro wr= ote: >> >> IOW, it's a QoI question - sure, NFS is weird and you lose a lot of = usual >> warranties there when it comes to object removal. =A0But why get loc= al >> fs behaving strangely? =A0It's not like "decrement i_nlink from 2 to= 1" was >> cheaper than "assign 0 to i_nlink", after all. >> >> FWIW, a lot of local filesystems have no notion of links; they tend = to >> maintain zero/non-zero distinction just fine. =A0Including those tha= t have >> all directories with i_nlink =3D=3D 1 for as long as directory lives= =2E > > The thing is, I don't think it's a QoI question at all - since any > user that _depends_ on this kind of behavior is simply broken. We > aren't going to guarantee it, exactly because some filesystems simply > will not ever guarantee it. > > Now, for FAT we do in fact try rather hard to fake the i_nlink count, > but I'm not at all convinced that's a good idea. It makes reading > directory inodes on FAT much more expensive (we have to basically do = a > readdir for each open). So I'd hate to make that whole "you need to > emulate i_nlink even if you really don't care" be something that we > actually end up thinking is a quality issue. Yes. It's one of reason linux's FAT is slow for some operations (from original designs). > There are other filesystems where i_nlink can be even _less_ > meaningful, ie if the filesystem does any kind of fancy > content-indexing thing or lazy COW (think "union filesystem within th= e > filesystem") or whatever, I could easily see i_nlink not having any > traditional unix filesystem semantics. But, some commands see i_nlink (IIRC, it's checking i_nlink =3D=3D 2, t= o know empty dir or not). So we have to simulate some levels. I guess you are not saying we don't need to care it at all though. I think if it's _really easy_ to do, I think we should try. Thanks. --=20 OGAWA Hirofumi