On Tue, Aug 15, 2006 at 09:21:53AM +0100, David Howells wrote: > Josh Boyer <jwboyer@xxxxxxxxx> wrote: > > > Out of curiosity, is there a performance hit for 32-bit systems? Have > > you done any minimal benchmarks to see? > > Yes, I'm sure there is, but we're talking performance vs correctness. ITYM performance vs. slightly different patch. Let me put all pieces in one place: * kstat gets u64 ino * filesystems that want to report 64bit st_ino do it in their ->getattr(); the rest is unchanged. * ino_t is left as-is * filldir() callbacks get u64 ino in arguments. Filesystem may pass 64bit value if it cares to; otherwise it's left unchanged. * filesystem that wants unusual search key can use iget5() (as it can do right now) * filesystem that wants to use the values it'd put into st_ino in its printks should use appropriate format * any printk in generic code that happens to use i_ino should be hunted down and shot for utter uselessness for too many filesystems (not sure if we actually _have_ any such printk these days). - 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
