Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
To: <cygwin AT cygwin DOT com>
Subject: RE: SPARSE files considered harmful - please revert
Date: Sat, 24 May 2003 21:26:06 -0500
Message-ID: <NCBBIHCHBLCMLBLOBONKIEDKEDAA.g.r.vansickle@worldnet.att.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
In-Reply-To: <20030524173811.GA5141@redhat.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal

> 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/