Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: VFAT truncate performance | Date | Tue, 05 Sep 2006 21:38:45 +0200 |
| |
Mattias Rönnblom <hofors@lysator.liu.se> wrote:
> extending files by ftruncate(2) runs very slow on VFAT file > systems. On my USB harddisk w/ VFAT, it takes 14 seconds to extend an > empty file to 1 GB. On a memory stick, it takes well over 4 minutes. > > My question is: is this problem on the conceptual level (ie there is > no way of extending files on FAT that doesn't involve many disk > operations) or is the current Linux fs driver suboptimal in this > respect?
Linux needs to zero files it truncate-extends because of security guarantees.
You could temporarily ignore the truncate after create if it's followed by writing the file (defer untill first non-write), but it will be a BAD hack. It might work.
Default: open(O_WRITE|O_CREAT|O_TRUNC) -> do it, goto State 1 otherwise -> just do it
State 1: ftruncate -> remember offset instead of executing ftruncate, goto State 2 otherwise -> goto Default
State 2: write -> do it, stay in State 2 unless file size increases beyond fake size, then goto Default stat -> return fake size otherwise -> really do ftruncate, goto Default
It might cause some operations to be slow you'd expect to be fast, and I'm not sure how it has to deal with concurrent access. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren.
http://david.woodhou.se/why-not-spf.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |