Bug 4651 - oplock issue!
oplock issue!
Status: RESOLVED WONTFIX
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Windows XP
: P3 normal
: ---
Assigned To: Steve French
:
: 4650 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-23 08:39 UTC by ylet
Modified: 2012-04-28 00:33 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ylet 2007-05-23 08:39:59 UTC
i am using three computer, named A,B,C , A and B all are linux and C is windowsXP
A is a samba(3.0.25) server ip 10.10.1.39 and B(kernel 2.6.21) 

B do the operations sequence 
B: mount -t cifs //10.10.1.39/sdb /mnt/sdb
B:service smb start (share name is sdb)
and B use samba(3.0.25) and have two NIC (10.10.1.151 and 10.10.2.151)

C mapped B's shared volume 
//10.10.1.151/sdb   to  Z:\
//10.10.2.151/sdb   to  Y:\

now, i begin to read the same file named x.dat from Z and Y

 added speed come from these two process is very slow!

i traced the oplock and i can see the client(B) first get the pSMB of OplockLevel=1 , and get the pSMB of OplockLevel=0 after seconds.   

this means when two and more process read the same file in above box, B can not cache files! why?
Comment 1 Steve French 2007-07-20 16:08:38 UTC
jra,
This is something we discussed and would be nice to be able to avoid on server side.

lonat,
Is the file opened both times with the same flags (if so a client optimization is possible)?
Comment 2 Steve French 2007-07-20 16:10:02 UTC
*** Bug 4650 has been marked as a duplicate of this bug. ***
Comment 3 ylet 2007-07-23 01:26:08 UTC
(In reply to comment #0)
> i am using three computer, named A,B,C , A and B all are linux and C is
> windowsXP
> A is a samba(3.0.25) server ip 10.10.1.39 and B(kernel 2.6.21) 
> 
> B do the operations sequence 
> B: mount -t cifs //10.10.1.39/sdb /mnt/sdb
> B:service smb start (share name is sdb)
> and B use samba(3.0.25) and have two NIC (10.10.1.151 and 10.10.2.151)
> 
> C mapped B's shared volume 
> //10.10.1.151/sdb   to  Z:\
> //10.10.2.151/sdb   to  Y:\
> 
> now, i begin to read the same file named x.dat from Z and Y
> 
>  added speed come from these two process is very slow!
> 
> i traced the oplock and i can see the client(B) first get the pSMB of
> OplockLevel=1 , and get the pSMB of OplockLevel=0 after seconds.   
> 
> this means when two and more process read the same file in above box, B can not
> cache files! why?
> 

(In reply to comment #1)
> jra,
> This is something we discussed and would be nice to be able to avoid on server
> side.
> 
> lonat,
> Is the file opened both times with the same flags (if so a client optimization
> is possible)?
> 

hi  steven
    Too long time be lapsed when i get your kindness reply. +_+  
    Because of C client using WINXP, and we use standard "copy" and "paste", we can not know whether the same flag be used by two processes.
 
Comment 4 ylet 2007-07-23 01:26:35 UTC
hi  steven
    Too long time be lapsed when i get your kindness reply. +_+  
    Because of C client using WINXP, and we use standard "copy" and "paste", we can not know whether the same flag be used by two processes.
Comment 5 Shirish S. Pargaonkar 2009-11-09 01:04:01 UTC
Lonat, I was trying to recreate the problem but not sure how exactly did you
do!  What was used to read the file on the Windows XP box (C)?
And I was wondering if it is possible to recreate this problem using C and
D i.e. two different boxes that mount a the same share from B.
Comment 6 Jeff Layton 2012-04-28 00:33:16 UTC
I guess the crux of this bug is a request to implement some sort of filehandle caching? That would be a nice to have, but there are a number of structural
changes that would need to go into place first.

Still no response to Shirish's query in more than 2 years however.  At this
point, I'm going to go ahead and close this bug WONTFIX. Please reopen if you wish to pursue it further.