delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/08/02/19:15:26

X-Spam-Check-By: sourceware.org
Message-ID: <44D131F2.7000203@cygwin.com>
Date: Wed, 02 Aug 2006 19:14:58 -0400
From: "Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060112 Fedora/1.5-1.fc4.remi Thunderbird/1.5 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: vdergachev AT rcgardis DOT com
Subject: Re: NTFS fragmentation
References: <004401c6b688$a2ffd300$020aa8c0 AT DFW5RB41>
In-Reply-To: <004401c6b688$a2ffd300$020aa8c0@DFW5RB41>
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

Gary R. Van Sickle wrote:
> [cc'ing you per your request]
> 
>> From:  Vladimir Dergachev
>> Sent: Wednesday, August 02, 2006 5:33 PM
>> Subject: NTFS fragmentation
>>
>>
>> Hi all, 
>>
>>        I have encountered a rather puzzling fragmentation 
>> that occurs when writing files using Cygwin. 
>>
>>        What happens is that if one creates a new file and 
>> writes data to it (whether via a command line redirect or 
>> with a Tcl script - have not tried C
>> yet) the file ends up heavily fragmented. 
>>
>>        In contrast, native Windows utilities do not exhibit 
>> this issue.
>>
>>        Someone suggested to me that Windows requires an 
>> expected file length to be passed at the time of open, thus I 
>> searched on Google and found "fsutil" program that allows to 
>> reserve space on the filesystem.
>>
>>        I attached a small Tcl script that, when run, creates 
>> two 30 MB files - one using regular open/write pair (and 
>> which is fragmented into about 300 pieces on my system) and 
>> one using fsutil/open in append mode/seek 0 method.
>>
>>       To see the problem defragment your system, run the test 
>> script and then run analyze and ask to view report. You will 
>> see a.dat at top of the list, while b.dat never appears in 
>> the report. 
>>
>>        Despite the workaround, it is still kinda hard for me 
>> to believe that anyone has designed a filesystem that needs 
>> to know what is the file size going to be - especially for a 
>> single program writing on an almost empty disk. Perhaps there 
>> is some sort of environment variable that I need to set ?
>>
>>         Any suggestions and comments would be greatly 
>> appreciated.        
>> Please CC me - I am not on the list.
>>
>>                            thank you very much
>>
>>                                         Vladimir Dergachev
> 
> I'll try your test case when I get a chance, but my WAG is that you're
> seeing the effects of Cygwin's creation of sparse files by default for any
> file beyond a certain size.  I unfortunately do not recall what that size
> is.  What happens as you change FILE_SIZE and/or BUFFER_SIZE in your script,
> to maybe a small multiple of your cluster size?
> 


This clicked with me as well.  I was thinking first though to try it with
straight C, to remove the possibility of some TCL pollution.  Otherwise a
quick Google of "sparse" for cygwin dot com turns up lots of relevant hits,
utilities, and technical details.  Should be pretty easy to determine if the
resulting files are sparse or not with this info.


-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019