Subject: Re: [linux-audio-dev] info point on linux hdr
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Apr 21 2000 - 16:53:13 EEST
In message <390050A4.AECC1F7_AT_jlaako.pp.fi>you write:
>Paul Barton-Davis wrote:
>>
>> ftruncate does *not* allocate disk blocks. it cannot be used this
>> way. all it does it to set the length of the file. the disk blocks are
>> not allocated until a write to them occurs.
>
>Would this be faster than writing every byte of file at preallocation time?
I don't.
>ftruncate(desired file size)
>for (fileposition < file size; fileposition += blocksize)
> lseek(fileposition)
> write(something, sizeof(dword))
>
>Block size here means bytes per inode.
Nope, it means the filesystem block size (typically 2 or 4K for ext2
filesystems).
>This tries to do same with files as memory management do when committing
>memory pages. Just touching every "page" would be enough to do the
>allocation? I think preallocating large files by writing every byte of file
>is waste of bandwidth..
This is exactly what I do now. but you make the same mistake that i
did (until stephen tweedie and others thankfully corrected me), in
forgetting that all filesystem i/o happens in units of fs blocks. if
the fs blocksize is 4K, then a request to write 1 byte to the file
results in 4k of writing. You can't ever just write 1 byte of a file,
when it gets down to the actual disk i/o level, unless you are using
raw i/o (and perhaps not even then).
also, in the code you show, the ftruncate is redundant, because it
doesn't allocate any blocks, and the point of preallocation (if there
is one) is to get the blocks allocated in a certain way.
--p
This archive was generated by hypermail 2b28 : Fri Apr 21 2000 - 17:29:24 EEST