https://www.opennet.ru/openforum/vsluhforumID3/91761.html Ряд сообществ, организаций и компаний, заинтересованных в развитии ZFS, скооперировались для совместного продолжения развития данной файловой системы и представили (http://www.open-zfs.org/wiki/Announcement) проект OpenZFS (http://open-zfs.org/). В состав проекта OpenZFS вошли заинтересованные в разработке ZFS сообщества Linux, FreeBSD, OS X,и illumos, к проекту также присоединился Мэт Аренс (Matt Ahrens), один из двух оригинальных авторов ZFS. OpenZFS позволит гарантировать дальнейшую эволюцию ZFS, сосредоточит разработку в рамках единого вектора развития и придаст разработке целиком кросс-платформенный характер, упрощающий использование ZFS в различных операционных системах.<br><br><br><br><br>Разработчики операционной системы FreeBSD, приветствовали (http://lists.freebsd.org/pipermail/freebsd-announce/2013-September/001500.html) образование OpenZFS и указали на то, что равное партнёрство разработчиков и пользователей FreeBSD, Illumos, Linux и OS X существенно поднимет уровень качества тестирования, документации, https://www.opennet.ru/openforum/vsluhforumID3/91761.html#452 Sat, 07 Dec 2013 14:39:15 GMT &gt;[оверквотинг удален]<br>&gt; пяток рейдов, настроить кластер с избыточностью информации, и потратить полмиллиона на <br>&gt; отдельную структуру для резервного копирования - пустяки. И я логично предполагаю, <br>&gt; что файловые системы для них пишутся с пониманием этого момента. Лучше <br>&gt; потратить человеко-часы на поддержку снепшотов, встроенных рейдов, менеджеров томов, <br>&gt; сжатия и т.д., чем то же время потратить на повышение надёжности. <br>&gt; Ибо все эти фишки нужны в сравнительных таблицах (типа у самолёта <br>&gt; есть реактивный двигатель, а у автомобиля - нет, значит покупаем самолёт), <br>&gt; а надёжность - дело десятое, и если у клиента и накроется <br>&gt; диск (что совсем не факт), то всегда можно переключиться на другой <br>&gt; комп кластера, который тоже содержит эту информацию.<br><br>dfdfdf<br> https://www.opennet.ru/openforum/vsluhforumID3/91761.html#451 Sun, 03 Nov 2013 15:30:01 GMT &gt; Нашлись с помощью чего? Мата и хексэдитора.<br><br>Из какой-то старинной резервной копии, всего лишь. Достать из древнего бэкапа пару файлов которые не меняли со времен царя Гороха - нормально вполне. Так удалось получить и текущее состояние и ничего не продолбать. С минимумом усилий человеков в плане войны с проблемой.<br><br>&gt; пулу и определить поимённо с точным путём, какие файлы повреждены. <br><br>В моем случае речь шла о максимальном вытаскивании с ФС данных. Дабы это обеспечить - сперва я прочел все что в принципе могло прочесться с этого носителя в образ, при том утилитка читает умно - сперва грубый проход по поверхности, с пропуском явно проблемных мест, а потом - добивание того что осталось до победного (или истечения лимита попыток, или окончательной смерти накопителя). Так даже если проблемный носитель умрет при долбежке - уже не очень обидно. Потому что делать что либо с нестабильным диском, который явно собирается помереть - себе дороже: пациент может умереть в руках доктора. Самое умное что можно сделать - https://www.opennet.ru/openforum/vsluhforumID3/91761.html#450 Sat, 02 Nov 2013 13:42:54 GMT &gt;&gt; - для /projects весьма удобна как раз ZFS с её снапшотами <br>&gt; ...и тормозами/фрагментацией/жрачем памяти и вообще дурно сделанным кэшом. Для именно <br>&gt; версионирования, именно исходников - система контроля версий с этим справляется лучше <br>&gt; и логичнее, а от ФС требуется не разваливаться и не особо <br>&gt; тупить с кучей мелочи. Обычный ext4 выше крыши.<br><br>EXT4 без журнала и барьеров для /projects ? Вы любите восстанавливаться из бакапов ? Или всетаки с журналом и тормозит на мелочи хуже btrfs ?<br> https://www.opennet.ru/openforum/vsluhforumID3/91761.html#449 Sat, 02 Nov 2013 13:35:05 GMT &gt; XFS "летает" лишь по-джедайски собранный и примонтированный(начиная с noatime) <br>&gt; но все это требует, как и в случае с EXT4 - UPS <br>&gt; на каждой машине со всем этим.<br>&gt; аналогично с btrfs, но обьем катастрофы будет чуть меньше ~ <br><br>EXT4 летает по камикадзовски, без журнала и барьеров и как показывает опыт работы с хецнером упс не поможет ...<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/91761.html#448 Sat, 02 Nov 2013 13:33:50 GMT &gt; В том-то и прелесть Linux, что можно выбрать подходящий инструмент под задачу. <br>&gt; К примеру: <br>&gt; - для загрузочных отделов вполне достаточно ext2, <br>&gt; - для мультимедиа - XFS, как, наверное, самый проверенный проект для работы <br>&gt; с мультимедиа <br>&gt; - для /tmp - tmpfs, ибо "пуля" <br>&gt; - для /projects весьма удобна как раз ZFS с её снапшотами <br>&gt; Можно, конечно, использовать для всего XFS, или, скажем, ReiserFS, или EXT4, но <br>&gt; смысл тогда теряется.<br>&gt; Осваивайте матчасть и не ищите панацеи и обрящете дао. ;) <br><br>И охота так заморачиваться ?<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/91761.html#447 Sat, 02 Nov 2013 13:15:43 GMT ---<br><br><br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/91761.html#446 Sat, 02 Nov 2013 13:13:23 GMT &gt;[оверквотинг удален]<br>&gt; Нашлись с помощью чего? Мата и хексэдитора.<br>&gt;&gt; Некая разница с тем на что кекс на лисяре нарвался, знаешь ли.<br>&gt; В то время ещё не существовало теперь уже штатной команды "zpool import <br>&gt; -F poolname", после которой можно пройтись scrub'ом по убитому в хлам <br>&gt; пулу и определить поимённо с точным путём, какие файлы повреждены. И <br>&gt; счёт может вестись не на пару файлов, а на сотню, если <br>&gt; так "повезло". И такой пул будет ещё жить очень долго, если <br>&gt; к сбойному носителю просто приаттачить зеркалом второй исправный носитель. А твоя <br>&gt; классическая файлуха такой конфигурации не выдержит в принципе даже на LVM <br>&gt; &#8212; с ума сойдёт от бэдов. ;) <br><br>LVM может сойти с ума если на диске с сим будет образ виртуалки тоже случайно размеченный с LVM ... <br><br> <br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/91761.html#445 Sat, 02 Nov 2013 13:05:59 GMT &gt; Мне как-то fsck успешно починил том с битой ФС где 10 секторов <br>&gt; ушло в бэды. После чего ФС стала моунтабельной и юзабельной. А <br>&gt; пару файлов которым не повезло - так и быть нашли по <br>&gt; сусекам отдельно.<br><br>Нашлись с помощью чего? Мата и хексэдитора.<br><br>&gt; Некая разница с тем на что кекс на лисяре нарвался, знаешь ли.<br><br>В то время ещё не существовало теперь уже штатной команды "zpool import -F poolname", после которой можно пройтись scrub'ом по убитому в хлам пулу и определить поимённо с точным путём, какие файлы повреждены. И счёт может вестись не на пару файлов, а на сотню, если так "повезло". И такой пул будет ещё жить очень долго, если к сбойному носителю просто приаттачить зеркалом второй исправный носитель. А твоя классическая файлуха такой конфигурации не выдержит в принципе даже на LVM &#8212; с ума сойдёт от бэдов. ;)<br><br>Вот ещё фейл с внешним винтом под Ext4 с шифрованием: http://www.linux.org.ru/forum/admin/9765462<br><br> https://www.opennet.ru/openforum/vsluhforumID3/91761.html#444 Sat, 02 Nov 2013 13:01:58 GMT &gt;&gt; Ext4 c журналом и барьерами по быстродействию проё ... простите уступает даже btrfs ...<br>&gt; А это как раз нормально. "Классика" с полным честным журналированием данных+метаданных <br>&gt; делает двойную работу. Поэтому собственно CoW-based и изобрели.<br><br>И после всего этого вы еще сравниваете эту тормозину с ZFS ?<br><br>&gt;&gt; ... и педалит по кладбищу на белой простыне.<br>&gt; Вы что, заранее отмечали Хэллоуин и перебрали?<br><br>Две недели думали что ответить ? :)) Вы случайно не с эстонии пишите ? <br><br>&gt;&gt; в голову вместе с горшком.<br>&gt; Честно говоря мне кажется что у вас вместо головы этот горшок оказался <br>&gt; в результате.<br><br>И часто вам кажется ? Не не так :)), а после чего вам стало казаться ? <br><br><br>