Axel Dörfler 3d268eda3d * Extracted file_map API out of the file cache - it's now an optional service
that can be used by file systems.
* Changed the way the file cache works: instead of reading/writing to the
  underlying device directly, it can now be used for any data source, ie.
  also network file systems.
* As a result, the former pages_io() moved to the VFS layer, and can now be
  called by a file system via {read|write}_file_io_vec_pages() (naming
  suggestions are always welcomed :-)). It now gets an FD, and uses that to
  communicate with the device (via its fs_{read|write}_pages() hooks).
* The file_cache_{read|write}() functions must now be called without holding
  an I/O relevant file system lock. That allows the file cache to prepare the
  pages without colliding with the page writer, IOW the "mayBlock" flag can
  go into the attic again (yay!).
* This also results in a much better performance when the system does I/O and
  is low on memory, as the page writer can now finally write back some pages,
  and that even without maxing out the CPU :)
* The API changes put slightly more burden on the fs_{read|write}_pages()
  hooks, but in combination with the file_map it's still pretty straight
  forward. It just will have to dispatch the call to the underlying device
  directly, usually it will just call its fs_{read|write}_pages() hooks
  via the above mentioned calls.
* Ported BFS and FAT to the new API, the latter has not been tested, though.
* Also ported the API changes to the fs_shell. I also completely removed its
  file cache level page handling - the downside is that device access is no
  longer cached (ie. depends on the host OS now), the upside is that the code
  is greatly simplified.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22886 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-11-10 21:19:52 +00:00
..
2007-10-15 14:09:14 +00:00