On Wednesday, July 31, 2002, at 08:16 , Justin C. Walker wrote: On Tuesday, July 30, 2002, at 02:51 PM, Pelle Johansson wrote: torsdagen den 25 juli 2002 kl 03.15 skrev Wade Tregaskis: Is this still an efficient way of operating, in an increasingly linear [e. g. single-user] OS? I'm just thinking, if you could return from writes faster, the calling process can keep doing other things. My thought is that you could do this without breaking existing apps by performing any error checking [i.e. quickly verifying there is free space, among other things] immediately, returning fail if appropriate, or otherwise returning no error. You could then worry about physically getting the data to disk, seeing as this is the most time intensive part... Side note: I was taught that if you know how large a file you want to write you should use ftruncate() to set the file size before writing. That way the OS can optimize the location of the file on the hard drive. I've noticed Unix application are quite bad at doing this, so perhaps it doesn't apply in some OSes. Most Unices won't take advantage of this 'optimization', because the typical Unix file system allows 'holes' in the allocation. Thus, if you create an empty file, and truncate (or seek to a far corner of the universe), and write a byte, the intervening space will *not* be allocated. This is dependent on the type of file system, of course. The HFS+ file system does not support 'holes'. A.K.A. sparse files, and depending on the backup tool used, can make life with Oracle databases interesting (think a tool which "makes" holes when restoring zeroed blocks, and the filesystem fills up six months later for no apparent reason...) Always cute to see in the flesh - this is on a NetBSD box: bash$ df -k . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd1a 3942626 1791392 1954102 47% /export/home bash$ touch sparse bash$ dd if=/dev/zero of=sparse bs=4k count=1 seek=4m 1+0 records in 1+0 records out 4096 bytes transferred in 0.001 secs (4096000 bytes/sec) bash$ ls -l sparse -rw-r--r-- 1 stix users 17179873280 Aug 1 23:47 sparse bash$ du -sk sparse 24 sparse bash$ Cheers, -- Paul Ripke Unix/OpenVMS/DBA 101 reasons why you can't find your Sysadmin: 68: It's 9AM and they're not working that late. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.