https://www.opennet.me/openforum/vsluhforumID3/60649.html "No, ZFS really doesn't need a fsck (http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html)" - один из инженеров Sun Microsystems опубликовал в своем логе подробную заметку с рассказом посему в ZFS отсутствует потребность в утилите fsck для проверки целостности файловой системы.<br><br>URL: http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=24150<br> https://www.opennet.me/openforum/vsluhforumID3/60649.html#54 Thu, 12 Nov 2009 21:00:13 GMT Спустя 26 минут от начала проверки:<br>% zpool status amd64rio<br> pool: amd64rio<br> state: ONLINE<br> scrub: scrub in progress for 0h26m, 12,41% done, 3h6m to go<br>config:<br><br>NAME STATE READ WRITE CKSUM<br>amd64rio ONLINE 0 0 0<br> mirror ONLINE 0 0 0<br> gpt/rio_zfs2 ONLINE 0 0 0<br> gpt/rio_zfs1 ONLINE 0 0 0<br><br>errors: No known data errors<br><br>Курсор в Xfce ни разу не замер, что удивительно. Однако отклик GUI происходит "урывками" &#8212; то замирает на 5 секунд, то потом отмирает и быстро воспроизводятся проделанные действия &#8212; добирается слово, набранное с клавиатуры, открывается меню при выборе пункта меню мышкой и т.д. Как-будто киноплёнка притормаживается на секунды, а потом быстро прокручивается до нормального состояния.<br>Работать можно, но неприятно.<br> https://www.opennet.me/openforum/vsluhforumID3/60649.html#53 Thu, 12 Nov 2009 20:34:32 GMT &gt;&gt;кто это имел при неудачных обесточиваниях компа с FreeBSD 6.1...8.0-RC2. <br>&gt;&gt;И fsck (на UFS2), и scrub (на ZFS) &#8212; обе начинают проверку <br>&gt;&gt;ФС в ФОНЕ, но при работе scrub, в отличие от fsck, <br>&gt;&gt;пользоваться компьютером просто не хочется из-за невыносимых тормозов. <br>&gt;<br>&gt;Бред, никогда scrub в фоне при загрузке компа (как это есть с <br>&gt;fsck) не запускается.<br><br>Что касается scrub, то да, действительно он сам не начинает проверку после внезапного рестарта компа &#8212; только что нажал на Reset на работающей FreeBSD 8.0-PRERELEASE с zpool в корневике:<br>% uname -a<br>FreeBSD rio.fire 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Thu Nov 12 19:40:03 VOLT 2009 root@rio.fire:/usr/obj/usr/src/sys/RIO amd64<br>% zpool status<br><br> pool: Arena<br> state: ONLINE<br> scrub: none requested<br>config:<br><br>NAME STATE READ WRITE CKSUM<br>Arena ONLINE 0 0 0<br> gptid/e0fa02b3-81a6-11de-8aa6-02508d92a2eb ONLINE 0 0 0<br> https://www.opennet.me/openforum/vsluhforumID3/60649.html#52 Wed, 11 Nov 2009 22:54:11 GMT &gt;&gt;Есть мнение, что стоит прислушаться к словам предыдущего оратора и пойти-таки подтянуть <br>&gt;&gt;матчасть. <br>&gt;<br>&gt;Простите пожалста, про дефолтового 2-байтного флетчера я прочел в каком-то из описальников <br>&gt;ZFS, так что если вы посылаете - так посылайте более конкретно. <br>&gt;Хотя-бы для того чтобы я наткнулся на правильное описалово. Или уточняйте <br>&gt;что вы хотели сказать. А то как-то очень троллеобразно выглядит. <br><br>А ваше заявление, основанное на данных Радио ОБС, не троллеобразно выглядит? Конкретно - смотреть первоисточник здесь:<br><br>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/zfs/zfs_fletcher.c<br><br><br><br><br> https://www.opennet.me/openforum/vsluhforumID3/60649.html#51 Wed, 11 Nov 2009 22:48:03 GMT &gt; Все бы ничего, только они так и не ответили на вопрос: а что делать если так сложилась ситуация что данные и метаданные неконсистентны. Собссно все журналирующие ФС не нуждаются в fsck если гарантирована консистентность метаданных. И накукуй же они с fsck тогда поставляются? :)<br><br>Этот вопрос адресуйте авторам этих других файловых систем.<br><br>&gt; Просто разных гадостей которые могут случиться - навалом. И как бы ФС совсем не в минус если есть утиль способный собрать что-то хоть немного моунтабельное из той лапши которая есть. Потому что дискэдитором то колупать - как-то сильно более уныло и медленно, ага?<br><br>Дискэдитором колупать ничего не надо. Хотите примеров - почитайте zfs-discuss, масса примеров восстановления в самых разных ситуациях - от пула без репликации на сбойнувшем рэйд-контроллере, до RAID-Z с несколькими отказавшими дисками.<br><br>&gt; Почему же, я этого не утверждал. Они, разумеется, существуют. Но у них есть довольно злые fsck которые достаточно упорно пытаются хоть что-нибудь отколупать. И даже полов https://www.opennet.me/openforum/vsluhforumID3/60649.html#50 Wed, 11 Nov 2009 20:01:32 GMT &gt;Мне все нравится, кроме одного: тепличные допущения "а подыграем ка мы себе, <br>&gt;выбрав удобные правила игры и допустив что метаданные всегда валидны, забив <br>&gt;на неудобный случай когда это не так" - сосут. В идеальном <br>&gt;мире - да, оно катит. В реальном - на диске может <br>&gt;быть что угодно, т.к. железо - сбоит, софт - с багами, <br>&gt;так что пиндеж саночников неубедителен. <br><br>Когда вы ресет делаете на ext3 - данные негарантированно валидны, нада fsck. когда на zfs - гарантированно валидны. ВСЕ, ВОТ ВСЕ ОТЛИЧИЕ. ВОТ ЧТО ИМЕЮТ ВВИДУ маркетологи от сан. Ни о какой валидности не идет речи при повреждении блоков, никто нигде об этом не говорит. Откуда ввоще вы эту чуш взяли? Есть возможность востановить при наличии резерва. Резерва нет - только обнаружить. <br><br>&gt;Почему же, я этого не утверждал. Они, разумеется, существуют. Но у них <br>&gt;есть довольно злые fsck которые достаточно упорно пытаются хоть что-нибудь отколупать. <br>&gt;И даже половина данных но в моунтабельной ФС лучше чем слом <br>&gt;мозга в дискэдиторе (таким макаро https://www.opennet.me/openforum/vsluhforumID3/60649.html#49 Wed, 11 Nov 2009 19:37:28 GMT &gt;Мне не понравилось вот что: саночники очень упирают на природу CoW и <br>&gt;на то что консистентность - есть. Не утруждаясь объяснениями того а <br>&gt;что будет если консистентности вдруг нет. Это выглядит сочинением маркетологов на <br><br>Как же до вас туго доходит:<br>Консистентность - подразумевается, что при работе на исправном железе, ФС постоянно находится в консистентном состоянии и БАСТА. ОНА ВСЕГДА КОНСИСТЕНТНА. НЕТ ТАКОГО ПОНЯТИЯ ВООБЩЕ - НЕКОНСИСТЕНТНАЯ ФС - ДЛЯ ДАННОГО СЛУЧАЯ. <br>Если проблемы с железом/бб - это уже другой случай. Никак не относится к понятию консистентности. Это повреждение ФС, и при возможности идет востановление данных (если есть резервные копии). если их нет - ДА, ДА, И ЕЩЕ РАЗ ДА. ЭТО ХАНА, ТОРБА, если хотите ЖОПА, если у вас нет бекапа. Так вас устраивает? И вообще чем вы думаете? Если блок испорчен и нет резервной копии, то никакая ФС, даже богом написанная вам не поможет. Если вам руку отрезать - fsck поможет?<br> https://www.opennet.me/openforum/vsluhforumID3/60649.html#48 Wed, 11 Nov 2009 19:22:08 GMT &gt;перефразирую - т.е. если "отрекаверить" не получится, то "zpool scrub" очень тактично <br>&gt;намекнёт, что восстановить не получилось.... <br>&gt;не то что эта фсчк с мерзкими криками.... просто ни каких сравнений. <br>&gt;<br><br>да, неполучится, неполучится. Как вы собираетесь востановить то, на что нет резервных копий. Но мы покрайней мере знаем что есть проблема. При этом он напишет какой именно файл задевает этот блок и там вы уже себе решаете что делать. Хоть бекап хоть еще как. fsck может даже не ругнуться, тогда как zfs всегда обнаружит сбой, а если есть хоть одна копия, то востанавливает ошибку. <br> https://www.opennet.me/openforum/vsluhforumID3/60649.html#47 Wed, 11 Nov 2009 19:13:06 GMT &gt;кто это имел при неудачных обесточиваниях компа с FreeBSD 6.1...8.0-RC2. <br>&gt;И fsck (на UFS2), и scrub (на ZFS) &#8212; обе начинают проверку <br>&gt;ФС в ФОНЕ, но при работе scrub, в отличие от fsck, <br>&gt;пользоваться компьютером просто не хочется из-за невыносимых тормозов. <br><br>Бред, никогда scrub в фоне при загрузке компа (как это есть с fsck) не запускается.<br> https://www.opennet.me/openforum/vsluhforumID3/60649.html#46 Wed, 11 Nov 2009 12:05:38 GMT &gt;Пусть они скажут, а что будет если она не обеспечилась. Причин которые <br>&gt;к этому приведут я могу придумать вагон. А вот что саночники <br>&gt;предложат тогда делать?<br><br>zpool scrub &lt;poolname&gt;, невежа.<br>