[lkml]   [2006]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: VFAT truncate performance
Mattias Rönnblom <> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-05 21:45    [W:0.022 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site