Subject: Re: [linux-audio-dev] using ext2fs "holes" in files
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma loka 18 1999 - 15:02:23 EDT
>*You do want* use some kludge mixtura of files and possible editlist
>(which about -- as used with your kludge -- I have not seen anything here).
Juhana, i don't know about you, but as a programmer, i take the phrase
"your kludge" rather personally. i don't know if its how you meant it,
but it comes across to me as a very negative and rather personal
statement.
first of all, i would have to be stupid to be against editlists for
programs that *edit* files and want to do so in an efficient,
non-destructive fashion. However, neither of those characteristics
describe my program. my not using an editlist has *nothing* do do with
the fact that a filesystem supports "holes" in files - it is because
my program doesn't do anything that makes sense for editlist use. if i
gave you the impression that i planned to use an editlist as well,
then i gave you the wrong impression, somehow.
furthermore, i don't rely in any way on whether or not "holes" are
supported. all i do is to lseek to the right offset in a file and
write there: i don't care whether the fs zero fills real disk blocks,
uses holes or whatever. All I care about is that POSIX says that
whenever i read back the file, I will read zeros in from any offsets
that I skipped without having previously written them.
it just so happens that ext2fs (and some of its predecessor file
systems) were designed to allow files with "holes" as an efficient use
of disk space, but thats just an implementation detail that adds an
additional, but not central argument in favor of doing this.
>When a third party program reads your files, it doesn't see your kludge
>file system usage -- you need to pass an editlist separately in anyway.
>So, why to complicate the system with some kludge?
No! Please read the man page for lseek(2). When *any* program reads a
file with holes, it reads zeroes for as many bytes as the hole is
large. Why do you keep calling this a kludge ? there is no way for an
application to have any idea that it is reading a hole instead of
zeroes from the disk except for speed of access (the holes will be
faster) or by carefully checking the results of various system calls
like stat(2).
let me say that again: *ANY* program can read a file created with
holes, without any special tricks or knowledge about the structure of
the file. but they are not a substitute for an editlist where an
editlist makes sense. not least because once you write any data to a
byte within the hole, that byte can never return to being part of a
hole (and, given implementation realities, neither can the disk block
it was part of).
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST