p3 1.4 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455
  1. .SH
  2. Buffer Cache
  3. .PP
  4. When the file server is
  5. booted,
  6. all of the unused memory is allocated to
  7. a block buffer pool.
  8. There are two major operations on the buffer
  9. pool.
  10. .CW Getbuf
  11. will find the buffer associated with a
  12. particular block on a particular device.
  13. The returned buffer is locked so that the
  14. caller has exclusive use.
  15. If the requested buffer is not in the pool,
  16. some other buffer will be relabeled and
  17. the data will be read from the requested device.
  18. .CW Putbuf
  19. will unlock a buffer and
  20. if the contents are marked as modified,
  21. the buffer will be written to the device before
  22. the buffer is relabeled.
  23. If there is some special mapping
  24. or CPU cache flushing
  25. that must occur in order for the physical I/O
  26. device to access the buffers,
  27. this is done between
  28. .CW getbuf
  29. and
  30. .CW putbuf .
  31. The contents of a buffer is never touched
  32. except while it is locked between
  33. .CW getbuf
  34. and
  35. .CW putbuf
  36. calls.
  37. .PP
  38. The
  39. file system server processes
  40. prevent deadlock in the buffers by
  41. always locking parent and child
  42. directory entries in that order.
  43. Since the entire directory structure
  44. is a hierarchy,
  45. this makes the locking well-ordered,
  46. preventing deadlock.
  47. The major problem in the locking strategy is
  48. that locks are at a block level and there are many
  49. directory entries in a single block.
  50. There are unnecessary lock conflicts
  51. in the directory blocks.
  52. When one of these directory blocks is tied up
  53. accessing the very slow WORM,
  54. then all I/O to dozens of unrelated directories
  55. is blocked.