[Gambas-user] fastest way to "zero-out" a huge binary file

nando nando_f at ...951...
Sun Jan 24 04:39:21 CET 2010


Gentlemen,
The Gambas program below does not write ZERO's in all locations.
The part of the file that is before the seek will have garbage
and if you found them to appear to be zero, you are just lucky - this time.

perform this shell command:

dd if=/dev/zero of=Elevation.tmp bs=65537 count=65537

This is the absolute fastest way to do it.
-Fernando



---------- Original Message -----------
From: kevinfishburne <kevinfishburne at ...1887...>
To: gambas-user at lists.sourceforge.net
Sent: Sat, 23 Jan 2010 19:21:33 -0800 (PST)
Subject: Re: [Gambas-user] fastest way to "zero-out" a huge binary file

> Benoît Minisini wrote:
> > 
> > On Linux, If you seek and write past the real end of a file, then the file
> > is 
> > automatically extended.
> > 
> > So the simplest is writing where you want in the file only when you need.
> > Just 
> > don't do that randomly, to prevent the disk from seeking too much.
> > 
> > Most Linux file systems will reserve only pieces where something was
> > written. 
> > The other part of the file that are only zeros are virtual, and will not 
> > consume your hard disk.
> > 
> > Anyway, why do you need 8Gb of data at once?
> >
> 
> Hi Benoît. I tried:
> 
> IF NOT Exist("~/.Littoral") THEN MKDIR "~/.Littoral"
> Elevation = OPEN "~/.Littoral/Elevation.tmp" FOR INPUT OUTPUT CREATE
> SEEK #Elevation, 8590196738
> WRITE #Elevation, Chr$(0)
> 
> and it creates a 262,148 byte file. That's four bytes larger than a 256K
> file. Checking the file in a hex editor it appears that all bytes are zero
> except for byte 262,147, which is one.
> 
> For my purposes I prefer the file to be pre-allocated so that it can be as
> contiguous as possible. I need to minimize read/write access times as much
> as possible or my app may take all day to run.
> 
> The reason for such a large file is because I'm writing a terrain generation
> app that generates a 65,537x65,537 vertex elevation map at 1 foot per vertex
> resolution (12x12 miles). Each vertex uses a short, or two bytes, to
> represent its elevation (65,537x65,537x2). I'm using a variation of the
> diamond square algorithm modified by a user-supplied height field that
> guides the terrain generation. Ultimately the resulting data file will be
> stored server-side, so size isn't an object.
> 
> -----
> Kevin Fishburne, Eight Virtues
> www:  http://sales.eightvirtues.com http://sales.eightvirtues.com 
> e-mail:  mailto:sales at ...1887... sales at ...1887... 
> phone: (770) 853-6271
> -- 
> View this message in context: http://old.nabble.com/fastest-way-to-%22zero-
> out%22-a-huge-binary-file-tp27290885p27292087.html Sent from the gambas-user 
> mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
------- End of Original Message -------




More information about the User mailing list