Richard Freeman wrote:
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.
Thanks for your answer Richard. I'm inclined to have the same opinion
about a filesystem zeroing files upon a system crash. But this is an
extreme and complex situation and there is still place for debate.
Outside of my system crash context, it came to my mind today that the
fact the VDB repository is not updated (almost) atomically could not be
only an issue in the context of a system crash.
Correct me if I'm wrong, but if _paludis_ crashes in the middle of a VDB
update, /var/db/pkg will be left in an inconsistent state.
Fortunately, being a paludis user from a long time, I happily admit that
a paludis crash is very rare. Actually the few paludis crashes that I
had in the past all came from a broken environment :-) But in the end,
it just happens.
Isn't it an issue ?
_______________________________________________
paludis-user mailing list
[email protected]
http://lists.pioto.org/mailman/listinfo/paludis-user
