]> Sergey Matveev's repositories - stargrave-blog.git/commit
Что не так с Copy-on-Write под Linux при копировании
authorSergey Matveev <stargrave@stargrave.org>
Sun, 3 Nov 2019 16:04:37 +0000 (19:04 +0300)
committerSergey Matveev <stargrave@stargrave.org>
Sun, 3 Nov 2019 16:04:37 +0000 (19:04 +0300)
commit0c5ff5a79b5b849dcdb029139a34283a20d9e350
tree4b825dc642cb6eb9a060e54bf8d69288fbee4904
parente4d6b84fca026b7f968ab6f60df93a65dc86ed16
Что не так с Copy-on-Write под Linux при копировании

https://habr.com/ru/post/473752/
Вся статья просто о том, что некоторые ФС позволяют не делать настоящее
копирование файлов, а просто создать ссылку, типа hardlink-а. Фича то
хороша, спору нет, но я категорически не согласен с автором что CoW ФСы
создавались как-раз для того чтобы эту фичу и использовать. Его ожидания
подорваны и поэтому он считает что что-то не так. Лично я категорически
не согласен с тем чтобы моя команда копирования не копировала данные
по-настоящему. В ZFS-е как минимум это хак для дефрагментации файла. На
любой ФС это, как минимум, создание избыточной копии файла, что может
быть полезно если диск начнёт сыпаться, без дубляжа всей ФС (RAID или
copies опция ZFS dataset). cp это копирование, точка. Копирование
reflink-а это копирование reflink-а.

Да и напрягает написанное у автора что:

    После этого я не торопился использовать Cow-системы, так как сама
    парадигма Copy-on-Write предполагает повышенную фрагментацию, потому
    что изменения данных каждый раз записываются в новое место.

    Для HDD фрагментация убивает производительность, так как процесс
    перепозиционирования блока считывающих головок — очень длительная
    операция.

    Поэтому лично я откладывал внедрение btrfs на своих машинах, пока
    они не перешли на SSD.

Он полностью прав что CoW это повышенная фрагментация. Прав что
фрагментация повышает IOPS, а жёсткие диски их не любят. Но только он
совершенно не учитывает кэширование, которое по сути может полностью
сгладить и нивелировать эти IOPS.