X-Spam-Check-By: sourceware.org
X-BigFish: V
From: Vladimir Dergachev <vdergachev AT rcgardis DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: NTFS fragmentation
Date: Thu, 3 Aug 2006 14:54:33 -0400
User-Agent: KMail/1.9.3
References: <065901c6b72b$e07aaa90$a501a8c0 AT CAM DOT ARTIMI DOT COM>
In-Reply-To: <065901c6b72b$e07aaa90$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200608031454.33341.vdergachev@rcgardis.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On Thursday 03 August 2006 2:37 pm, Dave Korn wrote:
> On 03 August 2006 18:50, Vladimir Dergachev wrote:
> > On Thursday 03 August 2006 5:18 am, Dave Korn wrote:
> >> On 03 August 2006 00:46, Vladimir Dergachev wrote:
> >>
> >>
> >>     Hi Vladimir,
> >>
> >>>>> Please CC me - I am not on the list.
> >>
> >>   Done :)
> >>
> >
> > I guess this means that sequential writes are officially broken on NTFS.
> >
> > Anyone has any idea for a workaround ? It would be nice if a simple
> > tar zcvf a.tgz * does not result in a completely fragmented file.
>
>   I can only think of one thing worth trying off the top of my head: what
> happens if you open a file (in non-sparse mode) and immediately seek to the
> file size, then seek back to the start and actually write the contents?  Or
> perhaps after seeking to the end you'd need to write (at least) a single
> byte, then seek back to the beginning?
>

I am not sure that I understand, if one creates the file and then seeks to 
+1G, wouldn't the file pointer be still at 0 as the filesize is 0 ?

What I am thinking about is modifying cygwin's open and write calls so that 
they preallocate files in chunks of 10MB (configurable by an environment 
variable). 

This way we still get some fragmentation, but it would not be so bad - 
assuming 50MB/sec disk read speed reading 10MB will take 200ms, while a seek 
is at worst 20ms (usually around 10-15ms).

                                     best

                                            Vladimir Dergachev


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