Re: How do disk writes work these days?
Re: How do disk writes work these days?
- Subject: Re: How do disk writes work these days?
- From: Paul Ripke <email@hidden>
- Date: Fri, 2 Aug 2002 00:00:28 +1000
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.