On Thu, Nov 24, 2011 at 12:27:11PM -0700, Matthew Wilcox wrote:
>
> On the other hand, if there was a crash mid-write, they might also get a
> 36k write that actually hit media (right? Or do we guarantee that on
> reboot you see a multiple of 128k?)
Sure, but in the case the crash we expect things to be in a wonky
state. The problem is if people assume atomic writes to files in a
non-crash case, which has been a traditional Unix/Linux "feature".
It's guaranteed by the standards as much a "close() implies fsync()",
but once application programmers start coding to such assumptions,
they refuse to admit they were wrong, and blame the kernel
programmers.
> > Dunno. People do lots of weird and flakey things. I have a suspicion
> > that we'll be hearing back from them about this change.
>
> The problem is that we may not hear from them for 6 years ... or whenever
> they decide to move off RHEL 3.
Funny you mention RHEL 3. I once had to fly on site to a customer
because their application programs depended on the order of addresses
handed back from mmap(), and that changed between 2.4 and 2.6, and
hence between RHEL 3 and RHEL 4 to debug the problem --- which turned
out to be caused in a change of an undocumented problem in mmap(2)...
(Well, it didn't break per se, but it turned an algorithm hidden
inside their app that had been O(n) to O(n**2), and that caused it to
slow down to the point that it was stalling long enough to make other
programs time out. All the customer could tell us was "Og had
program. Program worked on RHEL 3. Broke on RHEL 4. Og need
support." :-)
Still, I'm not too worried about those folks. Those are the customers
who keep people who do advanced support at Red Hat and IBM employed. :-)
I'm worried about the problems that break thousands of users using
open source code --- and so long as we it only happens on SIGKILL, and
not on any other signal, it's _probably_ going to be ok.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
