>> kill -KILL не о чём не говорит? или таки пейсатель?
>   Ну извините. Я по Вашей простыне наискось пробежался. Свою, заметьте,
> не поленился отфильтровать.

я и говорю не читатель, потому что моя простыня не большая это раз, а два это то что необходимое вам в подтверждение вы нашли быстро, а из этих вы потому что инженер в первую очередь пошел-бы искать причины падения вполне-себе userspace-ного сервиса по сигналу KILL, что делается в Linux давольно просто. Вместо поиска проблем с nbd вы стали лечить и жаловаться на симптомы (lvm).

>>> У lvm видел на эту тему чью-то ученическую поделку, и только.
>> а вы из этих...
>   Из инженеров, собирающих заказанный продукт из имеющегося, ага.

инженер из говна конфету не лепит -- для этого есть другие люди.
>[оверквотинг удален]
> Оно развивается и вполне разумно задумано, но ruby в данном секторе лично
> мне доставляет.
>   Там ещё есть ссылка на реально ученическую работу blocksync.py -
> оно изначально КС по блокам считало через adler32 https://gist.github.com/rcoup/1338263/revisions.
> Теперь автор повзрослел и поправил на sha /а современный rsync до
> сих пор md4 считает afaik/.
>   Мда. Когда я обнаружил эту питонятину в одном довольно таки
> серьёзном проекте, получил неслабый заряд позитива. А отсмеявшись, воткнул на его
> место патченный rsync, который btw тоже не фонтан. Но уж что
> было...

мне эта тема неинтересна - я не вижу где подобные техники можно применить (особенно если это делается как в приведённых примерах), но для для того чтобы иметь возможность копировать изменённые блоки с lv давно есть dm-era https://github.com/jthornber/thin-provisioning-tools

в частности у разрабов всевозможных утилит архивирования данная техника может быть применена по алгоритму
1. получаем изменённые блоки
2. через lib2fs/debug2fs получаем имя файла/ов находящегося в данном блоке
3. проводим синхронизацию.