Re: Performance issue when trashing files (backtraced to fsync)

[jcupitt gmail com]

2009/8/11  <jcupitt gmail com>:
> 2009/8/11 Alexander Larsson <alexl redhat com>:
>> Clearly we should do at least 3, which will fix this case (and other
>> similar tempfile cases). However, given the extremely bad performance
>> here we should maybe add the extra API in 2 allowing apps to avoid the
>> cost when needed? Its kinda ugly to expose that to users, but the
>> performance cost is pretty ugly too...
>
> I'm probably being stupid here, but how about putting the fsync in a
> timeout? Instead of calling fsync() directly, add a new thing called
> g_fsync_queue() which queues up an fsync 'soon'.

Oh ahem, I guess I'm thinking of sync() rather than fsync(). Though in
this case one sync() at the end of the delete would certainly be
faster than thousands of fsync()s.

John