Mail Archives: cygwin/2003/05/24/22:31:27
> On Sat, May 24, 2003 at 09:58:13AM +0200, Lapo Luchini wrote:
> >Rolf Campbell wrote:
> >
> >>>3) What no one seems to be mentioning is that we are trying to emulate
> >>>UNIX behavior here. If the above is an issue for Windows then it could
> >>>also be an issue for UNIX.
> >>
> >>And it is.
> >
> >e.g. from FreeBSD 4.8's "man mmap":
> >
> > WARNING! Extending a file with ftruncate(2), thus cre-
> > ating a big hole, and then filling the hole by modify-
> > ing a shared mmap() can lead to severe file fragmenta-
> > tion. In order to avoid such fragmentation you should
> > always pre-allocate the file's backing store by
> > write()ing zero's into the newly extended area prior to
> > modifying the area via your mmap(). The fragmentation
> > problem is especially sensitive to MAP_NOSYNC pages,
> > because pages may be flushed to disk in a totally ran-
> > dom order.
>
> And so, my point is proved.
>
Your point is what exactly, Chris? That Cygwin should duplicate any and all
dubious "features" of any and all Unii? Why? What benefit is anybody gaining
by essentially bypassing NTFS's "1 cluster==1 sector" abilities and going back
to the wonderous days of FAT16 on 99.9999999944% of all files created by Cygwin?
The only proof here, from the experiments of two people, is that this benefits
almost nobody while adversely affecting everybody.
Hell, why not just create every file as compressed? At least everybody would
gain something from that, and it'd do pretty much the same thing with that one
file that benefits from being marked sparse.
--
Gary R. Van Sickle
Brewer. Patriot.
--
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 -