Mail Archives: cygwin/2006/08/03/14:57:30
On Aug 3 13:22, Igor Peshansky wrote:
> On Thu, 3 Aug 2006, Corinna Vinschen wrote:
> > On Aug 3 01:54, Eric Blake wrote:
> > > it would be accepted upstream. Now if there were something more
> > > POSIX-y that we could do to speed things up, such as posix_fadvise,
> >
> > posix_fadvise can't be implemented nicely, AFAICS. The POSIX semantics
> > require an already opened file and the advice is given for an offset and
> > a length. The Windows semantics only allow to give the advice for the
> > whole file, and only switching between FILE_SEQUENTIAL_ONLY or "normal",
> > using ZwSetInformationFile. By re-opening the file using ZwOpenFile it
> > would also be possible to toggle the FILE_RANDOM_ACCESS flag. Still,
> > it's always for the whole file, not for an area giving offset and length.
>
> Theoretically, it's possible to implement posix_fadvise only for offset=0
> and length=<length-of-file>, and have it fail with EINVAL otherwise...
> While technically not POSIX-compliant, it would still allow for better
> implementation of things like copy...
Right. Now for the next problem. Could anybody be bothered to actually
test the performance effect of setting FILE_SEQUENTIAL_ONLY when reading
and writing files sequentially as cp does? It would be quite interesting
to get some real numbers on FAT and NTFS, before implementing posix_fadvice
just to find out that it has no practical effect. If it's less than 10%
it's not worth the effort, imo.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -