Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Изучение изменения размера кодовой базы Ext4, Btrfs и XFS, opennews (??), 23-Июн-11, (0) [смотреть все] Проблема только в том что у XFS строк уже больше, а у btrfs фичность как-то побо, Аноним (-), 12:28 , 23-Июн-11, (1) +2 // Ну вообще то генерация документации в т ч манов на основании соотв образом пре, klalafuda (?), 12:41 , 23-Июн-11, (4) +10 // Правда вот такие мануалы обычно стойко навевают воспоминания о анекдоте моя ско, Аноним (-), 14:10 , 23-Июн-11, (14) –1 // неа а вот такие коментари уж точно навевают мысли о быдлокодере признайся сразу, ананим (?), 17:01 , 23-Июн-11, (46) А тут надо помнить, что административные проблемы не решаются техническими средс, fr0ster (ok), 17:12 , 23-Июн-11, (50) –1 Э-э-э-э О чём Вы Комментарии к коду - не административная проблема, а техниче, ананим (?), 17:19 , 23-Июн-11, (54) –1 зыжайзен жабадок снизу уже привёл в качестве доказательства А я даже добавлю -, ананим (?), 17:26 , 23-Июн-11, (58) +1 Я с этим столкнулся не на жабе а на абапе, но вот привычка комментить чуть ли не, fr0ster (ok), 17:32 , 23-Июн-11, (62) если каментить надо каждый чих 8212 то это быдлокод нормальный код отлично ч, anonymous (??), 22:21 , 23-Июн-11, (102) –2 Техническая это использовать Доксиген или еще чтото для документирования, а треб, fr0ster (ok), 17:26 , 23-Июн-11, (59) ну дык и я о чём Важно не путать проблемы со средствами хорошо документированный, ананим (?), 17:40 , 23-Июн-11, (65) Хорошо документированный код это вообще не проблема Плохое документирование техн, fr0ster (ok), 18:01 , 23-Июн-11, (74) фиг там Административная она до тех пор, пока кода мало, а тот кто его написал е, ананим (?), 18:32 , 23-Июн-11, (81) Это всегда административная проблема Если руководитель допустил завязанность пр, fr0ster (ok), 21:43 , 23-Июн-11, (99) –1 эх, молодо-зелено Через дцать лет любой проект завязан на одного человека Д, ананим (?), 03:33 , 24-Июн-11, (134) какие в попу сейчас госконторы тут вон Путин возмущался что в приморье таможню у, ананим (?), 11:02 , 24-Июн-11, (157) Признаюсь в том что автоматически сгенеренная документация - как правило такой ж, Аноним (-), 17:22 , 23-Июн-11, (56) http wiki lustre org lid subsystem-map subsystem-map htmlвот документация кото, Аноним (-), 17:31 , 23-Июн-11, (61) Да как сказать Фифти-фифти Врубиться по этой доке в принципе можно Но читать , Аноним (-), 18:05 , 23-Июн-11, (75) Вообще говоря дока автоматом сгенерированная из нормально написанных комментарие, fr0ster (ok), 18:11 , 23-Июн-11, (77) Честно говоря, сырцы и коменты в них я могу почитать и без тупых автогенераторов, Аноним (-), 01:21 , 24-Июн-11, (126) авторы Qt удивлены , anonymous (??), 01:28 , 24-Июн-11, (128) Они не умеют использовать grep , Аноним (-), 12:19 , 24-Июн-11, (165) Автоматически генерируемая документация полезна при использовании библиотек, так, PereresusNeVlezaetBuggy (ok), 21:33 , 23-Июн-11, (98) +2 верно Но так же верно, что вставить в нужное место свой коммент забывают уж о, ананим (?), 17:34 , 23-Июн-11, (63) Да не только быдло, вон там человек в общем то по делу подпинывает btrfs ников з, Аноним (-), 18:23 , 23-Июн-11, (79) оставлю это на его совести Dа нахрена Разрабам ФС на это покласть, а от нови, ананим (?), 18:43 , 23-Июн-11, (83) Думаю у него совесть чиста - он в вопросе разбирается Нафига Чтобы был ман дающ, Аноним (-), 23:28 , 24-Июн-11, (189) За счёт комментариев Строго говоря, Вы правы, но самому не смешно ли Нет уж, у, Michael Shigorin (ok), 21:25 , 26-Июн-11, (218) Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев , iZEN (ok), 19:03 , 23-Июн-11, (84) О, как это в стиле жабистов сначала создать себе проблем, а потом их героически, Аноним (-), 01:27 , 24-Июн-11, (127) Преждевременные оптимизации вредны Сначала пишем код 8212 потом оптимизируем, iZEN (ok), 01:38 , 24-Июн-11, (130) –1 это был пример рассуждений типичного быдлокодера ну и что, что у вас техника б, anonymous (??), 01:42 , 24-Июн-11, (131) +2 К сожалению писать качественный код стало экономически не выгодно Зачастую прощ, kshetragia (ok), 05:46 , 24-Июн-11, (139) как язык 8212 да а вот по поводу инструментария 8212 не согласен его пон, anonymous (??), 08:15 , 24-Июн-11, (140) писец Можно подумать С и С запрещают писать комменты по стандарту доксигенов И, ананим (?), 11:07 , 24-Июн-11, (158) LSE с вами не согласны , Аноним (-), 23:29 , 24-Июн-11, (190) Ит с эн оверстэйтмент, мэн http lwn net Articles 443775 , Michael Shigorin (ok), 19:04 , 26-Июн-11, (216) Да, конечно, сперва делаем, потом думаем Хотя немного подумав заранее, можно из, Аноним (-), 12:29 , 24-Июн-11, (166) он даже про valgrind не знает, потому что для его жабы оно бесполезно а если в , anonymous (??), 13:25 , 24-Июн-11, (179) У него наверное даже ума собрать статистику сисколов strace ом не хватит - такие, Аноним (-), 23:35 , 24-Июн-11, (191) Для нормального кода IDE не нужен Он должен быть интуитивно понятен Где непоня, kshetragia (ok), 05:42 , 24-Июн-11, (138) это совершенно не важно да и 8212 что значит 171 как реально выглядит 187, anonymous (??), 08:19 , 24-Июн-11, (141) Смешались в кучу кони, люди и получилась хрень на блюде , Аноним (-), 12:30 , 24-Июн-11, (167) сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон, anonymous (??), 13:15 , 24-Июн-11, (176) Судя по повсеместному распостранению Оберона не так уж эксперт и неправ , Аноним (-), 18:37 , 25-Июн-11, (203) Система отличная, но малораспространенная Пока же приходится смотреть на реализ, kshetragia (ok), 07:07 , 27-Июн-11, (227) в принципе, BlackBox Component Builder открыт вроде как даже уже есть порт ядра, anonymous (??), 07:22 , 27-Июн-11, (229) действительно мелочь , kshetragia (ok), 14:24 , 27-Июн-11, (235) на крайний случай есть winelib убегает, увёртываясь от булыжников , anonymous (??), 16:13 , 27-Июн-11, (237) Как только появится свободная реализация в исходниках под Unix И не Оберона, а , kshetragia (ok), 07:06 , 27-Июн-11, (226) BlackBox Component Builder я, кстати, после открытия кода отрывал компилятор от, anonymous (??), 07:25 , 27-Июн-11, (230) Это значит, что я должен быть в состоянии прочитать код без IDE костылей И его , kshetragia (ok), 07:15 , 27-Июн-11, (228) у оберона вообще с понятием 171 файл 187 некоторая напряжёнка они, вроде бы, anonymous (??), 07:30 , 27-Июн-11, (231) документация к Qt генерится из исходников лучше документации я пока не видел, д, anonymous (??), 22:42 , 23-Июн-11, (103) +1 На то и посажен кодер , а на пккодер , maginoid (ok), 20:30 , 30-Июл-14, (239) Нуну, и что, неужели btrfs уже годна для продакшена Фичи-фичами, а главное - ста, anon8 (ok), 13:02 , 23-Июн-11, (6) // А еще пряморукость Я полностью согласен в отношении с Btrfs с Эдуардом Шишкины, BratSinot (?), 13:42 , 23-Июн-11, (8) // Предложения, алтернативы , koblin (ok), 14:17 , 23-Июн-11, (17) +1 У Шишкина было какое-то очень предвзятое мнение, наверное потому что он разработ, Аноним (-), 14:32 , 23-Июн-11, (19) +3 плевались как раз авторы btrfs, Аноним (-), 15:12 , 23-Июн-11, (24) Да они там на пару плевались, но в результате - тюнинг твикинг все-таки был Спа, Аноним (-), 15:21 , 23-Июн-11, (27) +1 Файловая система должна работать с любыми данными Если заявила отсутствие огран, Михаил (??), 15:35 , 23-Июн-11, (35) +1 У них раньше было ограничение прямо в утилитах - они посылали при попытке создат, Аноним (-), 17:43 , 23-Июн-11, (67) +2 Еще не годна Но неотвратимо приближается к этому моменту В продакшне Разумеет, Аноним (-), 14:14 , 23-Июн-11, (16) +1 что значат эти слова винда вон нестабильна даже при штатном использовании без х, anonymous (??), 22:54 , 23-Июн-11, (105) // Винда стабильна или нестабильна при штатном использовании точно так же, как люба, PereresusNeVlezaetBuggy (ok), 23:10 , 23-Июн-11, (108) Да какой там бубен, если видеодрайвера падают Ты или пользуешься футуристичной , Аноним (-), 12:33 , 24-Июн-11, (168) Видеокарты нормальные используйте Или кроме ATI AMD и NVIDIA других названий , PereresusNeVlezaetBuggy (ok), 13:54 , 24-Июн-11, (183) Почему же, знаем встроенные в интелские чипсеты еще Вообще тормозная гадость С, Аноним (-), 00:12 , 25-Июн-11, (193) Второй ноутбук с Intel ом на борту В винде проблем нет вообще В X org есть неб, PereresusNeVlezaetBuggy (ok), 02:34 , 25-Июн-11, (196) Не знаю как там у вас нет проблем, а я регулярно наталкиваюсь на взвисы семерок , Аноним (-), 19:33 , 25-Июн-11, (204) Ну так не используйте Intel В чём проблема Вы что, решили, что я вас агитирую , PereresusNeVlezaetBuggy (ok), 00:41 , 26-Июн-11, (212) Вроде бы речь шла про серверную часть -- удивился, заглянул на nomachine com, NX, Michael Shigorin (ok), 21:38 , 26-Июн-11, (219) более того, в никсах тоже есть xrdp это я про сервер И нормально работающие кс, ананим (?), 08:17 , 27-Июн-11, (232) а я не про это говорил я хотел узнать, что значит 171 годно для продакшена 1, anonymous (??), 13:28 , 24-Июн-11, (180) У каждого свой продакшн, и своя правда Nothing more, nothing less , PereresusNeVlezaetBuggy (ok), 02:37 , 25-Июн-11, (197) О-оо Ну например, жрёт ресурсы пачками, зато как-то принимает нагрузку Или, Michael Shigorin (ok), 20:13 , 26-Июн-11, (217) вот именно потому вопрос 171 оно уже готово для продакшена 187 имеет смысл , anonymous (??), 05:07 , 27-Июн-11, (225) вообще продакшн как и ынтырпрайз - слова сильно специфические Из разряда что кт, ананим (?), 08:21 , 27-Июн-11, (233) JavaDoc видел Это оно самое , iZEN (ok), 16:28 , 23-Июн-11, (41) +1 Зато там не будет ситуаций, когда вначале приходит патч в ядро вот эта хрень с , Elhana (ok), 16:31 , 24-Июн-11, (187) так и правельно делают, чем лучше исходники снабжены коментами, тем легче искать, Битазавр (?), 12:33 , 23-Июн-11, (2) +2 // Если есть необходимость комментировать код, то значит этот код плохо написан и е, пельмешка (?), 13:58 , 23-Июн-11, (9) –16 // Сам, то писал хоть раз Суровый челябинский кодер Если код не документирован, Зилибоба (ok), 14:09 , 23-Июн-11, (13) +1 // Не челябинский кодер, а архуский Дания Это мнение про комментарии принадлежит, пельмешка (?), 14:33 , 23-Июн-11, (20) Цитата так же точна, как напев Желтой Субмарины Абрамом по телефону С Что собств, fr0ster (ok), 15:28 , 23-Июн-11, (31) +1 Ну и шут с ним и его великом -- если гура до седины в бороде дожил, а не осозн, Michael Shigorin (ok), 15:30 , 23-Июн-11, (33) Ой, вот таки не надо сразу гуру дураком делать Сначала посмотрите насколько , fr0ster (ok), 15:32 , 23-Июн-11, (34) if а с выражениями действительно надо осторожней -- мало ли кто как поймёт , Michael Shigorin (ok), 15:35 , 23-Июн-11, (36) лично я даже и не думал, что выссказывание Страуструпа о необходимости писать ко, ананим (?), 17:48 , 23-Июн-11, (69) а вот тут начинает не зватать терминов комментировать перед функцией 8212 вх, anonymous (??), 23:08 , 23-Июн-11, (107) от быдло-кодера слышу Этож писец Теперь что и в структурах не писать какие зна, ананим (?), 03:45 , 24-Июн-11, (135) В идеальном случае код должен быть написан так чтобы коментов не требовалось В , Аноним (-), 14:41 , 23-Июн-11, (21) Просто Вы не видели реализацию сложных алгоритмов или структур данных , Аноним (-), 15:15 , 23-Июн-11, (25) Почему же, видел Просто если хочется что-то именно фундаментально задокументиро, Аноним (-), 15:22 , 23-Июн-11, (28) Затем, что в какой то момент вы рискуете вместо пояснения темных мест реализации, fr0ster (ok), 15:30 , 23-Июн-11, (32) +2 Если код пишут товарисчи с таким подходом - им лучше всего вообще не пользоватьс, Аноним (-), 18:28 , 23-Июн-11, (80) Лучше то лучше, но иногда выбор небогат Здесь Родос, здесь и прыгай , fr0ster (ok), 20:49 , 23-Июн-11, (91) Ну тогда прыгайте, чо Только так и убиться можно Умные люди обычно стараются п, Аноним (-), 01:32 , 24-Июн-11, (129) Вот умные люди и комментируют свой код Буквально каждый чих Что бы потом не вспо, fr0ster (??), 13:36 , 24-Июн-11, (181) если это надо специально вспоминать, то это называется 171 хак 187 хаки, ко, anonymous (??), 13:41 , 24-Июн-11, (182) Это не хак, это требования контролирующих органов Ну вот положено считать так, , fr0ster (??), 15:04 , 24-Июн-11, (184) по-моему, ты только что описал грязный хак , anonymous (??), 15:12 , 24-Июн-11, (185) Чтобы не было рассинхронизации документации и кода , segoon (ok), 16:23 , 23-Июн-11, (39) +2 ты риальне веришь, что при наличии этого в одном файле вероятность десинка меньш, anonymous (??), 23:16 , 23-Июн-11, (109) –4 по исходникам, хорошо и грамотно документированым, как раз и делают документацию, mealstrom (?), 12:40 , 23-Июн-11, (3) +1 А ширину строк учли, интересно , Дмитрий (??), 12:50 , 23-Июн-11, (5) // в таком случае -- вообще лучше сравнивать количество токенов слов и разделяющих, Аноним123321 (ok), 13:42 , 23-Июн-11, (7) Имхо, это плохо говорит о ядре Код не реюзается, а содержит много дубликатов , crypt (??), 14:07 , 23-Июн-11, (11) +1 // Это говорит о том, что еще оптимизировать и оптимизировать Тоесть - графики мог, Зилибоба (ok), 14:10 , 23-Июн-11, (15) Большой вопрос станет ли эффективнее если каждую строку выносить в функцию и пот, Аноним (-), 15:26 , 23-Июн-11, (30) –2 // Откройте для себя inline-функции , kibab (?), 15:50 , 23-Июн-11, (37) // Да Давайте сделаем каждую строку программы отдельной инлайн-функцией Извращать, Аноним (-), 17:46 , 23-Июн-11, (68) code const static inline volatile unsigned char __attribute__ always_inline , pavlinux (ok), 00:23 , 24-Июн-11, (117) +2 Ты уже заблудился P , Аноним (-), 01:45 , 24-Июн-11, (132) +2 Угу В одном коде везде написано 171 for i 0 i sz i 187 , а в друго, PereresusNeVlezaetBuggy (ok), 16:54 , 23-Июн-11, (45) Пути графиков сойдутся на 50тыс срок , zamir (??), 14:08 , 23-Июн-11, (12) +1 Статья из серии Занимательная фалометрия для Чайников или как создать срач на р, ImPressed (ok), 14:28 , 23-Июн-11, (18) +5 // Чем больше код, тем больше ошибок Чем меньше комментариев, тем сложнее его подде, Аноним (-), 15:19 , 23-Июн-11, (26) // С другой стороны и при минимуме кода бывают интересные ошибки Думали код времен, fr0ster (ok), 17:04 , 23-Июн-11, (48) // Бываают, но мистер D J Berstein делом доказал что это отличный способ минимизац, Аноним (-), 12:41 , 24-Июн-11, (169) Чем меньше _полезных_ комментариев И чем больше бесполезных Индусское комменти, PereresusNeVlezaetBuggy (ok), 17:07 , 23-Июн-11, (49) +2 // Маразм, но иногда алгоритм не так прозрачен, как кажется возьмите алгоритм окру, fr0ster (ok), 17:18 , 23-Июн-11, (53) Я и не спорю, что иногда это, к сожалению, нужно Речь была как раз о том, что в, PereresusNeVlezaetBuggy (ok), 17:21 , 23-Июн-11, (55) +1 Жаль только тривиальные случаи это вовремя не обнаруженные необычности Индусский, fr0ster (ok), 17:29 , 23-Июн-11, (60) +1 Дык на то голова программисту и дана, чтобы отличать одно от другого Чем прощ, PereresusNeVlezaetBuggy (ok), 17:34 , 23-Июн-11, (64) +1 Если архитектура запутанна, то медицина бессильна Весь код не может быть ясным , fr0ster (ok), 17:42 , 23-Июн-11, (66) Дык вы ж сами и привели примеры, когда внешние обстоятельства заставляют городит, PereresusNeVlezaetBuggy (ok), 21:23 , 23-Июн-11, (97) Как можно сравнивать прирост кода в старой 2001 XFS, с ее устоявшейся базой И , Sokoloff (?), 14:51 , 23-Июн-11, (23) // Форониксу - можно , Аноним (-), 15:23 , 23-Июн-11, (29) +4 крайний раз копался в коде btrfs с год назад, откомментирован он действительно о, fresco (ok), 15:59 , 23-Июн-11, (38) // Есть такой грешок за ними, факт С другой стороны когда 40 исходника это комент, Аноним (-), 17:49 , 23-Июн-11, (70) // много -- не мало, процентов 35, по опыту, в самый раз , fresco (ok), 21:48 , 23-Июн-11, (100) +1 Дедупликация ZFS уменьшит занимаемое ими место , iZEN (ok), 16:26 , 23-Июн-11, (40) // Неа Дедупликация ZFS действует только на блоки Очевидно, даже несколько идущих, Аноним (-), 17:12 , 23-Июн-11, (51) // это всё потому, что есть куча народу гордящегося_неимоверно новой цацкой, а не, ананим (?), 17:53 , 23-Июн-11, (71) –1 И давно она там есть Какой командой делается Ах, в виде патчей , Anon Y Mous (?), 09:15 , 24-Июн-11, (146) Сапожник Дедупликация ZFS не оперирует строками, она дисковыми блоками оперируе, Аноним (-), 17:54 , 23-Июн-11, (72) –2 // Что же с вами случилось, люуууудиии Сарказм уже воспринимают как личный наезд , iZEN (ok), 19:58 , 23-Июн-11, (87) –3 // Уж извини, не слежу за темой, но видать, заслужил ты имидж среди местного народа, crypt (??), 21:10 , 23-Июн-11, (94) +1 Да, кстати, был же этот товарищь от M со звучной фамилией Тот был еще прово, crypt (??), 21:14 , 23-Июн-11, (95) не только среди местного , anonymous (??), 23:47 , 23-Июн-11, (111) +1 iZEN умудряется сливать сразу на многих ресурсах, будучи наглядной иллюстрацией , Аноним (-), 12:46 , 24-Июн-11, (172) +1 пора тэг irony вводить, а то так понимать перестали , fresco (ok), 21:51 , 23-Июн-11, (101) +2 поратолько без поиска от витеньки, йопт (??), 11:12 , 24-Июн-11, (160) iZEN слишком толстый, ему этот тег не засчитают , Аноним (-), 12:47 , 24-Июн-11, (173) Инфляция , gegMOPO4 (ok), 22:52 , 23-Июн-11, (104) +1 Кто-нибудь в жизни её использует А то уж очень хочется неограниченного количест, IamthinkingaboutBTRFS (?), 16:41 , 23-Июн-11, (43) –1 // http ru wikipedia org wiki NILFS, iZEN (ok), 16:47 , 23-Июн-11, (44) +1 ZFS уже давно портировали на линакс, между прочим , Аноним (-), 17:13 , 23-Июн-11, (52) +1 Использую на нетбуке с 64 GB SSD с выхода убунты 10 10 по текущий момент Нескол, Frank (ok), 17:23 , 23-Июн-11, (57) Пробовал btrfs начиная с Ubuntu 10 10 с последующим апдейтом до 11 04, причем ос, Алексей Волков (?), 18:10 , 23-Июн-11, (76) +2 // Только если что - у zfs вообще fsck нет, даже в планах А у btrfs он пока поп, Аноним (-), 18:40 , 23-Июн-11, (82) –2   // zpool scrub poolname 8212 рассчитывает все контрольные суммы файлов и метадан, iZEN (ok), 19:08 , 23-Июн-11, (86) –1   Все это замечательно, но убитые метаданные не восстановит Так что действительно, Аноним (-), 20:37 , 23-Июн-11, (89)   Там оно и не нужно CoW, контрольные суммы и дублирование метаданных решают, а б, Мяут (ok), 23:49 , 23-Июн-11, (113) –1   адептам свойственно говорить, что то, чего у них в технологии нет, на самом деле, anonymous (??), 23:56 , 23-Июн-11, (114)   ZFS изначально проектировался, как надежная ФС, для которой бы не требовался fsc, Мяут (ok), 00:06 , 24-Июн-11, (115)   дык можно подумать, что та же винда изначально проектировалась как система, кот, anonymous (??), 00:09 , 24-Июн-11, (116)   Ну есть zdb если на то уж пошло А все фичи fsck типа определения сбойной ФС в Z, Мяут (ok), 00:47 , 24-Июн-11, (118)   Он может проверить все структуры на валидность и починить все что невалидно или , Аноним (-), 20:31 , 25-Июн-11, (206)   http www freebsd org cgi man cgi query zdbТо только эта цепочка и будет недост, iZEN (ok), 20:58 , 25-Июн-11, (207)   Можно вот рассказать, как это могло получиться, со ссылочками на on-disk format , Мяут (ok), 01:39 , 27-Июн-11, (221)   Да-да Сколько было излито желчи по поводу того, что ZFS - комбайн-все-в-одном-, Anon Y Mous (?), 09:19 , 24-Июн-11, (147)   Желчь была в основном потому что ZFSники утверждали что оно такое незаменимое Хо, Аноним (-), 00:26 , 25-Июн-11, (195)   От 2005 года данные, когда исходники ZFS открыли Сейчас количество строк кода в, Anon Y Mous (?), 09:23 , 24-Июн-11, (148)   Ага, вот вылезет у вас бэд так что ФС перестанет монтироваться, бэкап фигакс и с, Аноним (-), 00:18 , 25-Июн-11, (194)   Это у вас бэд приводит к немонтируемой ФС, у нас 4 копии метки на VDEV и 3 копии, Мяут (ok), 01:44 , 27-Июн-11, (222)   А зачем ему что-то восстанавливать Сама ZFS спроектирована по принципу CoW 82, iZEN (ok), 00:56 , 24-Июн-11, (120) +1   Малацца, основы CoW зазубрил Садись, пять И положи букварь на парту Только у , Аноним (-), 13:27 , 25-Июн-11, (198)   gt оверквотинг удален Матчасть подучи http blogs oracle com bonwick ru cate, iZEN (ok), 17:44 , 25-Июн-11, (202)   Это ты себе Как ты думаешь, к чему относилось про эффект домино CoW довольно ле, Аноним (-), 23:05 , 25-Июн-11, (208)   Наконец-то дошло Ты делаешь успехи А теперь прочти, что я написал РАНЕЕ про z, iZEN (ok), 00:44 , 26-Июн-11, (213)   Я -- да А Вы заканчивайте всё-таки свои чушебравады _Это_ как раз точно бессмы, Michael Shigorin (ok), 21:40 , 26-Июн-11, (220)   прежде чем что-то там восстанавливать пусть вначале на ней ПО нормально работать, ананим (?), 08:23 , 27-Июн-11, (234)   Включаешь либо избыточность по копиям параметром FS, либо делаешь зеркалирование, Аноним (-), 23:01 , 24-Июн-11, (188)   И какой командой мне сделать чтобы на моем ноуте у меня зазеркалировались все да, Аноним (-), 23:09 , 25-Июн-11, (209)   zfs set copies 2 tankДелает две копии данных и защищает от бедов, Мяут (ok), 01:49 , 27-Июн-11, (223)   конечно, не похоже унылые fsck традиционных ФС ещё и восстанавливать данные уме, anonymous (??), 23:49 , 23-Июн-11, (112)   Ага 8212 cкладывать горкой в lost-found неназванный мусор Чего ж до сих , iZEN (ok), 00:50 , 24-Июн-11, (119) –1   Проблема лишь в том что если все настолько плохо, том скорее всего совсем не смо, Аноним (-), 13:37 , 25-Июн-11, (199) +1   Да уж Унылый fsck по задумке еще и репайрит порушенные метаданные до более-мене, Аноним (-), 12:50 , 24-Июн-11, (174)   Увидь http compute cnr berkeley edu cgi-bin man-cgi zpool 1---zpool import -F, iZEN (ok), 15:51 , 24-Июн-11, (186)   И что в этой копипасте предлагается увидеть То что реализован аж целый один мет, Аноним (-), 13:42 , 25-Июн-11, (200)   Не поможет 8212 zdb в зубы и вперёд , iZEN (ok), 17:16 , 25-Июн-11, (201) –1   Лучше уж fsck, имхо Он большую часть типовых проблем чинит автоматически, а там, Аноним (-), 23:13 , 25-Июн-11, (210)   У него вопрос один Чинить или не чинить 8212 и то, файловую систему, а не, iZEN (ok), 07:58 , 26-Июн-11, (215)   Список типовых проблем, которые btrfsck чинит можно в студию А то как бы не ока, Anon Y Mous (?), 17:20 , 27-Июн-11, (238)   Да-да, ZFS нет никакой zfsc, а у btrfs есть А то, что этот чинящий что-то там b, Anon Y Mous (?), 09:29 , 24-Июн-11, (150) –1   Ну так научат, фигли Быстро только языком на форуме тарахтеть До тех пор никто, Аноним (-), 12:53 , 24-Июн-11, (175) +1   Странно Мне вот вот все равно, есть fsck или нет, ибо ее наличие дает разве чт, Anon Y Mous (?), 15:56 , 27-Июн-11, (236)   Кстати btrfsck уже научился исправлять ошибки , Аноним (-), 20:24 , 23-Июн-11, (88) +1 В этих 39 комментариев учтены стандартные заголовки файлов с указанием копирайт, gegMOPO4 (ok), 22:55 , 23-Июн-11, (106) 1,2,3,5,11,12,18,23,38,40,43,88,106

