On Thu, Jun 17, 2010 at 05:39:17PM -0600, Andreas Dilger wrote: > On 2010-06-16, at 13:54, Valerie Aurora wrote: > > On Wed, Jun 16, 2010 at 02:59:13PM -0400, Valerie Aurora wrote: > >> Who needs d_ino anyway? I am running a kernel with this patch - > >> Gnome, a browser, IRC, kernel compile, etc. and everything works. > > > > Gosh, maybe it would help to patch the currently used readdir instead > > of just old_readdir() (thanks, Arnd). And return 1 instead of 0 so ls > > doesn't think all files are deleted (thanks, Andreas). > > > > I'm running a kernel with the below patch and everything still works. > > Apparently "ls -i" is still using the bogus d_ino performance > > improvement mentioned here because it returns all 1's for inode > > number. > > > > http://www.mail-archive.com/bug-findutils@xxxxxxx/msg02531.html > > I don't see why the presence of d_ino is a "bogus" performance optimization. It is useful for some things, and replacing this with "1" by no means helps anything IMHO, and destroys some useful optimizations (e.g. finding which inodes may be hard links), so I'm against this patch. Ah, this particular performance optimization is bogus because the output result is wrong in the case of mountpoints. (It's a long long thread but maybe worth reading it all.) In general, there's nothing wrong with using d_ino as a performance optimization. I just posted this patch (and tested it) to see how people actually use d_ino in real life. I don't think there's any danger of it being accepted, although it is useful for testing programs that use d_ino. Thanks for your help, -VAL -- 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
