> для всех.На CoW получить старое состояние файла в случае "не прокатило" в принципе можно и без такой порнографии. Но тут смотря что программы делали.
> как журналирование от этого поможет?
Если журналить данные - можно либо завершить ту запись, либо отбросить, смотря успело ли намерение попасть в журнал. А если только метаданные журналились - вот тут уже без шансов, потребных данных просто нет нигде. И будет файл с обломаной на середине записью, понятно насколько юзабельный.
> В лучшем случае оно позволит избежать последствий reordering, когда мы писали-писали, решили
> что дописали, и поставили себе пометку transaction finished.
Если в момент краха запись обрубилась на середине - без журналирования данных это вообще совсем невозможно сделать чем-то консистентным применительно к данным. А в cow что, просто проигнорил последние потуги - и вот вам ваш файл, хоть и старый, но по крайней мере, читаемый и понимаемый.
> Но головки стояли близко к журналу транзакций, и далеко от данных - поэтому система
> оптимизировала запись, первым записав что поближе, и тут ой, kernel panic.
Ну во первых, если мухлевать в журналировании - то какой с него потом толк?
Во вторых, случае CoW все будет несколько иначе. Там по сути достаточно отбросить то что не получилось, старое состояние не испорчено и будет просто немного более старое но корректное представление.
Ясен фиг это все с точностью до сисколов конкретными прогами, идиотничать можно всегда. Но вот видимо это самое и вынуждает СУБД делать себе логику журналирования самим, целиком, от и до. Их такой расклад явно не устроит же.
> journaled fs при этом не пометит запись состоявшейся уже на своем уровне
> - и при накате журнала запишет и данные, и метку заново, приведя все в консистентное состояние.
Есть только 1 нюанс: писать данные сперва в журнал, потом в основную область означает ДВЕ записи данных. Скорость записи получается никакой. Поэтому этим режимом в EXT4 редко пользуются. А любимый шапкин XFS так, вроде, до сих пор не умеет. Зато умеет нули к файлам дописывать, походу. И таки до сих пор кажись какие-то остатки этого есть, я такой файлик видел, он не протерт конечно, но хвост из лишних нулей веселый :D.
> Поэтому никто с journal=data и не хочет иметь дел.
Блин спасибо кэп. Собственно поэтому CoW и придумали.
> Вот журналирующая CoW или log-structured (что совсем не то же самое) fs - поможет.
Вероятно, есть бесконечное количество способов сделать одно и то же по общему смыслу.
> Но опять же такой потерей производительности именно для субд
> - что все наизобретали костылей и подпорок, чтобы этот CoW для
> них выключать или хотя бы свести к минимуму.
Потому что в результате получается нечто типа "двойного журналирования", логика тамошнего журнала на CoW неудобно кладется и фрагментами забивается все просто в хлам.
И вариантов в общем то два: либо попросить CoW отвалить и оставить файл "in place" (btrfs так умеет), либо отдать ФС журналирование (но где для этого стандартная семантика и сисколы?). Собственно оракл с самого начала и хотел in-place файлы в btrfs (nodatacow) для своих баз, чего ж еще.
> - в случае как минимум mysql(innodb)+zfs не работает, данные первращаются в
> тыкву. Причины никому неизвестны и разбираться - героев не нашлось.
Думаю что они не полностью корректно смогли изобразить файлухой журнал. Это не просто и подразумевает кучу допущений, при том что удобного и стандартного способа пока вроде бы и нету. Хоть я и не понимаю чему противоречит next-gen семантика под CoW, позволяющая явно запрашивать у ФС услуги журналирования в желаемом виде (впрочем, ниоткуда не следует что ФС это хорошо сделает для БД, СУБД может позволить себе больше специализации).
