Performance optimization in av::fixup - use buffered IO, not mapped file

Corinna Vinschen
Wed Dec 12 15:37:00 GMT 2012

On Dec 12 08:16, Eric Blake wrote:
> On 12/12/2012 07:31 AM, Corinna Vinschen wrote:
> > On Dec 12 07:04, Eric Blake wrote:
> >> On 12/12/2012 06:22 AM, Corinna Vinschen wrote:
> >>> On Dec 12 06:11, Eric Blake wrote:
> >>>> Eww.  That would be a regression for coreutils, [...]
> >>>
> >>> Really?  How so?
> >>
> >> When using 'cp --sparse=always', coreutils relies on lseek() to create
> >> sparse files.  Removing this code from cygwin would mean that coreutils
> >> now has to be rewritten to explicitly ftruncate() instead of lseek() for
> >> creating sparse files.
> > 
> > On Cygwin only or on Linux as well?
> On cygwin only.

Oh, erm... I asked the wrong question, apparently.  What I meant to ask
was if cp uses lseek-only on Cygwin only.  But, no, it uses lseek in the
general case and expects the attempt to sparsify the file to be honored.

> >> of using ftruncate() when plain lseek() would do to keep them sparse.
> > 
> > Couldn't Devil's advocate also argue that coreutils are wrong?
> If ftruncate() is the only way on cygwin to make a sparse file, I
> suppose coreutils could adapt.

I guess so, but I was more interested to try to do the right thing in
Cygwin in the first place.  Given cp's behaviour, and reading up on the
issue (again) seems to imply that Cygwin is basically doing the right
thing.  The crude check for a minimum 128K hole was already a trade off
between getting automatic sparse files, as on ext FS, and Windows' NTFS
driver slowness in handling sparse files.

FTR: Given this slowness, there might be some value in having a mount
option to suppress sparse file generation.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list