http://bugs.winehq.org/show_bug.cgi?id=14914
--- Comment #20 from Marcus Blomenkamp mblomenk@gmx.de 2008-08-23 09:21:53 --- (In reply to comment #19)
On Linux 2.4 kernels sendfile() would always fail when writing to a sparse region of a file, but on 2.6 kernels sendfile() only works from a file to a socket so that's not a problem. Wine doesn't use sendfile(), but other software using files created by Wine could: Java did at some stage but recent versions fall back to traditional I/O when it fails. Thus a sparse region could cause trouble on older setups, but that problem is hardly Wine specific.
Thanks for pointing out other problematic usecases, although, as you said yourself, their relevance is diminishing.
Native Linux filesystems should minimize fragmentation with random writes to a sparse file, so this seem more of a *nix/NTFS interoperability issue; on *nix sparse files are a long standing default, while on NTFS they seem to be a badly supported opt-in novelty.
Use a better filesystem or defragment often.
I have a different opinion on that and consider EXT4 with delayed allocation switched-on as the only Linux-specific filesystem capable of theoretically avoiding fragmentation. XFS is a different matter, because until recently it only showed its true potentiontal on its native OS with certified hardware. And i assume Linux driver still does not implement all of its often-quoted features. NTFS isn't that bad as a filesystem itself, it's the Windows applications (Explorer etc) that do not honour its features properly. BTW: Do you defragment your Linux filesystems while they are in-use? I would be interested in getting to know how that can be done safely.
But that is getting off-topic.
On-topic is however that EXT3 with big sparse files written randomly in small chunks does fragment badly. And if the final files can only be read with average transfer rates of about 1MB/sec, then something has to be done about it. Which i tried to initiate in this thread, or at least initiate a discussion about useful semantics. But interpreting the responses, this initiative is unwanted. Interesting sidenote: I also discussed this issue whith the authors of the application in question (utorrent) and they will add a workaround for Wine, taking the approach that Alexandre has posted.