Actually, it seems more likely that you would turn off oplock temporarily (ie via /proc) rather than permanently (until cifs is reloaded or the system reboots). Wouldn't you only turn oplock off to temporarily work around a buggy server? On Tue, Oct 11, 2011 at 4:14 AM, Suresh Jayaraman <sjayaraman@xxxxxxxx> wrote: > On 10/10/2011 07:07 PM, Jeff Layton wrote: >> On Mon, 10 Oct 2011 18:36:15 +0530 >> Suresh Jayaraman <sjayaraman@xxxxxxxx> wrote: >> >>> On 10/10/2011 03:02 PM, Alexander Swen wrote: >>>> >>>> Hi Steve and other CIFS developers, >>>> >>>> please help me with the following: >>>> 1. fix the bug I explain below ;-) >>>> 2. tell me to what bug tracking system I should to file it to. >>>> >>>> so, imho this is a bug: when I load the cifs module it insists in setting oplockenabled to 1 while we want to have locking disabled (due to our poormen's nas who's performance sinks to subzero when we do serious io ;-) >>>> >>>> I've filed this bug at Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644135 >>>> >>>> I paste all details over here as well: >>>> <paste> >>>> Package: linux-mage >>>> Version: 2.6.32-5-amd64 >>>> >>>> cifs.ko module (which is included in the kernel pkg as far as i know) >>>> cifs driver version 1.61 >>>> >>>> when cifs module loads oplock is enabled by default. >>>> so I can do >>>> echo 0 >/proc/fs/cifs/OplockEnabled >>>> but that won't persist through a driver reload. so we tried adding this to /etc/sysctl.conf: >>>> fs.cifs.OplockEnabled = 0 >>>> however: >>>> >>>> root@nl14s0008-vm1:~# echo 0 >/proc/fs/cifs/OplockEnabled >>>> root@nl14s0008-vm1:~# cat /proc/fs/cifs/OplockEnabled >>>> 0 >>>> root@nl14s0008-vm1:~# modprobe -r cifs >>>> root@nl14s0008-vm1:~# tail -1 /etc/sysctl.conf >>>> fs.cifs.OplockEnabled = 0 >>> >>> IIUC, CIFS OplockEnabled is not a proper sysctl, it is just a proc >>> entry. Sysctls are listed below /proc/sys/ directory. >>> >>> For e.g. try >>> sysctl -w fs.cifs.OplockEnabled=0 >>> >>> you'll see the error: "/proc/sys/fs/cifs/OplockEnabled: No such file or >>> directory". Also, >>> >>> sysctl -p >>> >>> will throw the error: "/proc/sys/fs/cifs/OplockEnabled: No such file or >>> directory" >>> >>> It is not clear to me why do you want to unload and reload cifs module >>> often? The general usage is load module during boot or on first use and >>> the module lives on till the machine goes down. >>> >>> I'm not seeing an justification for making it an module parameter. Could >>> you please explain more on how it will be useful? >>> >> >> I agree with Alexander on this one... >> >> Making that a module parm would allow you to set that parameter at boot >> time without needing to add special startup scripts. IMO, all of the >> procfile "switches" under /proc/fs/cifs should be module parms >> instead. > > Making it a module parm would mean that it would no longer be possible > to dynamically change OplockEnabled. But, that might be Ok, because it > is quite unusual to change this setting once the module is loaded, > right?. Also, someone won't be able to see what is the current setting. > Again, not a big deal. > >> That would also allow us to get rid of some of the special procfile >> handling code for those files as well. >> > > Agreed. > > I'll whip up a patch and post it soon. > > > -Suresh > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
