Rodolphe Rocca wrote:
Ciaran McCreesh wrote:
On Sun, 04 Oct 2009 15:42:27 +0200
Rodolphe Rocca <[email protected]> wrote:
Maybe a forgotten fsync after writing the SLOT file ?
No, it's unrelated. We don't fsync anything, at all.
I'm not not a filesystem expert but isn't it the problem ?
First - apologies for replying to an otherwise-closed thread. Glad to
see that Ciaran isn't planning on making any changes.
Since this didn't come up I figured I'd add it - many people consider
the argument advanced in that blog you referenced bogus. That includes
Linus Torvalds. I believe the most recent kernels include an ext4 patch
that forces ordered writes by default as was the case with ext3 as a
result.
Applications generally shouldn't use fsync at all, except in very
specific circumstances. If the application implements its own
transactions (particularly across a network where one server might go
down and another might not), then it is appropriate to use fsync to
ensure transactions are synchronized. That comes with a significant
penalty to filesystem performance.
As an example of why fsync shouldn't be used, consider mythtv. By
default it fsyncs video recordings every couple of seconds. On a loaded
system with RAID that means that the disks are constantly seeking. On
my backend that resulted in video loss due to buffer overruns. When I
edited out the fsyncs from the source, the problem went away, as the
underlying device drivers could pool data in a sane way and not rewrite
the RAID5 stripes every time 1/10th of a stripe changed.
Filesystems should safely store files and avoid zeroing out modified
files any time they are written to normally. It shouldn't be up to
application developers to figure out the implementation-level details of
the filesystems they are running on.
Sure, it is best to not have a system crash at all. However, if it is
going to fail there are better ways of doing it than what the ext4 team
came up with. That is why Linus overrode them in the kernel.
_______________________________________________
paludis-user mailing list
[email protected]
http://lists.pioto.org/mailman/listinfo/paludis-user
