[Bug 14914] files are created as sparse files when they shouldn't

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Aug 23 09:21:55 CDT 2008


http://bugs.winehq.org/show_bug.cgi?id=14914





--- Comment #20 from Marcus Blomenkamp <mblomenk at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list