| /haiku/headers/private/fs_shell/ |
| H A D | fssh_fs_cache.h | 4612433715fc0477740693682ec4a642c1a4c6e1 Sat Aug 30 23:06:28 UTC 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added parameter "size_t align" to file_map_translate(). If > 1, the
vector at the end of the file will be aligned to the given value.
* BFS uses an alignment of 512 bytes (should be block size of the
underlying device or BFS block size, whatever is less), which should
be fine, since file data are only stored in BFS blocks. This totally
avoids any partial operations at the I/O scheduler level, thus saving
disk operations. Not that I could measure any performance difference.
Theoretically it should help a lot though, particularly when dealing
with lots of small files, since we avoid using bounce buffers, which
are (a) limited in number and (b) require copying of the data.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27246 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/headers/os/drivers/ |
| H A D | fs_cache.h | 4612433715fc0477740693682ec4a642c1a4c6e1 Sat Aug 30 23:06:28 UTC 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added parameter "size_t align" to file_map_translate(). If > 1, the
vector at the end of the file will be aligned to the given value.
* BFS uses an alignment of 512 bytes (should be block size of the
underlying device or BFS block size, whatever is less), which should
be fine, since file data are only stored in BFS blocks. This totally
avoids any partial operations at the I/O scheduler level, thus saving
disk operations. Not that I could measure any performance difference.
Theoretically it should help a lot though, particularly when dealing
with lots of small files, since we avoid using bounce buffers, which
are (a) limited in number and (b) require copying of the data.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27246 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/src/system/kernel/cache/ |
| H A D | file_map.cpp | 4612433715fc0477740693682ec4a642c1a4c6e1 Sat Aug 30 23:06:28 UTC 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added parameter "size_t align" to file_map_translate(). If > 1, the
vector at the end of the file will be aligned to the given value.
* BFS uses an alignment of 512 bytes (should be block size of the
underlying device or BFS block size, whatever is less), which should
be fine, since file data are only stored in BFS blocks. This totally
avoids any partial operations at the I/O scheduler level, thus saving
disk operations. Not that I could measure any performance difference.
Theoretically it should help a lot though, particularly when dealing
with lots of small files, since we avoid using bounce buffers, which
are (a) limited in number and (b) require copying of the data.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27246 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/src/add-ons/kernel/file_systems/ext2/ |
| H A D | kernel_interface.cpp | 4612433715fc0477740693682ec4a642c1a4c6e1 Sat Aug 30 23:06:28 UTC 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added parameter "size_t align" to file_map_translate(). If > 1, the
vector at the end of the file will be aligned to the given value.
* BFS uses an alignment of 512 bytes (should be block size of the
underlying device or BFS block size, whatever is less), which should
be fine, since file data are only stored in BFS blocks. This totally
avoids any partial operations at the I/O scheduler level, thus saving
disk operations. Not that I could measure any performance difference.
Theoretically it should help a lot though, particularly when dealing
with lots of small files, since we avoid using bounce buffers, which
are (a) limited in number and (b) require copying of the data.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27246 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/src/add-ons/kernel/file_systems/bfs/ |
| H A D | kernel_interface.cpp | 4612433715fc0477740693682ec4a642c1a4c6e1 Sat Aug 30 23:06:28 UTC 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added parameter "size_t align" to file_map_translate(). If > 1, the
vector at the end of the file will be aligned to the given value.
* BFS uses an alignment of 512 bytes (should be block size of the
underlying device or BFS block size, whatever is less), which should
be fine, since file data are only stored in BFS blocks. This totally
avoids any partial operations at the I/O scheduler level, thus saving
disk operations. Not that I could measure any performance difference.
Theoretically it should help a lot though, particularly when dealing
with lots of small files, since we avoid using bounce buffers, which
are (a) limited in number and (b) require copying of the data.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27246 a95241bf-73f2-0310-859d-f6bbb57e9c96
|