The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Почему в ZFS нет необходимости в утилите fsck"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от opennews (ok) on 07-Ноя-09, 10:27 
"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 для проверки целостности файловой системы.

URL: http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=24150

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от pavlinux (ok) on 07-Ноя-09, 10:27 
Потому что ZFS создали Боги, и в ней нет ошибок и багов, а данные, с вероятностью 1, нельзя потерять.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от Andrew Kolchoogin on 07-Ноя-09, 11:30 
От потери данных, связанной с ошибками в реализации файловой системы, fsck не спасёт. Кроме того, так как fsck -- сам по себе программный продукт, а "last bug in our programs won't be corrected until last user is dead", _само по себе наличие_ этой утилиты отрицательно сказывается на надёжности хранения данных.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

12. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от pavlinux (ok) on 07-Ноя-09, 14:10 
>От потери данных, связанной с ошибками в реализации файловой системы, fsck не
>спасёт. Кроме того, так как fsck -- сам по себе программный
>продукт, а "last bug in our programs won't be corrected until
>last user is dead", _само по себе наличие_ этой утилиты отрицательно
>сказывается на надёжности хранения данных.

  За 40 лет в UNIX сформировалось понятие об утилите fsck, - хрень
проверяющая целостность файловой системы.
  То есть, нет, да и не может существовать, единого алгоритма проверки,
даже не алгоритма, а структуры самих метаданных. Так как способ их представления,
в каждой ФС, разные.
  Из этого скромного вывода, можно сделать дугой - любой способ проверки ФС, по
определению можно назвать частью или целым fsck. И из этого же следует,
что этот кусок алгоритма, так же, может являться частью самой FS.
  Так что, нужна ли fsck снаружи или внутри, это уже решают сами архитекторы ФС.

Собственно, для ISO9660/UDF, Squashfs, UBIFS, CIFS, и т.п., она тоже не нужна :)

    

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

14. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от Andrew Kolchoogin on 07-Ноя-09, 15:47 
> Из этого скромного вывода, можно сделать дугой - любой способ проверки ФС,
> по определению можно назвать частью или целым fsck.

Совершенно верно!

Так вот, в ZFS нет fsck ни внутри, ни снаружи. :) Вот так вот хитро она устроена: state файловой системы на диске consistent ВСЕГДА. В ЛЮБОЙ МОМЕНТ ОСТАНОВКИ РАБОТЫ ZFS. Это фича. :)

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от vitek (??) on 07-Ноя-09, 20:40 
самое время вспомнить о бэд-блоках...
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

21. "Почему в ZFS нет необходимости в утилите fsck"  +1 +/
Сообщение от аноним on 07-Ноя-09, 22:14 
самое время уже пойти, наконец, и почитать.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

23. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от vitek (??) on 08-Ноя-09, 01:09 
и что пишут?
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

24. "Почему в ZFS нет необходимости в утилите fsck"  +3 +/
Сообщение от аноним on 08-Ноя-09, 02:04 
пишут, что бэд-блоки в ZFS не нужны!
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Почему в ZFS нет необходимости в утилите fsck"  –3 +/
Сообщение от User294 (ok) on 08-Ноя-09, 07:05 
>ВСЕГДА. В ЛЮБОЙ МОМЕНТ ОСТАНОВКИ РАБОТЫ ZFS. Это фича. :)

А если грамотно бэд-секторов подкинуть в неудачных местах (чего накопители делать любят) - фича пойдет лесом с интересом. И чего тогда делать? Парни из сана технично скипают этот момент. Много бухтя про то какое нехорошее железо, но ничего не говоря о том что делать если их допущение на котором все зиждется (что состояние ФС всегда консистентно) вдруг оказалось неверным (мало ли, левая прямая запись на диск, сбой диска, сбоящий проц или память, или хрен там знает чего еще...).

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

32. "Почему в ZFS нет необходимости в утилите fsck"  +3 +/
Сообщение от аноним on 08-Ноя-09, 21:59 
> А если грамотно бэд-секторов подкинуть в неудачных местах (чего накопители делать любят)
> - фича пойдет лесом с интересом. И чего тогда делать? Парни из сана технично скипают этот
> момент. Много бухтя про то какое нехорошее железо, но ничего не говоря о том что делать
> если их допущение на котором все зиждется (что состояние ФС всегда консистентно) вдруг
> оказалось неверным (мало ли, левая прямая запись на диск, сбой диска, сбоящий проц или
> память, или хрен там знает чего еще...)

Вы в очередной раз выглядите идиотом, не зная матчасть. Что бы там не сбойнуло, чексуммы это отловят и исправят, поэтому да - состояние всегда консистентное, если диски/контроллер не врут о завершении sync. Если врут, создать FS с какими-то гарантиями невозможно в принципе.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

35. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от User294 (ok) on 09-Ноя-09, 01:33 
>Вы в очередной раз выглядите идиотом, не зная матчасть. Что бы там
>не сбойнуло, чексуммы это отловят

Это не вы там предлагали /dev/random на диск выгрузить? Если что сами посчитайте через сколько вам 2-байтный флетчер скажет что все зашибись хотя по факту это будет рандом. Как бы для 2-байтной чексумы - вероятнось неотлова далеко не ноль. А считать sha1 как бы накладно. Такая вот подлянка с чексумами, при том - она не только в zfs, а "вообще". Вы или попадаете что иногда простой чексумм лажается и невалидные данные могут быть приняты за валидные, или вынуждены использовать крутые (и сравнительно тормозные...) штуки типа sha с приличной разрядностью и низкой вероятностью коллизий.

>и исправят,

А это откуда следует? И главное - кто и на основе какого алгоритма произведет исправление? Где это описано?

>поэтому да - состояние всегда консистентное, если диски/контроллер
>не врут о завершении sync. Если врут, создать FS с какими-то гарантиями
>невозможно в принципе.

Всем похрену на ваши теоретизирования, когда дело доходит до практики. А на практике - если том рассыпался, нужен утиль который сможет его реанимировать до более-менее монтируемого и доступного состояния. Пусть частично потеряв какие-то данные, это всяко лучше чем выколупывать их исключительно дискэдитором с совсем не цепляющегося тома. Чем лучше такой утиль и чем он больше упирается до последнего в потугах хоть что-то на томе отколупать - тем лучше ФС с точки зрения админов и юзеров. И саночники пардон мягко говоря - неубедительны. Менее мягко говоря - я озвучил как этот подход называется, имхо.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

37. "Почему в ZFS нет необходимости в утилите fsck"  +2 +/
Сообщение от Anon Y Mous on 09-Ноя-09, 12:30 
>>Вы в очередной раз выглядите идиотом, не зная матчасть. Что бы там
>>не сбойнуло, чексуммы это отловят
>
>Это не вы там предлагали /dev/random на диск выгрузить? Если что сами
>посчитайте через сколько вам 2-байтный флетчер

Есть мнение, что стоит прислушаться к словам предыдущего оратора и пойти-таки подтянуть матчасть.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

39. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от User294 (ok) on 10-Ноя-09, 01:25 
>Есть мнение, что стоит прислушаться к словам предыдущего оратора и пойти-таки подтянуть
>матчасть.

Простите пожалста, про дефолтового 2-байтного флетчера я прочел в каком-то из описальников ZFS, так что если вы посылаете - так посылайте более конкретно. Хотя-бы для того чтобы я наткнулся на правильное описалово. Или уточняйте что вы хотели сказать. А то как-то очень троллеобразно выглядит.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

43. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от QuAzI (ok) on 10-Ноя-09, 23:43 
The blocks of a ZFS storage pool form a Merkle tree in which each block validates all of its children. Merkle trees have been proven to provide cryptographically-strong authentication for any component of the tree, and for the tree as a whole. ZFS employs 256-bit checksums for every block, and offers checksum functions ranging from the simple-and-fast fletcher2 (the default) to the slower-but-secure SHA-256. When using a cryptographic hash like SHA-256, the uberblock checksum provides a constantly up-to-date digital signature for the entire storage pool.

Но всё равно можно SHA-256 включить, если уж ТАК заботиться о данных

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

52. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от Anon Y Mous on 12-Ноя-09, 01:54 
>>Есть мнение, что стоит прислушаться к словам предыдущего оратора и пойти-таки подтянуть
>>матчасть.
>
>Простите пожалста, про дефолтового 2-байтного флетчера я прочел в каком-то из описальников
>ZFS, так что если вы посылаете - так посылайте более конкретно.
>Хотя-бы для того чтобы я наткнулся на правильное описалово. Или уточняйте
>что вы хотели сказать. А то как-то очень троллеобразно выглядит.

А ваше заявление, основанное на данных Радио ОБС, не троллеобразно выглядит? Конкретно - смотреть первоисточник здесь:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/sr...


Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

36. "Почему в ZFS нет необходимости в утилите fsck"  +2 +/
Сообщение от Anon Y Mous on 09-Ноя-09, 11:58 
> А если грамотно бэд-секторов подкинуть в неудачных местах (чего накопители делать любят) - фича пойдет лесом с интересом. И чего тогда делать? Парни из сана технично скипают этот момент.

Это вы технично передергиваете в этом моменте, а парни из Сана рекомендуют предоставить ZFS возможность контролировать уровень избыточности. Метаданные, помимо избыточности вроде зеркал или RAID-Z, хранятся в нескольких экземплярах (два или три) за счет использования дубль-блоков. Плюс, админы локалхоста могут включить дубль-блоки для своих данных даже на одном диске.

Так что, конечно, можно подкинуть бэд-секторов в неудачных местах, но для этого нужно, чтобы они попали во все копиии дубль-блоков, а это уже гораздо менее вероятно.

И потом, не будете же вы утверждать, что не существует набора неудачных бэд-блоков, которые приведут какую-нибудь ext3/ext4 в непригодное состояние?

> Много бухтя про то какое нехорошее железо, но ничего не говоря о том что делать если их допущение на котором все зиждется (что состояние ФС всегда консистентно) вдруг оказалось неверным (мало ли, левая прямая запись на диск, сбой диска, сбоящий проц или память, или хрен там знает чего еще...).

Много бухтите тут, скорее, вы. Консистентность состояния на диске обеспечивается тем транзакционностью и CoW. Если же какой-то диск в системе не обеспечивают надлежащее сохранение этих консистентных состояних, это проблема этого диска. Так что повторяем еще раз - с головой даем ZFS контролировать уровень избыточности. А также смотрим сюда:

http://mail.opensolaris.org/pipermail/onnv-notify/2009-Octob...

Опять же, надеюсь, что вы не будете утверждать, что сбоящие процессор или память не могут привести другую файловую систему непригодное состояние.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

42. "Почему в ZFS нет необходимости в утилите fsck"  +1 +/
Сообщение от User294 (ok) on 10-Ноя-09, 23:26 
>Это вы технично передергиваете в этом моменте, а парни из Сана рекомендуют
>предоставить ZFS возможность контролировать уровень избыточности.

Парни из сана судя по стилю спича просто технично прикрывают свои жопы и пиарятся.

Чувакам вопрос:
- А почему у вас нет fsck?

Чуваки в ответ:
- Мы умеем так, мы умеем сяк и вот этак. И вообще у нас тут CoW, навороты, блаблабла. Но вы должны использовать правильное железо! Блаблабла.

Все бы ничего, только они так и не ответили на вопрос: а что делать если так сложилась ситуация что данные и метаданные неконсистентны. Собссно все журналирующие ФС не нуждаются в fsck если гарантирована консистентность метаданных. И накукуй же они с fsck тогда поставляются? :)

