Messages in this thread |  | | Date | Sat, 2 Sep 2000 22:43:13 -0700 (PDT) | From | Linus Torvalds <> |
| |
On Sat, 2 Sep 2000, Alexander Viro wrote: > + > + /* > + * So truncate in the middle of a hole not on a block boundary will > + * allocate a block. BFD. Everything is still consistent, so trying > + * to be smart is not worth the trouble. > + */
You don't actually have to be smart.
There's a really simple way to avoid this: compare the thing you're going to zero out against zero before you memset() it to zero. If it was already zero, you just unlock the page and release.
Downside: you have to read the page in, in order to compare. However, this turns out to be a non-issue: if there were no blocks on that page (like a forward truncate) this ends up generating no IO anyway. If there _were_ blocks on the page, it's likely that one of them was the one we're going to partially clear anyway, so the "prepare_write()" would have had to read it in anyway.
Upside: you don't need to mark it dirty unnecessarily, assuming you just extended the file. No extra allocation, and no extra write to disk.
Comments? Basically the "grab_cache_page()" would be a "read_cache_page()" instead with all the wait-on-page etc stuff.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |