| commit | a9d52b76688f644d63b53aaf4884cf686b0131ff | |
| author | Matthew Dillon <dillon@dragonflybsd.org> | |
| Sat, 28 Jun 2008 18:10:55 +0000 (28 18:10 +0000) | ||
| committer | Matthew Dillon <dillon@dragonflybsd.org> | |
| Sat, 28 Jun 2008 18:10:55 +0000 (28 18:10 +0000) | ||
| tree | a94cd4e0d6a436c8221aeedeb27cb613ab899db7 | treesnapshot (tar.gz zip) |
| parent | c4df96359ae35da7b72c09f633437f5c4a8f33b7 | commitdiff |
HAMMER 59C/Many: Stabilization pass - fixes for large file issues
* Rename hammer_delete_range_all() to hammer_delete_clean(). This function
is no longer responsible for deleting data and db records when a file
is removed. The normal hammer_delete_range() function now does that for
all cases.
* Adjust hammer_delete_range() to not restart at offset 0 when it hits a
deadlock or must defer the remainder of the operation to another flush
cycle. When removing very large files (greater then 500GB) the constant
restarts resulted in exponential delays.
Instead the function restarts near where it had left off the previous try.
* Change ip->sync_trunc_off's dynamics so it can be used to cache the
restart offset. The truncation state can now be left intact on the
backend and the frontend will merge new truncations into it instead
of replacing the truncation.
Add a new field, ip->save_trunc_off to handle the append overwrite
check optimization (sync_trunc_off used to be used for that, no longer).
* Fix minor bugs, and use the new bwillwrite() API.
* Remove the #if 0'd out cluster_write() code entirely (it never worked
anyway). The new buffer cache subsystem in the kernel allows bdwrite()
to be used with no real penalty.
* Rename hammer_delete_range_all() to hammer_delete_clean(). This function
is no longer responsible for deleting data and db records when a file
is removed. The normal hammer_delete_range() function now does that for
all cases.
* Adjust hammer_delete_range() to not restart at offset 0 when it hits a
deadlock or must defer the remainder of the operation to another flush
cycle. When removing very large files (greater then 500GB) the constant
restarts resulted in exponential delays.
Instead the function restarts near where it had left off the previous try.
* Change ip->sync_trunc_off's dynamics so it can be used to cache the
restart offset. The truncation state can now be left intact on the
backend and the frontend will merge new truncations into it instead
of replacing the truncation.
Add a new field, ip->save_trunc_off to handle the append overwrite
check optimization (sync_trunc_off used to be used for that, no longer).
* Fix minor bugs, and use the new bwillwrite() API.
* Remove the #if 0'd out cluster_write() code entirely (it never worked
anyway). The new buffer cache subsystem in the kernel allows bdwrite()
to be used with no real penalty.