>Метаданные, помимо избыточности вроде зеркал или RAID-Z,
>хранятся в нескольких экземплярах (два или три) за счет
>использования дубль-блоков. Плюс, админы локалхоста могут включить дубль-блоки
>для своих данных даже на одном диске.

Мне все нравится, кроме одного: тепличные допущения "а подыграем ка мы себе, выбрав удобные правила игры и допустив что метаданные всегда валидны, забив на неудобный случай когда это не так" - сосут. В идеальном мире - да, оно катит. В реальном - на диске может быть что угодно, т.к. железо - сбоит, софт - с багами, так что пиндеж саночников неубедителен.

>чтобы они попали во все копиии дубль-блоков, а это уже
>гораздо менее вероятно.

Просто разных гадостей которые могут случиться - навалом. И как бы ФС совсем не в минус если есть утиль способный собрать что-то хоть немного моунтабельное из той лапши которая есть. Потому что дискэдитором то колупать - как-то сильно более уныло и медленно, ага?

>И потом, не будете же вы утверждать, что не существует набора неудачных
>бэд-блоков, которые приведут какую-нибудь ext3/ext4 в непригодное состояние?

Почему же, я этого не утверждал. Они, разумеется, существуют. Но у них есть довольно злые fsck которые достаточно упорно пытаются хоть что-нибудь отколупать. И даже половина данных но в моунтабельной ФС лучше чем слом мозга в дискэдиторе (таким макаром вы и половину не будете доставать, уж поверьте).

>Много бухтите тут, скорее, вы. Консистентность состояния на диске обеспечивается

Пусть они скажут, а что будет если она не обеспечилась. Причин которые к этому приведут я могу придумать вагон. А вот что саночники предложат тогда делать?

>тем транзакционностью и CoW. Если же какой-то диск в системе не обеспечивают надлежащее
>сохранение этих консистентных состояних, это проблема этого диска.

А я то, дебилко, думал что это проблемы юзера этого диска в конечном итоге :)

> Так что повторяем еще раз - с головой даем ZFS контролировать уровень избыточности.

Все это левые отмазы, т.к. не отвечает на вопрос - а что делать если консистетности все-таки кранты? Допущение что "такого не бывает" не выдерживает никакой критики, поскольку методом "от противного" легко воссоздаются ситуации когда это будет не так. Т.е. эти ситуации не являются невозможными и даже - воссаздавабельны за разумное время на планете Земля.Т.е. ничто не мешает им в принципе произойти и самим по себе, "если не повезло".

> А также смотрим сюда:
>http://mail.opensolaris.org/pipermail/onnv-notify/2009-Octob...

Да, мы видим какой-то совсем недавний :D коммит чинящий судя по всему что-то вполне забавненькое - какой-то симпотный assert в парсинге ZIL. Т.е. как я понимаю, до этого коммита можно было схлопотать веселый assert в какой-то ситуации, ну и наверняка это было столь же приятно как серпом по йайцам :).И эти парни лечат что fsck не нужен, ага.

Как по мне - fsck в идеале должен быть утилью которая может пропарсить даже полуразрушенные структуры и восстановить все что было возможно восстановить в данных условиях, перестроив то что перестраивабельно и аннулировав потенциально конфликтные и проблемные метаданные, способные вызвать ругань драйвера ФС (ну, это в идеале). Т.е. том отданый утиле в абы каком состоянии должен прийти к консистентному состоянию, желательно с минимальными потерями данных. А заявы что у меня тома должны быть исправные - не в ладах со здравым смыслом. Да мало ли, может диск(и) настолько умерли что их еле-еле ремонтеры в дата рекавери лабе прочли, и то часть секторов - битые или пропущены, так что и ни о какой консистентности ФС спича более не идет? Случаи то разные бывают и с нахрапом втирать что данные всегда консистентны - наглость пиарщиков, не более.

Так, для особо упертых braindead-ов молящихся на парней из Sun напоминаю: в *штатных* ситуациях, которые так красочно расписаны саночниками, у журнялирующих ФС логика журналирования тоже как бы вполне себе работает. И fsck им при этом нафиг не сдался при таких допущениях - оно при крахе быстро среплеит лог и - вуаля, ФС снова консистентна, можно моунтить и - вперед.

Проблемы начнутся тогда когда это вдруг по какой-то причине не удалось или когда ФС почему-то попала в неконсистентное состояние в обход стандартной логики журналирования, etc. При том причин для этого - два зиллиона. И вот на такие случаи у других ФС есть отдельные тулсы, роль которых - попытаться починить порушенный том настолько насколько это возможно в даденых условиях. Хотя-бы потому что альтернатива в виде вытаскивания кусочков файлов с немонтируемого тома дискэдитором, парся остатки структур ФС в голове самолично заместо драйвера ФС - оптимизма обычно ни у кого не вызывает почему-то.

>Опять же, надеюсь, что вы не будете утверждать, что сбоящие процессор или
>память не могут привести другую файловую систему непригодное состояние.

Разумеется, угробить можно все. Вот только почему-то остальные не вешают макароны на уши а выдают комплект утилей для починки их ФС "in the case of emergency". А вовсе не лечат про то как я не должен попадать в эти самые "emergency". И вот такой подход лично мне не понравился.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

46. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от iZEN (ok) on 11-Ноя-09, 15:05 
>Пусть они скажут, а что будет если она не обеспечилась. Причин которые
>к этому приведут я могу придумать вагон. А вот что саночники
>предложат тогда делать?

zpool scrub <poolname>, невежа.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

50. "Почему в ZFS нет необходимости в утилите fsck"  +1 +/
Сообщение от yalur (ok) on 11-Ноя-09, 23:01 
>Мне все нравится, кроме одного: тепличные допущения "а подыграем ка мы себе,
>выбрав удобные правила игры и допустив что метаданные всегда валидны, забив
>на неудобный случай когда это не так" - сосут. В идеальном
>мире - да, оно катит. В реальном - на диске может
>быть что угодно, т.к. железо - сбоит, софт - с багами,
>так что пиндеж саночников неубедителен.

Когда вы ресет делаете на ext3 - данные негарантированно валидны, нада fsck. когда на zfs - гарантированно валидны. ВСЕ, ВОТ ВСЕ ОТЛИЧИЕ. ВОТ ЧТО ИМЕЮТ ВВИДУ маркетологи от сан. Ни о какой валидности не идет речи при повреждении блоков, никто нигде об этом не говорит. Откуда ввоще вы эту чуш взяли? Есть возможность востановить при наличии резерва. Резерва нет - только обнаружить.

>Почему же, я этого не утверждал. Они, разумеется, существуют. Но у них
>есть довольно злые fsck которые достаточно упорно пытаются хоть что-нибудь отколупать.
>И даже половина данных но в моунтабельной ФС лучше чем слом
>мозга в дискэдиторе (таким макаром вы и половину не будете доставать,
>уж поверьте).

ZFS тоже упорно пытается отколупать. При обнаружении сбойных болоков выдется сообщение, что такой-то и такой то испорчен, востановить нельзя, дается информация какие файлы относятся к сбойным блокам. Все что целое - копируете, а дальше с бекапа все подымаете. Какая бы нибыла фс, востановить в таком случаее ее до полного 100% рабочего состояния возможности нет. Какой прок от "половины данных" файла базы данных? Только бекап вас спасет.

>Как по мне - fsck в идеале должен быть утилью которая может
>пропарсить даже полуразрушенные структуры и восстановить все что было возможно восстановить

Не поверите, но ZFS так и пытается делать. Тем не менее, какой прок от востановленных данных (и от fsck), если они не гарантируют 100% востановление?

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

51. "Почему в ZFS нет необходимости в утилите fsck"  +1 +/
Сообщение от Anon Y Mous on 12-Ноя-09, 01:48 
> Все бы ничего, только они так и не ответили на вопрос: а что делать если так сложилась ситуация что данные и метаданные неконсистентны. Собссно все журналирующие ФС не нуждаются в fsck если гарантирована консистентность метаданных. И накукуй же они с fsck тогда поставляются? :)

Этот вопрос адресуйте авторам этих других файловых систем.

> Просто разных гадостей которые могут случиться - навалом. И как бы ФС совсем не в минус если есть утиль способный собрать что-то хоть немного моунтабельное из той лапши которая есть. Потому что дискэдитором то колупать - как-то сильно более уныло и медленно, ага?

Дискэдитором колупать ничего не надо. Хотите примеров - почитайте zfs-discuss, масса примеров восстановления в самых разных ситуациях - от пула без репликации на сбойнувшем рэйд-контроллере, до RAID-Z с несколькими отказавшими дисками.

> Почему же, я этого не утверждал. Они, разумеется, существуют. Но у них есть довольно злые fsck которые достаточно упорно пытаются хоть что-нибудь отколупать. И даже половина данных но в моунтабельной ФС лучше чем слом мозга в дискэдиторе (таким макаром вы и половину не будете доставать, уж поверьте).

Угу, злые. Специально провел эксперимент - создал ext4, записал туда немного данных, отмонтировал и затер нулями суперблок и все его копии. Вуаля - злые fsck говорят, что нет там никакой ext2 (!!!) и в помине не было:

root@ubuntu:~# fsck -t ext4 -b 229376 /dev/md0
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: Invalid argument while trying to open /dev/md0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>


Хотя казалось бы, чего тут сложного? Размер устройства известен, параметров, с которыми она была создана, не так уж много, метаданные в фиксированных местах. Перебери все варианты, и восстанови... Однако нет, пресловутая злая fsck (которая существует с момента начала жизни ext2, надо полагать) этого до сих пор не научилась делать. Сколько лет прошло? Десять? Больше?

> Пусть они скажут, а что будет если она не обеспечилась. Причин которые к этому приведут я могу придумать вагон. А вот что саночники предложат тогда делать?

Использовать zpool recovery support. Если не поможет - обращаться в zfs-discuss, так как этот zpool recovery support довольно консервативен.

>> тем транзакционностью и CoW. Если же какой-то диск в системе не обеспечивают надлежащее
>> сохранение этих консистентных состояних, это проблема этого диска.
> А я то, дебилко, думал что это проблемы юзера этого диска в конечном итоге :)

Проблемы юзера тоже, если он не озаботился наличием изыбточности

>> А также смотрим сюда:
>>http://mail.opensolaris.org/pipermail/onnv-notify/2009-Octob...
> Да, мы видим какой-то совсем недавний :D коммит чинящий судя по всему что-то вполне забавненькое - какой-то симпотный assert в парсинге ZIL. Т.е. как я понимаю, до этого коммита можно было схлопотать веселый assert в какой-то ситуации, ну и наверняка это было столь же приятно как серпом по йайцам :).И эти парни лечат что fsck не нужен, ага.

Сударь, если бы посмотрели чуть внимательнее, то заметили бы слона - поддержку восстановления пулов, добавленную этим коммитом. А не муху, которой является assert, неправильность которого была обнаружена при работе ztest, то есть в процессе тестирования, которым занимается каждый разработчик постоянно. Покажите аналоги ztest для других ФС? Много найдете?

> Как по мне - fsck в идеале должен быть утилью которая может пропарсить даже полуразрушенные структуры и восстановить все что было возможно восстановить в данных условиях, перестроив то что перестраивабельно и аннулировав потенциально конфликтные и проблемные метаданные, способные вызвать ругань драйвера ФС (ну, это в идеале). Т.е. том отданый утиле в абы каком состоянии должен прийти к консистентному состоянию, желательно с минимальными потерями данных. А заявы что у меня тома должны быть исправные - не в ладах со здравым смыслом. Да мало ли, может диск(и) настолько умерли что их еле-еле ремонтеры в дата рекавери лабе прочли, и то часть секторов - битые или пропущены, так что и ни о какой консистентности ФС спича более не идет? Случаи то разные бывают и с нахрапом втирать что данные всегда консистентны - наглость пиарщиков, не более.

Ответьте на один простой вопрос - как долго вы готовы ждать завершения работы fsck? Если она будет работать год, вы будете ждать?

Если вы готовы ждать долго, то почему злая fsck от ext2 из прошлого века, имевшая достаточно времени обзавестись восстановлением суперблоков путем полного перебора возможных параметров создания ФС, им до сих пор не обзавелась?

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

Ждать дольше, чем время восстановления из бэкапа, нет смысла, а оно

а) конечно
б) известно заранее

> Так, для особо упертых braindead-ов молящихся на парней из Sun напоминаю: в *штатных* ситуациях, которые так красочно расписаны саночниками, у журнялирующих ФС логика журналирования тоже как бы вполне себе работает. И fsck им при этом нафиг не сдался при таких допущениях - оно при крахе быстро среплеит лог и - вуаля, ФС снова консистентна, можно моунтить и - вперед.

А в случае малейшей нештатности - fsck таки требуется. Если сбой произойдет в процессе проигрывания журнале - она тоже понадобится. А сколько на это уйдет времени на ФС размером в несколько десятков терабайт с сотнями миллионов файлов?

> Проблемы начнутся тогда когда это вдруг по какой-то причине не удалось или когда ФС почему-то попала в неконсистентное состояние в обход стандартной логики журналирования, etc. При том причин для этого - два зиллиона. И вот на такие случаи у других ФС есть отдельные тулсы, роль которых - попытаться починить порушенный том настолько насколько это возможно в даденых условиях. Хотя-бы потому что альтернатива в виде вытаскивания кусочков файлов с немонтируемого тома дискэдитором, парся остатки структур ФС в голове самолично заместо драйвера ФС - оптимизма обычно ни у кого не вызывает почему-то.

Заметьте, проблемы начнутся у всех. Только одни либо воспользуются zpool recovery support, чтобы вернуться на пару транзакций назад (потеряв часть данных), либо сразу пойдут восстанавливаться из бэкапов, другие же будут молиться, чтобы fsck что-нибудь исправила, потом, после нескольких неудачных попыток, им таки придется пойти восстанавливаться из бэкапов. Правда, к тому времени те, кто начал восстанавливаться раньше, возможно уже и закончат. Смысл? Бэкапов нет? На fsck уповали? Незачем было себя обманывать, рано или поздно, но взрослеть придется.

Наличие fsck не освобождает от необходимости иметь бэкапы. Или вы будете утверждать обратное?

> Разумеется, угробить можно все. Вот только почему-то остальные не вешают макароны на уши а выдают комплект утилей для починки их ФС "in the case of emergency". А вовсе не лечат про то как я не должен попадать в эти самые "emergency".

Можно точно так же сказать, что другие ФС "вешают макароны на уши" и создают видимость возможности восстановления "in case of emergency", предоставляя fsck, которая, даже если ей там и удастся что-то угадать, никак вам не гарантирует целостность "восстановленных" данных. Она может гарантировать только то, что метаданные ФС более-менее целостны с точки зрения fsck. При этом у ядра на этот счет может быть несколько иное мнение, поскольку fsck тоже может содержать ошибки, и в большинстве случаев код fsck не имеет ничего общего с кодом ядра. Для примитивных файловых систем типа extX синхронизацию кода fsck и кода ядра еще можно худо-бедно поддерживать, для более сложных ФС это может быть не так тривиально.

В случае ZFS при том или ином варианте восстановления ФС вам гарантирует (в рамках вероятности необнаружения ошибок используемого алгоритма контрольных сумм) целостность тех данных, к которым вы смогли получить доступ.

Что имеет смысл делать - так это выявлять наиболее часто встречающиеся на практике причины невозможности открытия пула, и работать над их устранением, причем лучше всего в онлайновом режиме. И над этим работают - недавний комит тому пример.

Вот этот вот CR - еще один пример:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6...

Заметьте, речь идет не об fsck, а о восстановлении на лету в процессе работы.

У вас есть еще конкретные примеры реально встречающихся на практике причин невосстановимых повреждений - вперед, баги на bugs.opensolaris.org можно открывать кому угодно. И от этого будет гораздо больше пользы, чем от пространных рассуждений на тему отсуствия fsck для ZFS и сферических конях в безвоздушном пространстве.

> И вот такой подход лично мне не понравился.

Это ваш выбор, вот только не нужно его никому навязывать.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

15. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от Andrew Kolchoogin on 07-Ноя-09, 15:50 
>  За 40 лет в UNIX сформировалось понятие об утилите fsck,
> - хрень проверяющая целостность файловой системы.

"Нет". (C)

fsck хоть и расшифровывается, как file system check, однако, check -- это лишь одна из её функций. Вторая -- восстановление consistent state файловой системы, если она повреждена.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

18. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от vitek (??) on 07-Ноя-09, 20:42 
правильно.
но второе не может быть без первого... вначале чек, а потом рековери. и никак иначе.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

41. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от sshutdownow email(ok) on 10-Ноя-09, 15:50 
>>  За 40 лет в UNIX сформировалось понятие об утилите fsck,
>> - хрень проверяющая целостность файловой системы.
>
>"Нет". (C)
>
>fsck хоть и расшифровывается, как file system check, однако, check -- это
>лишь одна из её функций. Вторая -- восстановление consistent state файловой
>системы, если она повреждена.

а в xfs fsck тоже был return 0;

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

26. "Почему в ZFS нет необходимости в утилите fsck"  –4 +/
Сообщение от User294 (ok) on 08-Ноя-09, 06:58 
>Собственно, для ISO9660/UDF, Squashfs,

А там то все просто - это read-only FS. Почему нет fsck? Потому что удачи тебе в записи исправленной ISO9660 на "штамповку" засунутую в сидюшник, ога :D. Оно исправляется, только иначе - отправкой сбоящего носителя в треш и покупкой нового взамен.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

29. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от pavlinux (ok) on 08-Ноя-09, 09:43 
>>Собственно, для ISO9660/UDF, Squashfs,
>
>А там то все просто - это read-only FS. Почему нет fsck?
>Потому что удачи тебе в записи исправленной ISO9660 на "штамповку" засунутую
>в сидюшник, ога :D. Оно исправляется, только иначе - отправкой сбоящего
>носителя в треш и покупкой нового взамен.

cat /dev/cdrom | fsck.iso9660 -af > fixed.img :)  

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

44. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от User294 (ok) on 10-Ноя-09, 23:48 
Угу, картина маслом - роутер у которого ВСЯ ФЛЕХА занята squash-ом - крайне типичный такой сценарий, в любом магазине вон куда ни ткни оно вот такое вот. И куда предлагается записать починеный вариант squash? :) В /dev/null чтоли? А то больше как бы и некуда особо. Поэтому никто и не парится - в случае нужды починки ФС делается полная переливка образа, вот и не надо squash-у никакого fsck. А если и перелить образ не получается - так вам в сервисник или на свалку. С цд - опять же исходный том read-only а потому починке не подлежит.

Вообще среди fsck обычно не принято писать результат починки на destination отличный от source, как минимум без специальных плясок с бубном. По вполне понятным причинам (а кто сказал что destination вообще существует и там достаточно места и что кто-то хотел именно такой результат?).Собссно если том только для чтения, его починка - оксюморон.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

45. "Почему в ZFS нет необходимости в утилите fsck"  +3 +/
Сообщение от pavlinux (ok) on 11-Ноя-09, 04:31 
>Угу, картина маслом - роутер у которого ВСЯ ФЛЕХА занята squash-ом -
>крайне типичный такой сценарий, в любом магазине вон куда ни ткни
>оно вот такое вот. И куда предлагается записать починеный вариант squash?
>:) В /dev/null чтоли? А то больше как бы и некуда
>особо. Поэтому никто и не парится - в случае нужды починки
>ФС делается полная переливка образа, вот и не надо squash-у никакого
>fsck. А если и перелить образ не получается - так вам
>в сервисник или на свалку.

Cижу в тундре, до ближайшего телефона 300 км на оленях, самолёт
летает 2 раза в год. А данные сейсмологических исследований надо
писать раз в день. А тут прибор накрылся, но его можно загрузить
с сервисного диска, а тот сццука от мороза покорёжило, правда не весь,
а только начало, а прошивка всего 8 мегоф. Вот если бы прогнать через
fsck.iso9660, может удаться её спасти. Я б в ручную записывал, но 1 день
логов это примерно 200 листов A4 =) А нам выдали только одну упаковку.
Туалетной мало - 53 метра x 15 недель:( Да и карандаш всего один.
Из-за сильной ионизации атмосферы в полярную ночь, никакие беспроводные
связи не работают. Осталось только ловить моржей, медведей и оленей,
делать из них пергамент, и писать их жиром с сажей. (ну или кровью)  :)
Ещё вариант, научить почтового баклана, чтоб с флэшкой летал до центра,
но где же я в полярную ночь поймаю баклана. :(


Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

25. "Почему в ZFS нет необходимости в утилите fsck"  –1 +/
Сообщение от User294 (ok) on 08-Ноя-09, 06:52 
>Потому что ZFS создали Боги, и в ней нет ошибок и багов,
>а данные, с вероятностью 1, нельзя потерять.

Пусть они если такие умные, расскажут: что делать при серьезном разрушении метаданных ФС? И кто сказал что при этом удастся без ошибок откатиться к снапшоту? Они так много пиндят про CoW но ни звука не издают что делать если метаданные достаточно хардкорно посыпались.

В идеале, FSCK должен прогуляться по ФС и провалидировать метаданные на осмысленность и логическую корректность и перестроить то что явно порушено или хотя-бы попытаться нейтрализовать вред от заведомо невалидных метаданных, хотя-бы убив их. Да, часть данных может быть утеряна. Но ФС с хоть какими-то частично доступными данными - это лучше чем немоунтабельная ФС откуда данные не получить вообще НИКАК кроме разве что диск-эдитора. В итоге звучит весь этот спич в духе "маркетологи вещают про панацею - CoW".

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

33. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от аноним on 08-Ноя-09, 22:03 
>Пусть они если такие умные, расскажут: что делать при серьезном разрушении метаданных
>ФС? И кто сказал что при этом удастся без ошибок откатиться
>к снапшоту? Они так много пиндят про CoW но ни звука
>не издают что делать если метаданные достаточно хардкорно посыпались.

И откуда же возьмется "хардкорное нарушение"? Любое нарушение integrity (cat /dev/random >/dev/ad*) отловят чексуммы, поэтому битые метаданные не будут использованы _никогда_. Посему достаточно взять самый последний из 128 уберблоков, ссылающихся на консистентные метаданные, и все. Прекратите пукать, и опишите по пунктам конкретную ситуацию, с которой, по-вашему, ZFS не справится.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

34. "Почему в ZFS нет необходимости в утилите fsck"  –2 +/
Сообщение от User294 (ok) on 09-Ноя-09, 01:18 
Мне не понравилось вот что: саночники очень упирают на природу CoW и на то что консистентность - есть. Не утруждаясь объяснениями того а что будет если консистентности вдруг нет. Это выглядит сочинением маркетологов на тему "почему у нас нет fsck" смысл которого сводится к "да вы не волнуйтесь, мы лучше знаем что вам нужно". Ну, как обычно, собственно - все маркетологи одинаковы.

Насчет "_никогда_" ... погодите, а там по дефолту вроде весьма слабые чексуммы, всего 2 байта. Через сколько они сдадутся рандому с его грубой силой - калькулятор освойте, а потом расскажете как там 2-байтный чексумм нам гарантирует "никогда". А SHA1 считать в реалтайме вы подзаботаетесь пожалуй, в плане нагрузки от этого действа на проц (для недефолтного sha-1 допущение про "никогда" еще можно засчитать с его разрядностью хэша).

А не справится... ну а как насчет ситуации когда на диск пишется не то что посчитано и предположено? Саночники много пиндят про кривое железо и какое оно ... .Но ни звука не говорят - а что же все-таки делать в таких случаях. Грубо говоря - возникает ощущение что это маркетологи пытаются успокоить клиентов или типа того. Ну, сан вообще в довольно нахальном пиаре был замечен в последнее время, где больше макарон на уши чем по делу.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

49. "Почему в ZFS нет необходимости в утилите fsck"  +3 +/
Сообщение от yalur (ok) on 11-Ноя-09, 22:37 
>Мне не понравилось вот что: саночники очень упирают на природу CoW и
>на то что консистентность - есть. Не утруждаясь объяснениями того а
>что будет если консистентности вдруг нет. Это выглядит сочинением маркетологов на

Как же до вас туго доходит:
Консистентность - подразумевается, что при работе на исправном железе, ФС постоянно находится в консистентном состоянии и БАСТА. ОНА ВСЕГДА КОНСИСТЕНТНА. НЕТ ТАКОГО ПОНЯТИЯ ВООБЩЕ  - НЕКОНСИСТЕНТНАЯ ФС - ДЛЯ ДАННОГО СЛУЧАЯ.  
Если проблемы с железом/бб - это уже другой случай. Никак не относится к понятию консистентности. Это повреждение ФС, и при возможности идет востановление данных (если есть резервные копии). если их нет - ДА, ДА, И ЕЩЕ РАЗ ДА. ЭТО ХАНА, ТОРБА, если хотите ЖОПА, если у вас нет бекапа. Так вас устраивает? И вообще чем вы думаете? Если блок испорчен и нет резервной копии, то никакая ФС, даже богом написанная вам не поможет. Если вам руку отрезать - fsck поможет?

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

2. "Почему в ZFS нет необходимости в утилите fsck"  –2 +/
Сообщение от Аноним (??) on 07-Ноя-09, 10:30 
есть перевод статьи?
p.s. с английским туго, прогуливал уроки сидя  в информатике
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от iZEN (ok) on 07-Ноя-09, 10:40 
zpool scrub poolname — и прочувствуйте фоновую проверку. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Почему в ZFS нет необходимости в утилите fsck"  –1 +/
Сообщение от Andrew Kolchoogin on 07-Ноя-09, 11:34 
> zpool scrub poolname — и прочувствуйте фоновую проверку. :)

