Сразу видно истинного прохфисионала - такие безупречные рассуждения ;-)

Реализовать на уровне блочного устройства это можно и очень даже реально (погляди что такое DLM - хотя бы статью о VAX DLM на wiki) - но работать это будет ооочень медленно и практически не будет маштабироваться - так как локи прийдется брать на уровне блоков, с другой стороны исходники будут простыми.
Вас же не удивляет что RedHat cluster живет как-то себе? Хотя там обычная ext[2-3-4] + lock manager на уровне блоков.
Вас же не удивляет что несколько клиентов в Panasas или GFS или Lustre - могут разделять одну storage node?
и даже писать в одну inode с разных нод в разные диапазоны (кивок в сторону похмел-фс - которая не позволяет писать в один файл с разных нод - что делает ее ненужной для MPI приложений).

весь сторадж можно представить одной инодой, extent lock's и его range - как набор блоков которые будут модифицироваться в операции, так как это блочное устройство - то кэша на него не будет по определению.
Кроме того стоит вспомнить первую реализацию журналирования блочных устройств в FreeBSD - когда через хуки в GEOM велось журналирование всех изменений (аналоги journal=data в linux).
Реализация данного механизма требует вызова функций модуля журналирования по началу IO операции с диском (FS) и по концу - ну и callback который будет вызываться когда данные попадут на persistent storage.
Ровно эти же операции нужны для реализации блокировок (начало любого IO - взятие EX лока на диапазон, конец IO релиз лока), при возникновении конфликта локов - самое простое - это вызов аналога fsync() / не помню фревый VM - возможно там можно как-то узнать какой vnode принадлежат определенные блоки диска - и сбросить на диск только этот диапазон / что бы обеспечить что все данные упадут на storage и другая нода прочитает валидные данные.

Достаточно осветил вопрос - или еще пояснения нужны ?