Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <000801c2e974$0a0541b0$78d96f83@pomello> From: "Max Bowsher" To: References: <3E70AD52 DOT 744 DOT D4BC055 AT localhost> Subject: Re: cygwin-1.3.21-1, problem with sparse file creation as default Date: Thu, 13 Mar 2003 15:20:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Markus Mauhart wrote: > I have a problem with the following new feature of cygwin-1.3.21-1 > >> - Create sparse files by default, when possible. (Vaclav Haisman) > > Couldnt it be made configurable, or removed ? How about CYGWIN envvar triggered, and off by default? I'm building my own patched cygwin1.dll until this issue is resolved. > 1) good old file manager (winfile.exe from NT4 system) does not > display sparse files - so all newly created files (through gcc, or > make, > or "cp con 123.txt") are now invisible. (beside browsing, I didnt > test real file operations like move/copy a folder containing some > sparse files) > > > 2) AFAICS its advantages are very sparse ;-) Only when extending > a file's size the sytem (ntfs5+) automatically adds 'sparse' clusters. > Otherwise (even when writing 10G of all zero) not a single sector > is spared. Only programs aware of win32-sparse files profit from this > existing file-attribute when explicitely marking a range as zero, > but IMHO this is a micro-profit: such program can replace the > following code .... > > if (make_file_sparse(..)) mark_some_range_as_zero(..); > > ... with ... > > if (is_file_sparse(..)) mark_some_range_as_zero(..); > > Note, this was assuming the win32 file API. Are there any cygwin/GNU > file API's (except for file creation;-) which when used then > automatically profit from sparse files ? > > > 3) OTOH my guess is that it introduces more or less unnecessary > resource consumption (CPU and/or disk) ... one benchmark could be > building > gcc and messuring time and disk consumption, but last time I built gcc > was in 2001; maybe Vaclav Haisman could benchmark the pros and cons > of this new feature. (also defragmenting a volume with 10.000 of such > newly created 'pseudo-sparse' files might pay a price) We've had no proof of advantages (except in one very restricted corner case), and no disproof of disadvantages (i.e. speed penalties). Plus now an actual bug has surfaced. Can this be CYGWIN-conditionalized now? Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/