Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Wed, Mar 2, 2011 at 10:03 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> >> 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. But why get local >> fs behaving strangely? It'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. Including those that have >> all directories with i_nlink == 1 for as long as directory lives. > > 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 the > 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 == 2, to 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. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
