>[EMAIL PROTECTED] writes:
> > Why require two separate fsync() calls when one
> > will do?
>
>Because it's faster to only do the one. What is the point of spending
>10% of your disk throughput taking steps to prevent something that
>never happens?
"never happens" != "can't happen". My impression is that qmail users
are more interested in the latter claim than in the former. ;-/
> > Further, what is the point if the first fsync() call
> > is useless without the second, and vice versa?
>
>Because the ext2 filesystem has the ability to rebuild the file from
>the data.
I've been assuming something throughout this interchange, and
would like some confirmation.
Russ, is it your contention that if a program reliably fsync()'s
a *file* it is writing, and if the OS/filesystem/etc. isn't buggy,
that there exists no window of time during which a crash will lose
that file *or* data such that neither of the following will be
true following a reboot running fsck:
- The file and its data will appear at the appropriate inode
and in the appropriate directory
- The file and its data will appear at the appropriate inode
and in /lost+found
Reason I ask is, I can certainly see the utility of making sure file
*contents* aren't lost as distinct from ensuring the file's name's
*directory entry* isn't lost. If the former is needed but not the
latter, and if the file contents offer enough info for a human or
program to move it back to where it belongs (and do whatever relevant
cleanup is needed)...
...then I agree that there's a performance benefit available, at least
in theory, to programs that don't need to fsync() the parent directory
of a file, as long as that isn't *implicit* when fsync()'ing the file
itself.
Now, if the data's still intact but the file doesn't necessarily show
up anywhere on the file system, e.g. in /lost+found, the question is,
can that data be overwritten during system operation prior to a search-
and-rescue mission being undertaken? If so, then the data isn't really
intact. Again, this might "never happen", but it surely *can* happen
that fsync()'ing a file isn't enough to ensure that its data is intact
for long enough after a crash/power-off to reliably restore it to its
proper position in the filesystem.
tq vm, (burley)
P.S. Apologies to those who think I should say "Now, if the data're still
intact...". I usually stick with the singular form in casual
correspondence. I've used the plural in technical writing, but have
also seen persuasive explanations of why I shouldn't. ;-\
