1. 29 9月, 2007 1 次提交
  2. 18 7月, 2007 1 次提交
  3. 13 7月, 2007 1 次提交
  4. 10 7月, 2007 1 次提交
  5. 08 7月, 2007 1 次提交
  6. 22 1月, 2007 1 次提交
  7. 08 12月, 2006 2 次提交
  8. 13 10月, 2006 1 次提交
  9. 29 9月, 2006 1 次提交
  10. 01 6月, 2006 1 次提交
  11. 05 3月, 2006 1 次提交
    • S
      [CIFS] Always match oplock break (cache notification) to the right tcp · e77e6f3b
      Steve French 提交于
      session when multiply mounted.
      
      Fixes slow response when cifs client is mounted to shares on multiple
      servers and oplock break occurs (usually due to attempt to multiply open a
      file).  When treeids on mutiple mounted shares match and we find the wrong
      match first, we searched for the wrong cached files to send oplock break
      response for which usually meant that no matching file was found and thus
      the server would have to timeout the notification.  Oplock break timeout is
      about 20 seconds on some servers so this could cause significantly slower
      performance on file open calls in a few cases (in particular when multiple
      shares are mounted from multiple servers, tree ids match, and we have a
      cached file which is later opened multiple times).  This was the most
      important of the bugs that was found and fixed at Connectathon
      (interoperability testing event) this week.
      
      Acked-by:  Shaggy (shaggy@austin.ibm.com)
      Signed-off-by: Steve French (sfrench@us.ibm.com)
      e77e6f3b
  12. 03 3月, 2006 1 次提交
  13. 02 3月, 2006 1 次提交
  14. 24 2月, 2006 1 次提交
  15. 22 2月, 2006 1 次提交
  16. 13 12月, 2005 1 次提交
  17. 04 12月, 2005 1 次提交
  18. 02 12月, 2005 1 次提交
  19. 30 11月, 2005 1 次提交
  20. 12 11月, 2005 1 次提交
  21. 07 11月, 2005 1 次提交
  22. 11 10月, 2005 1 次提交
  23. 23 9月, 2005 1 次提交
  24. 22 9月, 2005 1 次提交
  25. 25 8月, 2005 1 次提交
  26. 20 8月, 2005 1 次提交
  27. 18 8月, 2005 1 次提交
  28. 15 8月, 2005 1 次提交
  29. 15 7月, 2005 1 次提交
  30. 18 5月, 2005 1 次提交
  31. 29 4月, 2005 4 次提交
  32. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4