I'm personally concerned about hand-held, and in case of UBIFSWe have a problem that user-space people do not want toWell... they really don't want to spin the disk up for the
use 'fsync()', even when they are pointed to their code
which is doing create/write/rename/close without fsync().
fsync(). I'm not sure if fsync() is really sensible operation to use
there.
fsync is not too expensive - we work on flash and on fsync() we
write back only the stuff belonging to inode in question, and
nothing else.
Well, I'm more concerned about spinning disks, having one even in my
zaurus. And I do believe that fsync() will write more data than
neccessary even in flash case.
In FS, or in application?1. truncate/write/close leads to empty filesthis is buggy.
Application is buggy; no way kernel can help there.
Well, OK, we can fsync() before rename, we just need clean rules2. create/write/rename leads to empty files..but this should not be. If we want to make that explicit, we should
provide "replace()" operation; where replace is rename that makes sure
that source file is completely on media before commiting the rename.
for this, so that all Linux FSes would follow them. Would be nice
to have final agreement on all this stuff.
My proposal is
rename() stays.
replace(src, bar) is rename that ensures that bar will contain valid
data after powerfail.
It is somehow similar to fsync()/rename(), but does not force diskRight. But I guess only few file-systems would really implement
spin up immediately -- it only inserts "barrier" between data blocks
and rename. (And yes, it should be implemented as fsync()+rename() for
filesystems like xfs. It can be implemented as plain rename for ext3
and ext4 after the fixes...)
this, because this is complex.
Complex yes, but at least ext3+ext4+btrfs should, and they really have
90% of "market share" :-). ext3 and ext4 implementations are already
done :-).
Pavel