https://www.opennet.dev/openforum/vsluhforumID3/91397.html Представлен (https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups=#!topic/zfs-announce/DOAuSF7kjsU) релиз ZFSonLinux 0.6.2 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Реализованная в ZFSonLinux версия пула и файловой системы совместима с ZFS из состава Illumos и FreeBSD. Проект развивается под руководством Брайана Белендорфа (создатель http-сервера Apache) при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.<br><br><br>В рамках ZFSonLinux подготовлена стабильная и полнофункциональная реализация поддержки компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Laye https://www.opennet.dev/openforum/vsluhforumID3/91397.html#105 Wed, 11 Sep 2013 01:00:03 GMT &gt; Месье не в курсе как работает ZFS ? Месье ниасилятор ? Можно <br>&gt; даже сказать терминальный ниасилятор ... ;) <br><br>ну расскажите, не томите!<br><br>open =&gt; write =&gt; close (и никаких fsync/fdatasync).<br><br>и вот тут где-то пропадает питание. <br>чтобы вам было проще, представьте, что zfs у нас на lun'е по iscsi, а rtt 60мс. <br><br><br>&gt; ЗЫ Алекс вы сменили ник ? Пришла осень ?<br><br>вы обознались.<br> https://www.opennet.dev/openforum/vsluhforumID3/91397.html#104 Mon, 09 Sep 2013 22:29:06 GMT &gt; У изена с его 6Мб на шпиндель и ноутбучными дисками - чуть менее чем вечность, имхо :)<br><br>Засунь своё имхо подальше.<br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/91397.html#103 Mon, 09 Sep 2013 22:19:22 GMT &gt; приложение пишет на диск 4кб данных. если в этот момент дернуть питание, <br>&gt; то нет наких гарантий что после отката данные будут на <br>&gt; диске. чудес не бывает.<br><br>Месье не в курсе как работает ZFS ? Месье ниасилятор ? Можно даже сказать терминальный ниасилятор ... ;)<br><br>ЗЫ Алекс вы сменили ник ? Пришла осень ?<br> https://www.opennet.dev/openforum/vsluhforumID3/91397.html#102 Mon, 09 Sep 2013 17:37:38 GMT &gt; Так XFS тоже убьётся в хламину, если рубильник дёрнуть. А ты недёргай. <br><br>ради интереса сколько раз дергал - не убивалась.<br><br>&gt; ZFS не нуждается в fsck, так как при обычном использовании ZIL не <br>&gt; допускает неатомарных записей групп транзакций. То есть в случае аварийного завершения <br>&gt; работы при последующем монтировании ФС пула происходит автоматический откат группы транзакций <br>&gt; примерно на 5 секунд раньше неудавшейся записи. <br><br>это настраивается, если чо. и тут традиционный баланс между производительностью и сохранностью данных<br><br><br>&gt;Данные остаются в непротиворечивом <br>&gt; состоянии. <br><br>Изя, ну что такое "данные в непротиворечивом состоянии"?<br><br>приложение пишет на диск 4кб данных. если в этот момент дернуть питание, то нет наких гарантий что после отката данные будут на диске. чудес не бывает.<br><br>&gt; Если всё же обнаружено несоотвествие контрольных сумм, то в дело <br>&gt; вступает scrub, который производит "очистку" пула от неконсистентных данных и выводит <br>&gt; полный поимённый список безвозвратно повреждён https://www.opennet.dev/openforum/vsluhforumID3/91397.html#101 Mon, 09 Sep 2013 17:21:25 GMT &gt;&gt; Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно посмотреть?) <br><br>А посмотреть то чем можно? <br><br>&gt; http://www.linux.org.ru/forum/general/9560485?cid=9563032 <br><br>Изя, ты самостоятельно думать не умеешь и только копипастишь?<br><br>&gt; Если не менять свойство recordsize, задающее максимальный размер блока, то это будет <br>&gt; 128 килобайт. Файлы, размер которых не превышает максимальный размер блока, занимают <br>&gt; ровно столько секторов, сколько требуется для их сохранения. При их модификации <br>&gt; происходит выделение нового блока, так что файлы размером до максимального размера <br>&gt; блока всегда остаются непрерывными.<br><br>чудесно. что происходит со старым блоком, после того как данные "переехали" в новый?<br>hint: metaslab, space map.<br><br>вся техника борьбы с фрагментацией в zfs описывается вот тут:<br><br>[CODE]<br>When ZFS decides to allocate blocks from a particular metaslab, it first reads that metaslab's space map from disk and replays the allocations and frees into an in-memory AVL tree of free space, s https://www.opennet.dev/openforum/vsluhforumID3/91397.html#100 Mon, 09 Sep 2013 03:31:23 GMT &gt; Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно посмотреть?)<br><br>http://www.linux.org.ru/forum/general/9560485?cid=9563032<br><br>///---<br>В ZFS, если что, нет понятия &#171;фрагмент&#187;, есть понятие блок, который может быть разных размеров.<br><br>Если не менять свойство recordsize, задающее максимальный размер блока, то это будет 128 килобайт. Файлы, размер которых не превышает максимальный размер блока, занимают ровно столько секторов, сколько требуется для их сохранения. При их модификации происходит выделение нового блока, так что файлы размером до максимального размера блока всегда остаются непрерывными. Если файл перерастает максимальный размер блока, то его размер блока фиксируется, и все его блоки в дальнейшем занимают 128 килобайт каждый (при значении recordsize по умолчанию).<br><br>В ext4 4 размер блока равен странице, так что при фрагментации файла на блоки размером 4 килобайта эффект от фрагментации может оказаться гораздо печальнее, нежели от фрагментации на блоки размеров 128К.<br> https://www.opennet.dev/openforum/vsluhforumID3/91397.html#99 Sun, 01 Sep 2013 06:13:23 GMT &gt; Так XFS тоже убьётся в хламину, если рубильник дёрнуть. <br><br>Может. Но там хотя-бы утилиты для починки есть.<br><br>&gt; А ты недёргай. <br><br>А ты русский язык не прогуливай. Не с глаголами пишется раздельно.<br><br>&gt;&gt; и починить нечем будет - а где у нее fsck вообще?<br>&gt; ZFS не нуждается в fsck, так как при обычном использовании ZIL не <br>&gt; допускает неатомарных записей групп транзакций.<br><br>ZFS "не нуждается" в fsck, потому что сани решили что полный fsck для такой монстряки получается как-то слишком сложно, поэтому гораздо интереснее, проще и дешевле просто скормить лохам маркетингового булшита. По той же причине он "не нуждается" в дефрагере и что там еще. Как оно фрагментится - ты же нам и показал с 6М/сек на шпиндель. Как оно не нуждается в fsck - показал другой деятель на лисяре, устраивавший закат солнца вручную.<br><br>&gt; То есть в случае аварийного завершения работы при последующем монтировании ФС пула <br>&gt; происходит автоматический откат группы транзакций <br><br>Или не происходит, если вср@лась какая-то ошибка, например бэд с https://www.opennet.dev/openforum/vsluhforumID3/91397.html#98 Fri, 30 Aug 2013 10:49:48 GMT &gt;&gt; Отключи ZIL и checksum и будет ZFS такая же быстрая и "надёжная" <br>&gt;&gt; на запись, как XFS, а может даже быстрее и реактивнее.<br>&gt; Только потом убьется в хламину<br><br>Так XFS тоже убьётся в хламину, если рубильник дёрнуть. А ты недёргай.<br><br>&gt; и починить нечем будет - а где у нее fsck вообще?<br><br>ZFS не нуждается в fsck, так как при обычном использовании ZIL не допускает неатомарных записей групп транзакций. То есть в случае аварийного завершения работы при последующем монтировании ФС пула происходит автоматический откат группы транзакций примерно на 5 секунд раньше неудавшейся записи. Данные остаются в непротиворечивом состоянии. Если всё же обнаружено несоотвествие контрольных сумм, то в дело вступает scrub, который производит "очистку" пула от неконсистентных данных и выводит полный поимённый список безвозвратно повреждённых и потерянных (для пула) файлов. По этому списку файлы можно восстановить из бэкапа, если требуется. Классический fsck не предоставляет такой возможности, как scrub, и сваливает найденные "ос https://www.opennet.dev/openforum/vsluhforumID3/91397.html#97 Fri, 30 Aug 2013 04:29:07 GMT &gt; Отключи ZIL и checksum и будет ZFS такая же быстрая и "надёжная" <br>&gt; на запись, как XFS, а может даже быстрее и реактивнее.<br><br>Только потом убьется в хламину и починить нечем будет - а где у нее fsck вообще? Кроме того, CoW сам по себе в принципе достаточно быстрая техника которая может показывать во многих случаях скорость как у обычной ФС с журналом только метаданных, обеспечивая полное журналирование. Что собственно и является одним из аргументов "за" такой дизайн. А тут слив в полтора раза...<br>