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/