Почувствуйте школоту, не читавшую документацию.

Команда "zpool scrub" проверяет пул на целостность. То есть, грубо говоря, читает каждый занятый блок пула, считает его контрольную сумму и сравнивает с записанной на диске. С помощью команды "zpool scrub" делается то же самое, что и с помощью, фактически, утилиты "diskdefect" в ранних версиях BSD. Утилита "fsck" никакого отношения к работе команды "zpool scrub" не имеет -- в том месте, где "zpool scrub" обнаружит ошибку и попытается отрекаверить блок, "fsck" вывалится с мерзкими криками: "UNEXPECTED INCONSITENCY: CAN'T READ BLK xxx".

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

19. "Почему в ZFS нет необходимости в утилите fsck"  –1 +/
Сообщение от vitek (??) on 07-Ноя-09, 20:49 
перефразирую - т.е. если "отрекаверить" не получится, то "zpool scrub" очень тактично намекнёт, что восстановить не получилось....
не то что эта фсчк с мерзкими криками.... просто ни каких сравнений.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

48. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от yalur (ok) on 11-Ноя-09, 22:22 
>перефразирую - т.е. если "отрекаверить" не получится, то "zpool scrub" очень тактично
>намекнёт, что восстановить не получилось....
>не то что эта фсчк с мерзкими криками.... просто ни каких сравнений.
>

да, неполучится, неполучится. Как вы собираетесь востановить то, на что нет резервных копий. Но мы покрайней мере знаем что есть проблема. При этом он напишет какой именно файл задевает этот блок и там вы уже себе решаете что делать. Хоть бекап хоть еще как. fsck может даже не ругнуться, тогда как zfs всегда обнаружит сбой, а если есть хоть одна копия, то востанавливает ошибку.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

31. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от iZEN (ok) on 08-Ноя-09, 18:02 
>Почувствуйте школоту, не читавшую документацию.

Молчали бы уж лучше в тряпочку и не говорили полной ерунды тому, кто это имел при неудачных обесточиваниях компа с FreeBSD 6.1...8.0-RC2.
И fsck (на UFS2), и scrub (на ZFS) — обе начинают проверку ФС в ФОНЕ, но при работе scrub, в отличие от fsck, пользоваться компьютером просто не хочется из-за невыносимых тормозов.

>Команда "zpool scrub" проверяет пул на целостность.

А ещё масло масляное.

>где "zpool scrub" обнаружит ошибку и попытается отрекаверить блок, "fsck" вывалится с мерзкими криками: "UNEXPECTED INCONSITENCY: CAN'T READ BLK xxx".

Бред. На FreeBSD fsck никуда не вываливалось, а просило: "SALVAGE? Y/N".

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

47. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от yalur (ok) on 11-Ноя-09, 22:13 
>кто это имел при неудачных обесточиваниях компа с FreeBSD 6.1...8.0-RC2.
>И fsck (на UFS2), и scrub (на ZFS) — обе начинают проверку
>ФС в ФОНЕ, но при работе scrub, в отличие от fsck,
>пользоваться компьютером просто не хочется из-за невыносимых тормозов.

Бред, никогда scrub в фоне при загрузке компа (как это есть с fsck) не запускается.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

53. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от iZEN (ok) on 12-Ноя-09, 23:34 
>>кто это имел при неудачных обесточиваниях компа с FreeBSD 6.1...8.0-RC2.
>>И fsck (на UFS2), и scrub (на ZFS) — обе начинают проверку
>>ФС в ФОНЕ, но при работе scrub, в отличие от fsck,
>>пользоваться компьютером просто не хочется из-за невыносимых тормозов.
>
>Бред, никогда scrub в фоне при загрузке компа (как это есть с
>fsck) не запускается.

Что касается scrub, то да, действительно он сам не начинает проверку после внезапного рестарта компа — только что нажал на Reset на работающей FreeBSD 8.0-PRERELEASE с zpool в корневике:
% uname -a
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
% zpool status

  pool: Arena
state: ONLINE
scrub: none requested
config:

    NAME                                          STATE     READ WRITE CKSUM
    Arena                                         ONLINE       0     0     0
      gptid/e0fa02b3-81a6-11de-8aa6-02508d92a2eb  ONLINE       0     0     0
      gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb  ONLINE       0     0     0

errors: No known data errors

  pool: amd64rio
state: ONLINE
scrub: none requested
config:

    NAME              STATE     READ WRITE CKSUM
    amd64rio          ONLINE       0     0     0
      mirror          ONLINE       0     0     0
        gpt/rio_zfs2  ONLINE       0     0     0
        gpt/rio_zfs1  ONLINE       0     0     0

errors: No known data errors

scrub нужно "пиннуть" руками, чтобы он начал выполнять свою работу (в фоне):
% zpool scrub amd64rio
% zpool status
  pool: Arena
state: ONLINE
scrub: none requested
config:

    NAME                                          STATE     READ WRITE CKSUM
    Arena                                         ONLINE       0     0     0
      gptid/e0fa02b3-81a6-11de-8aa6-02508d92a2eb  ONLINE       0     0     0
      gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb  ONLINE       0     0     0

errors: No known data errors

  pool: amd64rio
state: ONLINE
scrub: scrub in progress for 0h5m, 0,85% done, 11h35m to go
config:

    NAME              STATE     READ WRITE CKSUM
    amd64rio          ONLINE       0     0     0
      mirror          ONLINE       0     0     0
        gpt/rio_zfs2  ONLINE       0     0     0
        gpt/rio_zfs1  ONLINE       0     0     0

errors: No known data errors

Пока тормозов не ощущаю. Отклик GUI с запаздыванием 2...5 секунд. Загрузка CPU — 17...25%. Время запуска приложений увеличилось на 5...10 секунд, но ранее запущенные и остановленные приложения стартуют мгновенно.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

54. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от iZEN (ok) on 13-Ноя-09, 00:00 
Спустя 26 минут от начала проверки:
% zpool status amd64rio
  pool: amd64rio
state: ONLINE
scrub: scrub in progress for 0h26m, 12,41% done, 3h6m to go
config:

    NAME              STATE     READ WRITE CKSUM
    amd64rio          ONLINE       0     0     0
      mirror          ONLINE       0     0     0
        gpt/rio_zfs2  ONLINE       0     0     0
        gpt/rio_zfs1  ONLINE       0     0     0

errors: No known data errors

Курсор в Xfce ни разу не замер, что удивительно. Однако отклик GUI происходит "урывками" — то замирает на 5 секунд, то потом отмирает и быстро воспроизводятся проделанные действия — добирается слово, набранное с клавиатуры, открывается меню при выборе пункта меню мышкой и т.д. Как-будто киноплёнка притормаживается на секунды, а потом быстро прокручивается до нормального состояния.
Работать можно, но неприятно.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

40. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от Stop scrubbing on 10-Ноя-09, 14:47 
       zpool scrub [-s] pool ...

           Begins a scrub. The scrub examines all data in the specified  pools
           to  verify  that  it checksums correctly. For replicated (mirror or
           raidz) devices, ZFS automatically  repairs  any  damage  discovered
           during  the  scrub. The "zpool status" command reports the progress
           of the scrub and summarizes the results of the scrub  upon  comple-
           tion.

           Scrubbing  and resilvering are very similar operations. The differ-
           ence is that resilvering only examines data that ZFS  knows  to  be
           out  of  date (for example, when attaching a new device to a mirror
           or replacing an existing device), whereas  scrubbing  examines  all
           data to discover silent errors due to hardware faults or disk fail-
           ure.

           Because scrubbing and resilvering are I/O-intensive operations, ZFS
           only  allows  one at a time. If a scrub is already in progress, the
           "zpool scrub" command terminates it and starts a new  scrub.  If  a
           resilver  is  in progress, ZFS does not allow a scrub to be started
           until the resilver completes.

           -s    Stop scrubbing.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от ffsdmad (ok) on 07-Ноя-09, 10:55 
а скоро заметки про ZFS будут начинаться так
> один из инженеров Oracle опубликовал <
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от sHaggY_caT (ok) on 07-Ноя-09, 13:32 
В Oracle будет и ZFS, и btrfs, ocfs, lustre... Не много ли на них одних :)? Остальным остается, из вкусного и инновационного, gfs, проприетарный gpfs IBM (хотя, конечно, он очень вкусен, есть уже сейчас, и, во многом интереснее ZFS/brtfs, если, конечно, теплое может быть интереснее мягкого) и.. кучка новеньких пионерских ФС, и все..?

У Оракля монополия на файловые системы :)?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

20. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от vitek (??) on 07-Ноя-09, 20:51 
теперь - да.
и не только на фс.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

28. "Почему в ZFS нет необходимости в утилите fsck"  +/
Сообщение от User294 (ok) on 08-Ноя-09, 07:12 
>У Оракля монополия на файловые системы :)?

Не раньше чем монополия на mainline ядро и всех разработчиков комитящих в ФС :P. Но задавать вектор развития - пожалуй сможет, если захочет.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру