Cc: Bodo Eggert <7eggert@...>, Diego Calleja <diegocg@...>, Jan Kara <jack@...>, Jiri Kosina <jkosina@...>, <linux-fsdevel@...>, Linux Kernel list <linux-kernel@...>, Michal Hocko <mhocko@...>, Meelis Roos <mroos@...>, Pavel Machek <pavel@...>
> Well it would take seriously hard work to make a program that would work
I can easily imagine such a program. I think you aren't exercising enough
imagination about the kinds of requirements a program might be
implementing.
That lack of imagination (in all of us) is the reason we shouldn't
tolerate something working not as designed or not as expected just because
we went through every possible use scenario and it didn't matter in any of
them. Just focus on the layer in question.
The easiest way to imagine a program not doing locking and being useful
anyway (as long as the kernel is thread-safe) is to use the same arguments
you use for the kernel doing it: there's a higher level user responsible
for locking. The code in question doesn't guarantee that user writes all
its stuff to the right place, but at least it guarantees that that user's
lack of locking doesn't screw some other user of the file. It does that
by ensuring it never seeks to a place the user doesn't own and that no two
separate users ever access the file at the same time.
I'd even like to accomodate the poor user trying to debug the broken
locking in his application. He sees the file getting corrupted and
immediately thinks, "what if my thread serialization isn't working right?"
But he notices that the corruption isn't consistent with that hypothesis.
He knows he was working with only the beginning and the end of the file
and the corruption happened in the middle. So he wastes a week
considering other hypotheses, including a kernel bug, until someone points
out a paragraph in the lseek() man page that says contrary to all Unix
convention, that particular function and system call is not thread-safe,
and it doesn't necessarily seek to the place mentioned in its argument.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
--