Сообщения

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

	82. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–2 +/–
	Сообщение от Аноним (-), 23-Июн-11, 18:40
	Только если что - у zfs вообще fsck нет, даже в планах ;). А у btrfs он пока попросту бесполезный т.к. сырой еще напрочь - его только сделали.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от iZEN (ok), 23-Июн-11, 19:08
	> Только если что - у zfs вообще fsck нет, даже в планах ;). zpool scrub poolname — рассчитывает все контрольные суммы файлов и метаданных и сверяет их с теми, что есть, выводит список запорченных файлов, если они есть. Выполняется в фоне, при перезапусках продолжает работу с того места ФС, где закончила в последний раз. Правда, не похоже на унылый fsck традиционных ФС? ;)
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 23-Июн-11, 20:37
	> zpool scrub poolname — рассчитывает все контрольные суммы файлов и метаданных и > сверяет их с теми, что есть, выводит список запорченных файлов, если > они есть. Выполняется в фоне, при перезапусках продолжает работу с того > места ФС, где закончила в последний раз. > Правда, не похоже на унылый fsck традиционных ФС? ;) Все это замечательно, но убитые метаданные не восстановит. Так что действительно, на fsck не тянет.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от Мяут (ok), 23-Июн-11, 23:49
	Там оно и не нужно. CoW, контрольные суммы и дублирование метаданных решают, а баги системы и fsck не починит. Кстати, сравнение кодовой базы UFS+SVM и ZFS: -------------------------------------------------   UFS: kernel= 46806   user= 40147   total= 86953   SVM: kernel= 75917   user=161984   total=237901 TOTAL: kernel=122723   user=202131   total=324854 -------------------------------------------------   ZFS: kernel= 50239   user= 21073   total= 71312 ------------------------------------------------- отсюда: http://blogs.oracle.com/eschrock/entry/ufs_svm_vs_zfs_code
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??), 23-Июн-11, 23:56
	> Там оно и не нужно. адептам свойственно говорить, что то, чего у них в технологии нет, на самом деле не нужно. как только кто-то это «ненужное» дописывает — оно сразу становится нужным, полезным и уберфичей.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok), 24-Июн-11, 00:06
	ZFS изначально проектировался, как надежная ФС, для которой бы не требовался fsck. Понятное дело, что это умозаключение всего лишь теоретическое.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??), 24-Июн-11, 00:09
	дык. можно подумать, что та же винда изначально проектировалась как система, которая будет падать. лучше иметь ненужную тулзу, чем не иметь нужной.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok), 24-Июн-11, 00:47
	Ну есть zdb если на то уж пошло. А все фичи fsck типа определения сбойной ФС в ZFS делаются на-лету, так что утверждать, что у ZFS нет аналога fsck я бы не стал :-) Например взять выделение блока. В ZFS используются т.н. space maps являющиеся по сути логами транзакций, равно как в каком-нить ext3 fsck будет искать блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. Во время же выделения мы проигрываем лог.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 20:31
	> Ну есть zdb если на то уж пошло. Он может проверить все структуры на валидность и починить все что невалидно или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то что уцелело? > А все фичи fsck типа определения сбойной ФС в ZFS делаются на-лету, > так что утверждать, что у ZFS нет аналога fsck я бы не стал :-) Сбой фс нынче обнаруживает любой приличный драйвер. Но проблема в том что чинить их он не умеет - не его епархия.. > блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. А теперь представьте себе что цепочка логов порушилась где-то в середине. Или метаданные описываюшие оную. > Во время же выделения мы проигрываем лог. Вы рассматриваете только простые сбои, которые должна обработать обычная логика журналирования. Тогда как fsck обычно пользуются лишь тогда, когда эта логика не смогла отработать как надо. Когда мы видим что дело дрянь и основной парашют не сработал - нервно сглатываем и дергаем запасной. А вы в вашем праве превращаться в лепешку, если вам так удобнее.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok), 25-Июн-11, 20:58
	>> Ну есть zdb если на то уж пошло. > Он может проверить все структуры на валидность и починить все что невалидно > или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то > что уцелело? http://www.freebsd.org/cgi/man.cgi?query=zdb >> блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. > А теперь представьте себе что цепочка логов порушилась где-то в середине. Или > метаданные описываюшие оную. То только эта цепочка и будет недоступна. >> Во время же выделения мы проигрываем лог. > Вы рассматриваете только простые сбои, которые должна обработать обычная логика журналирования. > Тогда как fsck обычно пользуются лишь тогда, когда эта логика не > смогла отработать как надо. В самом деле? https://osu.redhat.com/content/courses-ru/rha130-50-2-ru/tag... --- Использование команды fsck Команда fsck обычно вызывается с именем раздела, который нужно проверить, в качестве единственного параметра. Если команда fsck найдет ошибку, которую она сможет исправить без риска потери данных, она исправит ее. Если есть риск потери данных, команда fsck приостановится и выдаст сообщение с вопросом, должна ли она исправлять ошибку. Для администраторов, которые не обладают подробными знаниями в области внутренней структуры файловой системы ext2, выбор невелик. По правде говоря, команда fsck часто запускается с ключом -y, который так и говорит: "Не спрашивать, просто делать". --- > Когда мы видим что дело дрянь и основной парашют не сработал - нервно сглатываем и дергаем запасной. А он у вас есть? Бэкапы хотя бы сделали? :)) > А вы в вашем праве превращаться в лепешку, если вам так удобнее. У нас хотя бы мусор из-за бэд-блока на одном носителе можно достоверно обнаружить, а на группе носителей в RAID невозможен в принципе.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok), 27-Июн-11, 01:39
	> А теперь представьте себе что цепочка логов порушилась где-то в середине. Можно вот рассказать, как это могло получиться, со ссылочками на on-disk format? Есть подозрения что ФС пойдет через Traverse в поисках блоков. Ну или опять же поедет на старую неповрежденную версию лога. > Он может проверить все структуры на валидность и починить все что невалидно или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то что уцелело? Валидность структуры - это сущая эвристика. Уж лучше контрольные суммы и транзакционная модель.
	Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

	147. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous (?), 24-Июн-11, 09:19
	>> Там оно и не нужно. > адептам свойственно говорить, что то, чего у них в технологии нет, на > самом деле не нужно. как только кто-то это «ненужное» дописывает — > оно сразу становится нужным, полезным и уберфичей. Да-да.. Сколько было излито желчи по поводу того, что ZFS - комбайн-все-в-одном-и-ни-нужно, а теперь оказывается, что если комбайн-все-в-одном называется btrfs - то он внезапно уже оказывается нужен. Двойные стандарты такие двойные :)
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	195. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 00:26
	Желчь была в основном потому что ZFSники утверждали что оно такое незаменимое.Хотя по факту LVM и рэйды с обычной ФС поверх вполне могут похожее по функционалу изобралить, а удобство администрирования - вопрос вкуса и предпочтений. А btrfs нужен всем по разным причинам. Кому-то потому что CoW означает неразрушающую и быструю запись. Кому-то за эффективные снапшоты. Кому-то за управление томами. А кому-то за просто скорость. Btrfs не ударяет в грязь лицом даже на low end системах, вплоть до эмбеддовки. В отличие от ZFS, которому с его блочным дизайном и жуткой фрагментацией надо минимум несколько Гб оперативки чтобы нормально работать, а не тормозить. И в большинстве бенчей почему-то btrfs уже сто лет назад делал ZFS.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous (?), 24-Июн-11, 09:23
	> отсюда: http://blogs.oracle.com/eschrock/entry/ufs_svm_vs_zfs_code От 2005 года данные, когда исходники ZFS открыли. Сейчас количество строк кода в ядре - уже под сто тысяч. Но и функциональности прибавилось в сравнении с 2005.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	194. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 00:18
	> Там оно и не нужно. Ага, вот вылезет у вас бэд так что ФС перестанет монтироваться, бэкап фигакс и старый, а вон те файлики - позарез нужно. И будете вы пухнуть, разбирая по ночам навороченные структуры хексэдитором. Вместо того чтобы починиться стандартной утилитой.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	222. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok), 27-Июн-11, 01:44
	>> Там оно и не нужно. > Ага, вот вылезет у вас бэд так что ФС перестанет монтироваться, бэкап > фигакс и старый, а вон те файлики - позарез нужно. И > будете вы пухнуть, разбирая по ночам навороченные структуры хексэдитором. Вместо того > чтобы починиться стандартной утилитой. Это у вас бэд приводит к немонтируемой ФС, у нас 4 копии метки на VDEV и 3 копии метаданных.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от iZEN (ok), 24-Июн-11, 00:56
	>> zpool scrub poolname — рассчитывает все контрольные суммы файлов и метаданных и >> сверяет их с теми, что есть, выводит список запорченных файлов, если >> они есть. Выполняется в фоне, при перезапусках продолжает работу с того >> места ФС, где закончила в последний раз. > Все это замечательно, но убитые метаданные не восстановит. Так что действительно, на fsck не тянет. А зачем ему что-то восстанавливать? Сама ZFS спроектирована по принципу CoW — если что-то повреждается, то восстанавливается легко и непринуждённо откатом на предыдущее состояние, если ФС видит потерю данных на одной из половины зеркала, то не кричит об этом, а тихо восстанавливает данные по другой половине (то же самое с другими избыточными моделями хранения данных). Если данные не восстановимы в принципе, то пул тупо останавливает свою работу, чтобы предотвратить потерю консистентности метаданных самой файловой системы, а там уж администратор должен сам разобраться в проблеме — fsck на такое не способна, и ни один из линуксовых RAID не может в этом помочь: http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3...
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	198. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 13:27
	> А зачем ему что-то восстанавливать? Сама ZFS спроектирована по принципу CoW — > если что-то повреждается, то восстанавливается легко и непринуждённо откатом на > предыдущее состояние, Малацца, основы CoW зазубрил. Садись, пять. И положи букварь на парту. Только у данного устройства ФС есть проблема: относительно небольшое разрушение метаданных может вызывать очень невкусные последствия. Знаешь что такое "эффект домино"? Ну вот снапшоты - они друг за другом, как костяшки домино. Грохнется что-то в одном? Полетит все что было за ним. Потому что зависит от предшествующего куска. И уж хотя-бы перестроить метаданные в случае опы, например порушеный индекс на основе данных целого индекса - было бы очень кстати, не говоря уж про исправление заведомо некорректных метаданных/проблемных и прочая. > если ФС видит потерю данных на одной из половины зеркала, то не кричит об этом, > а тихо восстанавливает данные по другой половине (то же самое с другими > избыточными моделями хранения данных). При условии если это вообще получилось. Вообще-то, запасной парашют нужно дергать только если основной (стандартная журнальная механика) не сработал. Может быть до тебя это уже дойдет, двоечник? :) > Если данные не восстановимы в принципе, то пул тупо останавливает свою работу, Да. И далее ты или выгребаешь из него хексэдитором нужные файлы или клюешь. Как мило! > чтобы предотвратить потерю консистентности метаданных самой файловой системы, а там уж > администратор должен сам разобраться в проблеме — fsck на такое не способна, Администратору приводить метаданные в консистентное и непротиворечивое состояние "немного" сложнее и дольше чем утилитам. > и ни один из линуксовых RAID не может в этом помочь: А почему RAID должен помогать в починке метаданных ФС? Если ты вдруг не знал, RAID далеко не панацея и справляется далеко не с любыми сценариями разрушений. Кстати, даже лучшая конструкция парашюта очень редко но все-таки может не сработать. Поэтому изобрели запасные парашюты. > http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3... Тебя так прикалывает демонстрировать свою тупость?
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok), 25-Июн-11, 17:44
	>[оверквотинг удален] >> предыдущее состояние, > Малацца, основы CoW зазубрил. Садись, пять. И положи букварь на парту. Только > у данного устройства ФС есть проблема: относительно небольшое разрушение метаданных может > вызывать очень невкусные последствия. Знаешь что такое "эффект домино"? Ну вот > снапшоты - они друг за другом, как костяшки домино. Грохнется что-то > в одном? Полетит все что было за ним. Потому что зависит > от предшествующего куска. И уж хотя-бы перестроить метаданные в случае опы, > например порушеный индекс на основе данных целого индекса - было бы > очень кстати, не говоря уж про исправление заведомо некорректных метаданных/проблемных > и прочая. Матчасть подучи: http://blogs.oracle.com/bonwick/ru/category/ZFS --- Нисходящее восстановление: пул дисковой памяти - это дерево блоков. Чем ближе к корню дерева находится блок, тем значительнее его потеря, так как она означает потерю доступа к во всем потомкам этого блока. Использование метаданных позволяет ZFS осуществлять нисходящее восстановление избыточности. Это значит, что в первую очередь ZFS восстановит убер-блок и метки диска. Затем будет восстановлена избыточность метаданных, общих для всего пула; затем метаданных каждой файловой системы; и так далее вниз по дереву. В ходе этого процесса ZFS следует такому правилу: ибыточность блока не восстанавливается до тех пор, пока не восстановлена избыточность всех его предков. Трудно преувеличить важность этого правила. При прямолинейном копировании всего диска, даже если успешно скопировано 99%, есть неплохой шанс, что один из верхних блоков дерева еще не скопирован. С точки зрения среднего времени восстановления после отказа (MTTR) это значит, что прогресса нет: отказ или ошибка второго диска в этот момент времени все еще будет иметь катастрофические последствия. При нисходящем восстановлении избыточности, копирование каждого следующего блока увеличивает количество данных, которые могут быть обнаружены. В случае сбоя еще одного диска, все данные, избыточность которых была восстановлена до этого момента, останутся доступными. --- >> если ФС видит потерю данных на одной из половины зеркала, то не кричит об этом, >> а тихо восстанавливает данные по другой половине (то же самое с другими >> избыточными моделями хранения данных). > При условии если это вообще получилось. Вообще-то, запасной парашют нужно дергать только > если основной (стандартная журнальная механика) не сработал. Может быть до тебя > это уже дойдет, двоечник? :) Вообще-то, "запасной парашют" в ZFS всегда на готове и он готов для дёрганья в тот момент, когда основной отвалился, а не когда мы уже на земле. --- ZFS использует сквозные контрольные суммы для выявления и исправления неявных нарушений целостности данных. Если диск возвращает некорректные данные в результате случайного сбоя, ZFS определит это и попытается прочитать данные еще раз. Если диск является частью "зеркала" или RAID-Z, ZFS не только определит, но и исправит ошибку: контрольная сумма позволит определить правильную копию, предоставить корректные данные приложению и исправить с их помощью поврежденную копию. --- >> Если данные не восстановимы в принципе, то пул тупо останавливает свою работу, > Да. И далее ты или выгребаешь из него хексэдитором нужные файлы или клюешь. Как мило! Опять двадцать пять. Начинай сначала. >> чтобы предотвратить потерю консистентности метаданных самой файловой системы, а там уж >> администратор должен сам разобраться в проблеме — fsck на такое не способна, > Администратору приводить метаданные в консистентное и непротиворечивое состояние "немного" > сложнее и дольше чем утилитам. Правда что ли? Неужели пробовал восстанавливать RAID из состояния FAULTED, чтобы это говорить? На mdraid это вообще бессмысленно. >> и ни один из линуксовых RAID не может в этом помочь: > А почему RAID должен помогать в починке метаданных ФС? А почему нет, если он интегрирован с ФС? > Если ты вдруг не знал, RAID далеко не панацея и справляется далеко не с любыми сценариями разрушений. Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :)) > Кстати, даже лучшая конструкция парашюта очень редко но > все-таки может не сработать. Поэтому изобрели запасные парашюты. >> http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3... > Тебя так прикалывает демонстрировать свою тупость? Почему свою? Это ваша тупость, данная вам в ощущениях.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 23:05
	> Матчасть подучи: http://blogs.oracle.com/bonwick/ru/category/ZFS Это ты себе? > Нисходящее восстановление: пул дисковой памяти - это дерево блоков. Чем ближе к > корню дерева находится блок, тем значительнее его потеря, Как ты думаешь, к чему относилось про эффект домино? CoW довольно легко повреждается и повреждения даже небольшого участка метаданных или данных могут выбить довольно много всего в результате. Потому что текущий вид данных зависит от предыдущего. > Использование метаданных позволяет ZFS осуществлять нисходящее восстановление избыточности. Тут делается вольное допущение что избыточность есть, что это удалось и что нигде не облажались. В реальной жизни таких гарантий даже страховой полис не даст. [копипаст из букваря поскипан] В общем это, копипастить и дурак может. > Вообще-то, "запасной парашют" в ZFS всегда на готове и он готов для > дёрганья в тот момент, когда основной отвалился, а не когда мы уже на земле. И что является парашютом заменяющим fsck? Те несколько хиленьких опций утилиток, затыкающих несколько специфичных сценариев и плевать хотевших на все остальные? Это не парашют, это бутафория какая-то. В упомянутом букваре допускается что избыточность - была, что перестроение дупов прошло успешно и что валидная копия метаданных вообще была. Но зато ни звука про случай когда их не было. И если в крутых энтерпрайзных многодисковых хранилищах еще можно в некоторых случаях надеяться что это будет не настолько уж и неправдой, для более простых юзкейсов вида "один винч на ноуте, и тот осыпался" это как-то очень неубедительно уже смотрится. Ах, я и забыл - сани делали ФС только для энтерпрайзов. Поэтому такие юзкейсы они не рассматривали и вы для этого используете окаменелый UFS. А вот для btrfs это вполне валидная ситуация. Не просто заранее заложенная, а дефолтная для meego на x86. Негде в ноуте или планшетке многодисковое хранилище распихать. > является частью "зеркала" или RAID-Z, ZFS не только определит, но и > исправит ошибку: контрольная сумма позволит определить правильную копию, Покажи мне как сделать эффективное "зеркало" из одного диска в моем ноуте? Или по твоему мнению я там должен использовать окаменелости типа UFS? Ну увидит ФС - ага, том сыпанулся, бэд чексум. Дальше - что? > Опять двадцать пять. Начинай сначала. Ну так я не виноват что ты тугой и до тебя медленно доходит: вполне возможна ситуация, когда диск был 1, на нем хаотично вылезли бэды например. Это типичный десктопно-ноутбучный юзер. Все что сможет ФС - констатировать bad checksum. А восстановить это - не сможет. И хорошо бы юзеру собрать то что от тома осталось и отрепайрить до моунтабельного состояния, чтобы он не упирался, выколупывая останки файлов хексэдитором. Да, некоторые файлы могут быть испорчены. Хорошо если ФС или fsck их как-то пометит как таковые. Но выцепить то что осталось с тома проще всего когда он примонтирован, копированием. Для этого том должен быть доведен до моунтабельного состояния. Утилитой-чекером. > Правда что ли? Неужели пробовал восстанавливать RAID из состояния FAULTED, чтобы это > говорить? На mdraid это вообще бессмысленно. Пробовал и могу сказать что это та еще лотерея. Более того - иногда RAID может так "восстановить" данные что потом вообще костей не соберешь. Кстати, а расскажи, как мне RAID в ноуте забабахать, если там чисто физически место для 1 HDD и более нишиша? >> А почему RAID должен помогать в починке метаданных ФС? > А почему нет, если он интегрирован с ФС? Да хотя-бы потому что RAIDить может быть и некуда. Ну понятное дело что ZFS не ориентирован на мелкие инсталляции "перец с ноутом", все что они смогут сказать - "сам дурак". А вот btrfs очень даже ориентирован на такое применение. Поэтому там не катит говорить "сам дурак". Там чинить придется, а потребовать пять дисков для рэйда - не катит. > Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :)) Просто btrfs рассчитан на немного более широкие сценарии, в частности и на ноуты там всякие, где разместить многодисковый рэйд попросту негде. Так что неизбежно придется отколупывать юзверям их диски из весьма неприглядного состояния и скорее всего не имея зеркальной копии всех метаданных. > Почему свою? Это ваша тупость, данная вам в ощущениях. Мои ощущения говорят мне что мой ноут с 1 диском как-то сложно сделать осмысленным RAIDом.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok), 26-Июн-11, 00:44
	>> Опять двадцать пять. Начинай сначала. > Ну так я не виноват что ты тугой и до тебя медленно > доходит: вполне возможна ситуация, когда диск был 1, на нем хаотично > вылезли бэды например. Это типичный десктопно-ноутбучный юзер. Все что сможет ФС > - констатировать bad checksum. А восстановить это - не сможет. Наконец-то дошло! Ты делаешь успехи. А теперь прочти, что я написал РАНЕЕ про "zpool scrub poolname", что в результате его работы мы имеем. Не трудись: список повреждённых файлов с полными путями. Для вашего fsck, запускаемого по дефолту как "fsck -y", возможна только файло-помойка в каталоге /lost+found. > И > хорошо бы юзеру собрать то что от тома осталось и отрепайрить > до моунтабельного состояния, чтобы он не упирался, выколупывая останки файлов хексэдитором. Дело в том, что scrub обозначает повреждённые файлы и одновременно производит очистку ФС. И ФС после его работы считается де-факто в консистентном состоянии (свойство CoW + очистка scrub). Выколупывать какие-то ошмётки после scrub, конечно можно, они будут либо полностью отсутствовать, либо находиться по тем же путям, что и ранее имевшиеся файлы, даже имена файлов будут те же, но это уже будут не "те данные" — доставай из бэкапов, чуда не будет. --- Для сведения к минимуму риска повреждения данных в ZFS применяется расчет контрольной суммы, обеспечение избыточности данных и их самовосстановление. Тем не менее, повреждение данных может происходить в том случае, если пул не является избыточным, при повреждении во время нахождения пула в состоянии DEGRADED или в результате ряда маловероятных событий, приводящих к повреждению нескольких копий фрагмента данных. Вне зависимости от причины, результат одинаков: данные повреждены и, следовательно, недоступны. Предпринимаемое действие зависит от типа поврежденных данных и их относительной значимости. Возможно повреждение двух основных типов данных: * Метаданные пула – ZFS требует некоторых данных для открытия пула и обращения к наборам данных. При повреждении этих данных весь пул или целые ветви иерархии набора данных становятся недоступными. * Данные объектов – в этом случае повреждение происходит в рамках определенного файла или каталога. Эта проблема может привести к тому, что часть файла или каталога становится недоступной, или объект может оказаться полностью неработоспособным. Данные проверяются в нормальном режиме работы, а также в процессе очистки. --- Всё равно: в случае с ZFS у нас на руках список повреждённых/отсутствующих файлов ("zpool status -v"), а вслучае fsck —  сваленные в кучу "какие-то" ошмётки неизвестно чего в /lost+found. Вот и догадайся в последнем случае, что это было и что именно нужно восстановить. > Да, некоторые файлы могут быть испорчены. Хорошо если ФС или fsck > их как-то пометит как таковые. Но выцепить то что осталось с > тома проще всего когда он примонтирован, копированием. Для этого том должен > быть доведен до моунтабельного состояния. Утилитой-чекером. Ещё раз: "zpool import -F poolname" — импортирует полностью убитый (FAULTED) пул, если есть хоть малейшая надежда хоть что-то с него выцепить. fsck традиционных ФС в таких же случаях ничего не может предпринять кроме разрушения пользовательских данных ради приведения в порядок структуры ФС. > Кстати, а расскажи, как мне RAID в ноуте забабахать, если там чисто физически место для 1 HDD и более нишиша? В некоторых ноутбуках от SONY есть место для двух 2,5" HDD. Сам подумай, как можно сделать из них mirror. В обычных ноутбуках, как правило, место только для одного HDD/SSD. Тут уж не до избыточности, а вот верифицируемость данных важна, особенно на ненадёжных MLC SSD. >>> А почему RAID должен помогать в починке метаданных ФС? >> А почему нет, если он интегрирован с ФС? > Да хотя-бы потому что RAIDить может быть и некуда. Ну понятное дело > что ZFS не ориентирован на мелкие инсталляции "перец с ноутом", все > что они смогут сказать - "сам дурак". В настоящий момент я бы не отказался от ZFS на ноутбуке, у которого минимум 4 ГБ ОЗУ и процессор уровня двухъядерного AMD Athlon II 2 ГГц. Всё, что не слабее этой аппартаной конфигурации, должно довольствоваться UFS2 с Soft Updates или NTFS, но никак не динуксовыми ФС, теряющими данные на ровном месте. > А вот btrfs очень > даже ориентирован на такое применение. Поэтому там не катит говорить "сам > дурак". Там чинить придется, а потребовать пять дисков для рэйда - > не катит. Btrfs для высоких уровней RAID использует средства mdadm. До сих пор нет поддержки нативной реализации RAID-5. Только недавно в GRUB2 обеспечили возможность загрузки с Btrfs. Что ещё можно обсуждать? >> Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :)) > Просто btrfs рассчитан на немного более широкие сценарии, в частности и на > ноуты там всякие, где разместить многодисковый рэйд попросту негде. Так что > неизбежно придется отколупывать юзверям их диски из весьма неприглядного состояния и > скорее всего не имея зеркальной копии всех метаданных. >> Почему свою? Это ваша тупость, данная вам в ощущениях. > Мои ощущения говорят мне что мой ноут с 1 диском как-то сложно сделать осмысленным RAIDом. Вперёд, читать про восстановление ZFS после сбоев: http://download.oracle.com/docs/cd/E19253-01/820-0836/gavwg/...
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok), 26-Июн-11, 21:40
	> Правда что ли? Неужели пробовал восстанавливать RAID из состояния FAULTED, > чтобы это говорить? Я -- да. > На mdraid это вообще бессмысленно. А Вы заканчивайте всё-таки свои чушебравады.  _Это_ как раз точно бессмысленно.
	Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

	234. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим (?), 27-Июн-11, 08:23
	прежде чем что-то там восстанавливать пусть вначале на ней ПО нормально работать начнёт. А то для примеру тот-же нжинкс до сих пор рекомендует её только для экстремалов. В отличие от кстати.
	Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

	188. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 24-Июн-11, 23:01
	Включаешь либо избыточность по копиям параметром FS, либо делаешь зеркалирование одной командой. Законы сохранения и мануалы для тебя не писаны? Веришь в Деда Мороза?
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	209. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 23:09
	> Включаешь либо избыточность по копиям параметром FS, либо делаешь зеркалирование одной > командой. И какой командой мне сделать чтобы на моем ноуте у меня зазеркалировались все данные+метаданные? Это что-то из разряда магии? :)
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok), 27-Июн-11, 01:49
	# zfs set copies=2 tank Делает две копии данных и защищает от бедов
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??), 23-Июн-11, 23:49
	> Правда, не похоже на унылый fsck традиционных ФС? ;) конечно, не похоже: унылые fsck традиционных ФС ещё и восстанавливать данные умеют. а проверку чексум написать — дело нехитрое.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	119. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от iZEN (ok), 24-Июн-11, 00:50
	>> Правда, не похоже на унылый fsck традиционных ФС? ;) > конечно, не похоже: унылые fsck традиционных ФС ещё и восстанавливать данные умеют. Ага — cкладывать горкой в .lost-found неназванный мусор. :)) > а проверку чексум написать — дело нехитрое. Чего ж до сих пор не написали, чтобы fsck для традиционной ФС выводил полный список повреждённых файлов, а не молчком складировал "чего-то найденное, опознанное как файлы" в .lost-found?
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (-), 25-Июн-11, 13:37
	> Ага — cкладывать горкой в .lost-found неназванный мусор. :)) Проблема лишь в том что если все настолько плохо, том скорее всего совсем не смонтируется или не протянет долго будучи примонтированным, так что без fsck в той же ситуации ты сам будешь этот мусор еще и собирать хексэдитором со всех закоулков диска, лично парся дисковые структуры. Что и можно понаблюдать где-то типа http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ - это еще повезло, все было легко и очевидно. Могло быть гораздо хуже, как то бэд где-то посередине диска. > Чего ж до сих пор не написали, чтобы fsck для традиционной ФС > выводил полный список повреждённых файлов, а не молчком складировал "чего-то найденное, > опознанное как файлы" в .lost-found? Наверное, потому что удалось опознать нечто как похожее на файл, но не удалось понять кому оно принадлежало? Или ты как наивный чукотский юноша думаешь, что в lost+found файлы складывают чтобы пользователю насолить? :)
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 24-Июн-11, 12:50
	> Правда, не похоже на унылый fsck традиционных ФС? ;) Да уж. Унылый fsck по задумке еще и репайрит порушенные метаданные до более-менее моунтабельного состояния. Чтобы структуры (то что от них уцелело) разбирал бы все-таки драйвер ФС а не юзверь с хексэдитором. Потому что второй вариант "немного" сложнее и медленнее. А у вас я такой задумки не вижу. И что-то мне не нравится перспектива пересобирать 100500 гиговый пул если умерло всего 2 несущественных файла на 5Кб.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	186. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok), 24-Июн-11, 15:51
	>> Правда, не похоже на унылый fsck традиционных ФС? ;) > Да уж. Унылый fsck по задумке еще и репайрит порушенные метаданные до > более-менее моунтабельного состояния. Чтобы структуры (то что от них уцелело) разбирал > бы все-таки драйвер ФС а не юзверь с хексэдитором. Потому что > второй вариант "немного" сложнее и медленнее. А у вас я такой > задумки не вижу. Увидь: http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?zpool+1 --- zpool import -F poolname -F              Recovery mode for a non-importable pool. Attempt  to              return the pool to an importable state by discarding              the last few transactions. Not all damaged pools can              be  recovered  by  using this option. If successful,              the data from the discarded  transactions  is  irre-              trievably  lost.  This option is ignored if the pool              is importable or already imported. Example 15 Recovering a Faulted ZFS Pool      If a pool is faulted but recoverable, a  message  indicating      this  state  is  provided  by  zpool  status if the pool was      cached (see cachefile above), or as part of the error output      from a failed zpool import of the pool.      Recover a cached pool with the zpool clear command:        # zpool clear -F data        Pool data returned to its state as of Tue Sep 08 13:23:35 2009.        Discarded approximately 29 seconds of transactions.      If the pool configuration was not cached, use  zpool  import      with the recovery mode flag:        # zpool import -F data        Pool data returned to its state as of Tue Sep 08 13:23:35 2009.        Discarded approximately 29 seconds of transactions. ---
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 13:42
	И что в этой копипасте предлагается увидеть? То что реализован аж целый один метод рекавери для целой одной ситуации когда что-то пошло не так в самых последних транзакциях? Дык это не аналог fsck, это костылик для одной конкретной ситуации. Те же бэдсектора вовсе не давали обязательств попадать только в последние транзакции, а не куда-то в середину. А откатывать полтома в вид каким оно было 2 месяца назад - как-то уже не то.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от iZEN (ok), 25-Июн-11, 17:16
	> И что в этой копипасте предлагается увидеть? То что реализован аж целый > один метод рекавери для целой одной ситуации когда что-то пошло не > так в самых последних транзакциях? Не поможет — zdb в зубы и вперёд.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (-), 25-Июн-11, 23:13
	> Не поможет — zdb в зубы и вперёд. Лучше уж fsck, имхо. Он большую часть типовых проблем чинит автоматически, а там где это невозможно - запрашивает пользователя что ему сделать.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok), 26-Июн-11, 07:58
	> запрашивает пользователя что ему сделать. У него вопрос один: "Чинить или не чинить?" — и то, файловую систему, а не файлы (файлы ему как-то похеру).
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous (?), 27-Июн-11, 17:20
	>> Не поможет — zdb в зубы и вперёд. > Лучше уж fsck, имхо. Он большую часть типовых проблем чинит автоматически, а Список типовых проблем, которые btrfsck чинит можно в студию? А то как бы не оказалось, что все что он делает - это аналог 'zpool import -F'.. > там где это невозможно - запрашивает пользователя что ему сделать. Ну-ну - вы уж определитесь, толи fsck для пользователя, толи пользователь для fsck :)
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	150. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от Anon Y Mous (?), 24-Июн-11, 09:29
	> А у btrfs он пока попросту бесполезный т.к. сырой еще напрочь - его только сделали. Да-да, ZFS нет никакой zfsc, а у btrfs есть. А то, что этот чинящий что-то там btrfsck никто еще толком не видел, и что он там умеет чинить никто не знает - это фигня, главное команда такая есть :) У btrfs был шанс - ровно до тех пор, пока не начали делать fsck. Теперь вместо тестирования файловой системы чуваки занимаются тестированием fsck: https://fedorahosted.org/fesco/ticket/594#comment:2 > Recovery strategy - A fsck tool is almost ready, part of the reason it is taking so long is it is being very well > tested, so when it does ship it will have been run through several hundred broken fs's to make sure it works > properly. Теперь ее участь - корневая ФС на крохотных раздельчиках, не более :)
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	175. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (-), 24-Июн-11, 12:53
	> что он там умеет чинить никто не знает - это фигня, > главное команда такая есть :) Ну так научат, фигли. Быстро только языком на форуме тарахтеть. > У btrfs был шанс - ровно до тех пор, пока не начали делать fsck. До тех пор никто ее на серверах и десктопах всерьез рассматривать даже не стал бы. > Теперь вместо тестирования файловой системы чуваки занимаются тестированием > fsck: https://fedorahosted.org/fesco/ticket/594#comment:2 Жирно слишком. Ченжлоги к кернелу не подтверждают ваш тезис. А fsck тоже тестировать надо - мы хотим возможность отремонтировать ФС даже если оно все-таки каким-то чудом навернется. > Теперь ее участь - корневая ФС на крохотных раздельчиках, не более :) Я бы сказал, "она будет работать в том числе и на крохотных раздельчиках". Спасибо Шишкину и Ко..
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous (?), 27-Июн-11, 15:56
	> До тех пор никто ее на серверах и десктопах всерьез рассматривать даже не стал бы. Странно. Мне вот  вот все равно, есть fsck или нет, ибо ее наличие дает разве что возможность бездарно потерять еще кучу времени с непредсказуемым результатом, вместо того начать восстанавливаться из бэкапа. Вот отсутствие аналога ztest для btrfs - это гораздо хуже. Хотя может я отстал от жизни и аналог таки уже есть. > Жирно слишком. Ченжлоги к кернелу не подтверждают ваш тезис. Жирно слишком у тебя в черепной коробке, все мозги жиром заплыли :) >> Теперь ее участь - корневая ФС на крохотных раздельчиках, не более :) > Я бы сказал, "она будет работать в том числе и на крохотных раздельчиках". Спасибо Шишкину и Ко.. Речь о том, что для ФС размером в сотни терабайт и больше время fsck становится неприлично большим, так что есть она или нет - не так важно. Важно то, что вместо нормального тестирования самой ФС ребята занимаются ерундой и тестируют fsck. А наличие fsck развращает - всегда есть воcпользоваться fsck чтобы "восстановить хоть что-то", вместо того, чтобы разобраться, что же собственно не так. И при ее наличии устоять против этого соблазна будет ой как непросто. Поэтому я и говорю, у btrfs  был шанс стать системой для ФС любых объемов - от крохотных до огромных. А так остаются только крохотные, где fsck сможет отработать за разумное время, да и там, как показал Шишкин, есть проблемы :)
	Ответить | Правка | Наверх | Cообщить модератору

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

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