| |||||||||||||
Where the the correctness go?Where the the correctness go?Posted Mar 14, 2009 4:24 UTC (Sat) by flewellyn (subscriber, #5047)In reply to: Where the the correctness go? by foom Parent article: Ts'o: Delayed allocation and the zero-length file problem
> I see people arguing against the idea that zeroing out files is a good quality for a filesystem to have.
Which has what to do with the filesystem itself? I mean, if you use O_TRUNC when you call open(), zeroing out the file is exactly what you are asking to happen. Doing this and then writing new data to the file without calling fsync() before closing it, is where the problem comes from.
People should not blame the filesystem for doing what they ask it to do.
(Log in to post comments)
Where the the correctness go? Posted Mar 14, 2009 5:16 UTC (Sat) by foom (subscriber, #14868) [Link]
Open a brand new file, write, close, "atomic" rename on top of an existing file. No O_TRUNC. This
sequence causes the problem.
Where the the correctness go? Posted Mar 14, 2009 5:33 UTC (Sat) by flewellyn (subscriber, #5047) [Link]
Hmm...in that case, definitely fsync after rename.
Where the the correctness go? Posted Mar 15, 2009 1:43 UTC (Sun) by droundy (subscriber, #4559) [Link]
Sorry, that's wrong. fsync before rename.
Where the the correctness go? Posted Mar 14, 2009 6:21 UTC (Sat) by bojan (subscriber, #14302) [Link]
Please read the manual page for close(). Just because you closed the file doesn't mean your data is on disk.
As for rename, your file gets renamed _atomically_ just fine. However, if you don't _commit_ your writes (make the changes durable, call fsync), the renamed file will have zero size.
This is not a file system problem, but an application problem.
|
|||||||||||||