и ни на какой журнал zfs не полагается. Или пруфы плиз

и ни на какой журнал zfs не полагается. Или пруфы плиз

Это так ужасно: нельзя уменьшить раздел. Как я живу без этого =))

а лог девайсы это что повашему?

это не то же, что журнал ext

Ну толку от журнала, если старые данные уже переписаны поверх? как спасёт журнал?

Нет, стоп, Вы говорите "журнал ZFS не полагается" Вы не сказали *ZFS не журналируемая файловая система* (что корректно, ибо она транзакционная, но все транзакции точно также хранятся в *журнале*)

что за гопстоп тут? =) Я сказал, что сказал: zfs не полагается на журнал, т.к она cow

В случае когда она ломается - полагается, чтобы откатить транзакции

что за гопстоп тут? =) Я сказал, что сказал: zfs не полагается на журнал, т.к она cow

полагается. в журнал идут синкованные записи между флашами дерева. при креше журнал применится к последней версии дерева.

где журнал в zfs?

нет, это не журнал

нет, это не журнал

Нууу, давайте посмотрим на его расширофку

P.S. С одной стороны, человек пытается привести нас к TXG (которые являются группой транзакций), но забывает, что TXG это тот же лог\журнал операций, (просто в профиль), а CoW позволяет проигрывать журнал не только вперёд, но и назад

SLOG - synchronous log (journal)

Что на самом деле несёт Alex - я хрен его знаю

А, ну Владислав как обычно всё знает за всех наперед. Чтож, ему и отвечать =)

Хер свой убери, плиз =)

)))) Только если Вы согласны с тем, что журнал в ZFS есть)

Хрен не уберу

Почему тогда не SLOJ ?

Нет, это не так. имхо

То есть в итоге Вы просто считаете что правильно по Вашему без опоры на... что-либо?

Что по Вашему пишется в SLOG?

что за гопстоп тут? =) Я сказал, что сказал: zfs не полагается на журнал, т.к она cow

журнал в ехт4 тоже intent log такто

* journal mode data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all others modes. Enabling this mode will disable delayed allocation and O_DIRECT support.

Ну самое банальное, 1) A physical journal logs an advance copy of every block that will later be written to the main file system. Physical journals impose a significant performance penalty because every changed block must be committed twice to storage. 2) A logical journal stores only changes to file metadata in the journal, and trades fault tolerance for substantially better write performance. May allow unjournaled file data and journaled metadata to fall out of sync with each other 3) CoW FS avoid in-place changes to file data by writing out the data in newly allocated blocks, followed by updated metadata that would point to the new data and disown the old, followed by metadata pointing to that, and so on up to the superblock, or the root of the file system hierarchy. This has the same correctness-preserving properties as a journal, without the write-twice overhead.

это откуда?

physical journal logs - я не знаю что это за physical. Это как ?

Не, я всё же вовсе не уверен, что ext с journal=data будет равносильно cow по fault tolerance . В случае, когда идет перезапись файла, ext4 будет перезаписывать. И если уже произойдет перезапись данных, то никакой журнал не поможет. А старых данных у нее нет, иначе она была бы полноценной cow, а это не так

Не, я всё же вовсе не уверен, что ext с journal=data будет равносильно cow по fault tolerance . В случае, когда идет перезапись файла, ext4 будет перезаписывать. И если уже произойдет перезапись данных, то никакой журнал не поможет. А старых данных у нее нет, иначе она была бы полноценной cow, а это не так

Эх надо дальше ехать. Есть что сказать вам про нагрузку. Но сейчас не успею. Мржет быть даже имеет смысл вечерком голосом.

я же привел пример когда и cow может пролюбить старые данные *приложения*

? У Вас есть данные, которые надо записать и мета к ним на диске 1 Пока она не окажется целиком на диске 2 - данные с диска 1 никуда не денутся. Если у нас фейл по питанию - диск 2 продолжит восстанавливать данные с диска 1 CoW использует схожий принцип, просто данные не пишутся дважды, у Вас просто меняется указатель (Деление на диски условное, это может быть один диск, просто с двумя нагляднее)

Диск 2 принял данные, точно их записал себе. Потом они качуют на диск 1 в то место, где лежит изменяемый файл. Случился фейл по питанию, данные не записались до конца, данные с диска 2 снова запишутся на диск 1 после включения?

Диск 2 принял данные, точно их записал себе. Потом они качуют на диск 1 в то место, где лежит изменяемый файл. Случился фейл по питанию, данные не записались до конца, данные с диска 2 снова запишутся на диск 1 после включения?

А каким образом у Вас данные качуют между дисков-журналом (диск 1) и диском-файловая система (диск 2) в обратную сторону?

Так вопрос к Вам, т.к. с вашего описания я понял, что диск с журналом это диск 2, а с данными - первый

? У Вас есть данные, которые надо записать и мета к ним на диске 1 Пока она не окажется целиком на диске 2 - данные с диска 1 никуда не денутся. Если у нас фейл по питанию - диск 2 продолжит восстанавливать данные с диска 1 CoW использует схожий принцип, просто данные не пишутся дважды, у Вас просто меняется указатель (Деление на диски условное, это может быть один диск, просто с двумя нагляднее)

Тогда вопрос. Что будет с данными, если Диск 1 на самом деле не записал их на себя, а придержал в буфере, но при этом ФС уже начала переписывать данные на диске 2?

Ничего? Система просто не увидит ничего и ФС и приложения на диске 2 будет цела, просто на моменте *до пропажи питания*

? У Вас есть данные, которые надо записать и мета к ним на диске 1 Пока она не окажется целиком на диске 2 - данные с диска 1 никуда не денутся. Если у нас фейл по питанию - диск 2 продолжит восстанавливать данные с диска 1 CoW использует схожий принцип, просто данные не пишутся дважды, у Вас просто меняется указатель (Деление на диски условное, это может быть один диск, просто с двумя нагляднее)

Еще раз: перезапись. Данные перезаписались, а журнал не обновился => потеря старых данных

Если бы ext не перезаписывала данные, она была бы cow.

Там не совсем CoW как таковой, но штраф на запись дважды есть

Вы не поняли. 1) Данные просятся в ФС 2) ФС попутно создает мету и отправляет с данными на диск 1 (журнал). Диск берет их себе, кладёт в буфер у себя (ОЗУ), но сообщает, что записал на ПЗУ. 3) ФС считает, что всё ок, начинает писать данные на диск 2, но не успевает закончить, т.к. пропало питание. 4) Питание появилось, ФС запустилась. Смотрит, мета есть, а данные не сходятся ни в журнале, ни на диске 2. 5) Упс

Или данные положил, или мету. А может ни то, ни другое. Кто знает их логику, кроме разработчиков? А т.к. это не PLP, как у Вас evo 860, то никто ничего гарантировать не должен

И да, там был фикс на эту тему для SMR дисков, что бы мета и данные оказывались на самом диске, а не в буфере диска

Т.е. Вы согласны, что такие случаи бывали, а значит могут быть и в будущем?