On Fri, Aug 13, 2010 at 1:53 PM, Patrick J. LoPresti <lopresti@xxxxxxxxx> wrote: > On Fri, Aug 13, 2010 at 12:09 PM, john stultz <johnstul@xxxxxxxxxx> wrote: >> >> So other then "show some numbers", my only thought that might make the >> patch more attractive is that rather than a global change, or a static >> CONFIG_ option, would it maybe make more sense as a mount option? > > I really like this idea. > > Consider the following "revision 2" of my proposal: > > 1) Add a function pointer "current_fs_time" to struct super_block. > > 2) Replace all calls of the form: > > current_fs_time(sb); > > with > > sb->current_fs_time(sb); > > 3) Arrange for the default value to point to the current implementation. > > These first three could be one patch. They change no functionality; > they just enable the next step. > > Finally: > > 4) Add a mount option to cause sb->current_fs_time(sb) to use the > hi-res implementation. > > Comments? I'm not sure how nfs works but if this is a client side issue I don't see anything wrong with a CONFIG_ item but if its server side it might be better off as a procfs or sysfs tunable so reboots are not required to change the setting performance wise why would there be any difference the same amount of bits are being set on the disk drive no? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
