forum.opennet.ru

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

Оглавление

Для Ext4 представлена поддержка контрольных сумм для проверк..., opennews (??), 02-Июн-12, (0) [смотреть все]

А производительность на сколько просядет , Аноним (-), 11:25 , 02-Июн-12, (1) +3 //

не идиоты же пишут, там куча реализаций крк32 под разные процессорные возможност, ВовкаОсиист (ok), 11:29 , 02-Июн-12, (2) +3
видимо в зависимости от проца, я надеюсь он догадался поюзать все современные оп, Анонимус_б6 (?), 11:29 , 02-Июн-12, (3) //

в ядре фантазёр, Аноним (-), 12:05 , 02-Июн-12, (7) –14 //

Да В ядре Достаточно посмотреть его исходники Или хотя бы 1 раз его собрать са, ананим (?), 13:04 , 02-Июн-12, (13)
В каком месте это вообще здесь уперлось На микро экзо нано ядрах нет файловой п, BratSinot (?), 16:45 , 02-Июн-12, (28)

Там счет crc32 покажется ерундой на фоне постоянного переключения контесктов , Аноним (-), 17:03 , 02-Июн-12, (31) +3

Отдельный сервер для расчёта CRC-32, да , Аноним (-), 17:34 , 02-Июн-12, (36) +2
Я бы лучше и не ответил , ананим (?), 18:36 , 02-Июн-12, (48)
А разве такое выносится в отдельный процесс Просто будет библиотека, оптимизиро, Аноним (-), 21:21 , 02-Июн-12, (73)

Вы вообще понимаете что говорите Где статическая да и любая другая линковка и , ананим (?), 21:39 , 02-Июн-12, (74)

цитата Зубинского в контексте микторядра MINIX 3 За всякое улучшение надо п, Voviandr (??), 23:43 , 02-Июн-12, (94) +1

Да забодали вы с вашими сферическими конями в вакууме Сделайте практическую реа, Аноним (-), 00:59 , 04-Июн-12, (141) +3

вы выдвигаете тезис, что мои утверждения про полпроцента необоснованны, так как , Voviandr (??), 02:01 , 04-Июн-12, (160) +1

У меня есть валидное оправдание я на уровне инженерной интуиции вполне могу пре, Аноним (-), 02:29 , 04-Июн-12, (166) –2

Куча профильных ошибок для специалиста если вы специалист В том то и дело что , ананим (?), 18:58 , 02-Июн-12, (52) +1

В пингвине к счастью никто не страдает настолько упоротой некромансией чтобы исп, Аноним (-), 22:42 , 02-Июн-12, (87)

Для вас это будет сюрпризом, но в библиотеке Glibc, которая используется почти в, Аноним (-), 09:31 , 03-Июн-12, (106) +2

Да хоть бы XOR по дефолту Что это меняет , filosofem (ok), 12:54 , 03-Июн-12, (111) –1
ещё бы ведь это ложь Dhttp www gnu org software libc manual html_node crypt, ананим (?), 13:07 , 03-Июн-12, (112) –1

Не вырывайте из контекста, а читайте дальше где написано, что по дефолту DES, а , Аноним (-), 23:27 , 03-Июн-12, (140)

Ок Я не буду вырывать , а вы научитесь читать Нет никакого дефолта Есть переме, ананим (?), 09:42 , 04-Июн-12, (177)

А причём тут glibc если crypt с DES это стандарт POSIX glibc наоборот добавляет, Аноним (-), 22:11 , 03-Июн-12, (130) +2

При том, что аноним выше ухмылялся про DES во FreeBSD, в то время как crypt и в , Аноним (-), 23:19 , 03-Июн-12, (139)

Какой в попу дефолт Салт нужен в любом случае И это первое Второе 8212 какое, ананим (?), 09:37 , 04-Июн-12, (176)

Осталось найти хоть 1 пароль в современном пингвине зашифрованный именно так , Аноним (-), 01:00 , 04-Июн-12, (142)

Вообще-то надо найти впингвине хоть один вызов не умеющий многобайтовые символы , ананим (?), 11:06 , 04-Июн-12, (183)

устаревшее барахло это grep в linux , Аноним (-), 20:50 , 05-Июн-12, (207)

Мимо 8212 http www opennet ru opennews art shtml num 25926ЗыжКакое отношени, ананим (?), 07:17 , 06-Июн-12, (211)
пример поиска в utf8 для grep-2 9 wget -O - http opennet ru 2 1 124 iconv , ананим (?), 07:30 , 06-Июн-12, (212)

В пределах погрешности, Аноним (-), 11:35 , 02-Июн-12, (4)
не должно просесть, здесь запись на диск намного тормознее вычисления crc, Аноним (-), 12:04 , 02-Июн-12, (6) +1 //

Диски уже не покупают , pavlinux (ok), 14:56 , 02-Июн-12, (16) –1 //

А что покупают SSD , анон (?), 15:28 , 02-Июн-12, (22)

Примерно так На механические диски цены после наводнения в тайване довольно кон, Аноним (-), 17:32 , 02-Июн-12, (35)

А как быть с большими объемами Цены на SSD все еще довольно высокие Цены на HDD, анон (?), 17:39 , 02-Июн-12, (39)

Ну вот и выбираем между конскими ценами и еще более конскими , Аноним (-), 04:58 , 04-Июн-12, (174)

угу админ локал хоста замечен А что бы данный админ сказал о raid6 который имее, Аноним (-), 14:58 , 02-Июн-12, (17) //

А у меня дома RAID 60 на SAS SSD c суммарной записью 12Gb s, или мне это присни, pavlinux (ok), 15:05 , 02-Июн-12, (19) –1

а без SSD получить столько , Аноним (-), 12:03 , 03-Июн-12, (107)

Конечно нет, да и с SSD столько не получишь, это ж маркетинг, как и 6Gb s и 3Gb , pavlinux (ok), 01:01 , 04-Июн-12, (143)

В моем случае увы не маркетинг А реальная стойка с винтами - нечто типа того чт, Аноним (-), 01:26 , 04-Июн-12, (146)

Давай скрины iozone -a - u -p -B -e -E А то эти SANы NASы - типа кэшуруют , а, pavlinux (ok), 13:39 , 04-Июн-12, (186) +1

сам ты жертва маркетинга Некоторые подобные железки собирают , Аноним (-), 17:54 , 04-Июн-12, (189)

Если начальник не жмот, там и процы должны быть соответствующие , Аноним (-), 16:59 , 02-Июн-12, (30) +1

начальник не жмот - но вот в чем проблема - подсчет crc32 от такого потока - съе, Аноним (-), 12:06 , 03-Июн-12, (108)

А че за железка такая, у которой скорость рандомной записи на raid 6 сравнима со, filosofem (ok), 13:07 , 03-Июн-12, (113)

Можно сказать самосбор - аналоичный тому что продает NETAP только у NETAP наруж, Аноним (-), 09:54 , 04-Июн-12, (179)

По моему, в новости написано о том, что будет У вас, наверное реализовано что-то, XoRe (ok), 18:48 , 03-Июн-12, (126)

У нас другое - но хорошо показывает использования CPU на больших потоках данных,, Аноним (-), 09:52 , 04-Июн-12, (178)

А у вас проверяются данные, или мета данные Наверное, у вас данные - тогда понят, XoRe (ok), 17:56 , 04-Июн-12, (190)

Проверяется все Но если для данных - это выльется в загрузку CPU, то для метада, Аноним (-), 11:57 , 05-Июн-12, (201)

Просто вы написали подсчет crc32 от такого потока - съедает 4 ядра и 12 Вы нев, XoRe (ok), 22:54 , 08-Июн-12, (213)

Кстати в догонку - лучше бы сделали поддержку T10 DIF DIX Хотя бы половина зада, Аноним (-), 10:01 , 04-Июн-12, (181)

Ну, положим не ГБ, а Гб Предполагаю, что сие можно будет отключить, когда оно, XoRe (ok), 18:48 , 03-Июн-12, (125)

Ну допустим именно 3ГБ с - 4 контролера на 6 Gb s и backplane на 24 sas диска , Аноним (-), 01:28 , 04-Июн-12, (147)

А если pci-e ssd взять , Аноним (-), 17:04 , 02-Июн-12, (32) +1 //

вы все здесь какие-то все упоротые собрались У какого-то придурка там рейд выда, Аноним (-), 19:45 , 02-Июн-12, (55) +9

на каждую операцию операцию с диском приходится ровно одна операция с MD видимо , Аноним (-), 12:08 , 03-Июн-12, (109)

Насчет упоротых соглашусь с предыдущим Анонимом , filosofem (ok), 13:17 , 03-Июн-12, (114)
Месье, как я понимаю, в отличие от Вас, знал, что не при каждом обращении к файл, Yakov Markovitch (?), 16:40 , 03-Июн-12, (122) +1

gt оверквотинг удален Упроотые это все тестировали и писали реализаю этого ког, Аноним (-), 01:35 , 04-Июн-12, (150) –1

gt оверквотинг удален ах да, забыл - когда у тебя один raid 5,6 тогда io AT д, Аноним (-), 09:56 , 04-Июн-12, (180)
gt оверквотинг удален 1 relatime _является_ опцией по умолчанию, на всякий с, Yakov Markovitch (?), 15:07 , 04-Июн-12, (188)

gt оверквотинг удален welcome to HPC world пример - Cray acceptance testing п, Аноним (-), 17:59 , 04-Июн-12, (191)

30MB s OK, согласен, пишем на каждую операцию по странице - 120MB c 20 нагруз, Yakov Markovitch (?), 19:59 , 04-Июн-12, (192) +1

вы твердо уверены что MD операции могут выполняться паралельно в одной директори, Аноним (-), 12:07 , 05-Июн-12, (203)

знаешь что я тоже могу сейчас у себя на локалхосте написать быдлокод и заявить, all_glory_to_the_hypnotoad (ok), 23:32 , 04-Июн-12, (195)

Обратитесь в подразделение Cray за обоснованием этих цифр , Аноним (-), 11:58 , 05-Июн-12, (202)

ах да, требуемые 15к unlink s это для кластера BlueWaters - TOP7 если склероз не, Аноним (-), 19:30 , 05-Июн-12, (206)

Ты откуда вылез ext уже лет 5 как монтируется по умолчанию с relatime, Аноним (-), 22:14 , 03-Июн-12, (131)

А мы виноваты что технологии - вот они Пошел в магазин да купил Упоротый - это, Аноним (-), 01:03 , 04-Июн-12, (144) –1

Я, честно говоря, свосем не понял вашего вопроса А именно что вы там в магазине, all_glory_to_the_hypnotoad (ok), 23:38 , 04-Июн-12, (196) +2

И как оно будет работать Ну вырубися у меня комп во время записи, файл не запис, Аноним (-), 11:53 , 02-Июн-12, (5) //

Ну ёбни по диску кувалдой во время записи и проверь что будет CRC используютс, pavlinux (ok), 15:00 , 02-Июн-12, (18) //

здесь 8212 метаданных, Аноним (-), 17:35 , 02-Июн-12, (37) //

псевдо-, мета-, квази-, суб-, в общем данных , pavlinux (ok), 20:35 , 02-Июн-12, (64) –1

Сохранность данных во время операций записи, связанная со сбоями оборудования, н, анон (?), 15:22 , 02-Июн-12, (21) //

В т ч забота ФС Журналирование - попытка решить эту проблему Не важно что отка, Аноним (-), 17:40 , 02-Июн-12, (41) //

Заботой ФС это было бы в том случае, если бы она это могла сделать хотя бы теоре, анон (?), 18:15 , 02-Июн-12, (46)

А также ECC память, проверка целостности каждого блока данных записанного на дис, Аноним (-), 01:36 , 03-Июн-12, (98)

Проверка целостности данных, на сколько я знаю, происходит при передаче через ин, анон (?), 13:35 , 03-Июн-12, (115)

Ман версионные FS Никакой атомарности нам нахрен не нужно , Аноним (-), 02:03 , 03-Июн-12, (102)

На сколько понял, разница с обычными ФС только при изменении данных, т е они не, анон (?), 12:41 , 03-Июн-12, (110)

Да При том только измененных блоков И меняются структуры описывающие размещени, Аноним (-), 01:30 , 04-Июн-12, (148)

В контексте обсуждений это та же хрень, что и с журналом, только сбоку Тут обсу, анон (?), 02:32 , 04-Июн-12, (167)

С этой точки зрения атомарность - костылик обычным ФС по сути А у этих некое, Аноним (-), 01:37 , 04-Июн-12, (152)

Атомарность - свойство, а не сущность, т е иными словами не может быть костылем, анон (?), 02:39 , 04-Июн-12, (168)

Журнал решает совсем другую проблему - поддерживает целостность самой ФС, а не д, Аноним (-), 19:50 , 02-Июн-12, (56) +1

кто сказал zfs , Аноним (-), 20:43 , 03-Июн-12, (129) //

И она конечно гарантирует, что например при отключении питания все данные будут , анон (?), 22:14 , 03-Июн-12, (132)

Такие ФС гарантируют что у вас или уж старая версия файла, или новая А не непой, Аноним (-), 02:10 , 04-Июн-12, (165)

К сожалению тут, как уже отписался выше на 1 пост, обсуждается мной озвученная с, анон (?), 02:41 , 04-Июн-12, (169)

Во первых, журнал - один В него сначала пишутся намерения Если облом на этой ф, Аноним (-), 17:26 , 02-Июн-12, (33) //

В COW тоже накладные расходы высокие При изменении файла, он еще и копируется в, Аноним (-), 17:38 , 02-Июн-12, (38) //

Глупости Пишется в новое место только блок кластер сектор зависит от термина мин, ананим (?), 18:34 , 02-Июн-12, (47)

такой же объём для сектора, но никто не гранулирует по секторам Грануляция идёт, Аноним (-), 20:00 , 02-Июн-12, (57)

DВсё верно почти Вот только всё ЭТО только отговорка от темы перезаписи все, ананим (?), 21:55 , 02-Июн-12, (80)

ЗзыжВо-первых это вопрос терминологии Во-аторых размер сектора бывает разный А, ананим (?), 22:01 , 02-Июн-12, (83)

это называется кластером и никто не оперирует в ФС сектором , Аноним (-), 22:35 , 02-Июн-12, (85)

БЛОКОМ сознательно заметаете свой слив , ананим (?), 23:15 , 02-Июн-12, (89)

А все-равно тупо У нормальных людей нормальные экстентные аллокаторы уж давно, , Аноним (-), 01:32 , 04-Июн-12, (149) –2

С нетерпением ждём и надеемся Счастливые пользователи ZFS Так когда жда, iZEN (ok), 01:40 , 04-Июн-12, (153)

Это того который даже отдебажить нормально не могут до сих пор, так что полно ви, Аноним (-), 02:07 , 04-Июн-12, (164)

Вот только вопрос кто кому и чего покажет , schwed (?), 11:35 , 04-Июн-12, (184)

какая разница где она происходит, этот процесс порождает несколько грязных класт, Аноним (-), 22:36 , 02-Июн-12, (86)

Так что там с перемещением всего файла и оверхедом коу , ананим (?), 23:17 , 02-Июн-12, (90)

про весь файл писал кто-то другой , Аноним (-), 01:16 , 03-Июн-12, (97)

D, ананим (?), 01:40 , 03-Июн-12, (99)
Я писал Первый снепшот в LVM2 дает сильное замедление в работе, последующие пра, Аноним (-), 01:42 , 03-Июн-12, (100)

Я думаю что теперь вы понимаете почему так активно пилят btrfs Там снапшоты - н, Аноним (-), 01:36 , 04-Июн-12, (151)

Никуда там файл не копируется При записи изменений 1 В сторонку пишется блок с, Аноним (-), 01:17 , 04-Июн-12, (145)

Если формат метаданных изменился, значит получается несовместимость с предыдущим, АнонимЪ (?), 14:01 , 02-Июн-12, (14) //

Вариант с простым игнорированием данной информации более ранними версиями Вами н, анон (?), 15:31 , 02-Июн-12, (23)

Не совсем понятно это чего Что разе ехт4 ехт2 не могла чекать данные А други, anonymous (??), 14:14 , 02-Июн-12, (15) //

разрушение метаданных может вынудить fsck порубить нормальные данные в капусту , Аноним (-), 17:39 , 02-Июн-12, (40) //

Это понятно Понятно даже почему это было на кассетах от БК,но как это может про, anonymous (??), 23:33 , 02-Июн-12, (92) //

Наверное потому что это файловой системой толком не являлось А чексумм блоков с, Аноним (-), 01:40 , 04-Июн-12, (154)

А есть инфа как изменится занимаемое место , Panasonic1 (ok), 15:06 , 02-Июн-12, (20) //

увеличится на 4 байта per inode петросян, Аноним (-), 20:02 , 02-Июн-12, (58)

Да, посмотрели разработчики на ZFS BTRFS и закричали мы тоже такое себе хотим , dalco (ok), 15:39 , 02-Июн-12, (24) +1 //

Зачем это надо не расшифруете , анон (?), 15:46 , 02-Июн-12, (26) //

Чтобы обнаруживать сбои накопителей или линков к ним, например В момент их появ, Аноним (-), 17:31 , 02-Июн-12, (34) //

Во первых, на сколько мне известно, хранимая на винте информация п у имеет избы, анон (?), 18:00 , 02-Июн-12, (44)

К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели , dalco (ok), 18:43 , 02-Июн-12, (51) +2

Ошибки интерфейса отлавливаются точно см SMART Буферная память ЖД также може, анон (?), 19:12 , 02-Июн-12, (53) –1

В идеальном мире из идеальных программ и идеальной аппаратуры вообще ни журналов, dalco (ok), 20:19 , 02-Июн-12, (62) +4

Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования , анон (?), 20:35 , 02-Июн-12, (65)

кто будет восстанавливать запорченные реплики нормальными Что вы тут вещаете эт, Аноним (-), 20:47 , 02-Июн-12, (67)

То, что я вещаю есть способ решения задачи То, что Вы говорите заметьте отсу, анон (?), 20:57 , 02-Июн-12, (70) –2

Имеет, к сожалению Целостность FS от всего вышеперечисленного нехило зависит И, dalco (ok), 20:56 , 02-Июн-12, (69)

А то, что все это зависит от прямости рук админа От этого она не должна защищат, анон (?), 21:10 , 02-Июн-12, (72)

Хм, попробую объяснить последний раз Есть железо, НЕидеальное железо Есть FS,, dalco (ok), 21:39 , 02-Июн-12, (75) +1

Все, что я узнал из вашего поста - не хочу знать где как и что работает, хочу вс, анон (?), 21:54 , 02-Июн-12, (78)
страшно похоже на знакомую на шкуре полемикуленивого по определению админа и м, mix (??), 23:47 , 02-Июн-12, (95)
тут всё прозаичнее, полемика условного технаря с ламерьём это анон Только лам, Аноним (-), 15:49 , 03-Июн-12, (119)
Прозаичнее, это да Думаю что проблема в том, что моя точка зрения не модная и, анон (?), 16:28 , 03-Июн-12, (121)
Господа, все довольно просто Были времена, когда мне действительно было интерес, dalco (ok), 19:11 , 03-Июн-12, (128) +1
Так с этого и надо было начинать ИМХО все хорошее начинается с велосипедов и не, анон (?), 22:29 , 03-Июн-12, (133)
Поздравляю, ваш мозг заржавел Правда с этим обычно не поздравляют Небольшой ф, Аноним (-), 02:05 , 04-Июн-12, (163)
Ваша точка зрения не требует знаний, она ровно такая же модная как и все здесь о, Аноним (-), 22:51 , 03-Июн-12, (136) +2
Ваше мнение очень важно для нас Ждите, мы сами Вам позвоним ЗЫ Еще один аноним , анон (?), 22:56 , 03-Июн-12, (138)
Что, в две смены бедняга поди ишачишь Завтра серверов старент сотни тысяч и теб, kurokaze (ok), 13:56 , 03-Июн-12, (116) –1

Даже круче ECC, которая при сбое чтения пытается скорректироваться самим винтом, Аноним (-), 01:49 , 04-Июн-12, (155)

И что вам не понравилось, будет ошибка - сообщит, будет исправимая ошибка - не с, анон (?), 22:13 , 04-Июн-12, (193)

ему аналог CRC нужен совсем по другой причине Чтение с физического носителя идё, all_glory_to_the_hypnotoad (ok), 23:53 , 04-Июн-12, (197)

Во-первых, спасибо за детали работы, не знал, хоть к делу это и не имеет отношен, анон (?), 00:45 , 05-Июн-12, (198)

Не гарантирует Кроме чтения с физического носителя есть ещё firmware котроллера, all_glory_to_the_hypnotoad (ok), 10:50 , 05-Июн-12, (200)

Приведу ссылку http rlab ru doc s m a r t html 1511и цитату Это лишь пример о, анон (?), 13:54 , 05-Июн-12, (204)

это пример медийных ошибок, а не буфера Точно такие же ошибки как при чтении с, all_glory_to_the_hypnotoad (ok), 22:06 , 05-Июн-12, (209)

Вы либо студент-идиот, либо умело здесь им прикидываетесь Я разговариваю с вами , анон (?), 23:43 , 05-Июн-12, (210)

Да, во избежание недопонимания из-за многабуков, обсуждаемые контрольные суммы о, анон (?), 00:47 , 05-Июн-12, (199)

ты же сам сбежишь от такой ФС первым , Аноним (-), 20:02 , 02-Июн-12, (59)

Я один не вижу use case для этого Там, где нужна надёжность, подсчётом контроль, Crazy Alex (??), 15:44 , 02-Июн-12, (25) –1 //

Черно-белый мир , Аноним (-), 16:35 , 02-Июн-12, (27) +1 //

Ну так вам либо хоть как-то важны данные тогда их надо бэкапить или хотя бы рез, Crazy Alex (??), 17:44 , 02-Июн-12, (42) //

И сейчас ничего не изменилось - по-прежнему нужен аппаратный контроллер , Аноним (-), 22:37 , 03-Июн-12, (135)

Смотря где В ряде случаев можно и без него В том плане что это просто кучка sa, Аноним (-), 02:03 , 04-Июн-12, (162)
Изменилось - раньше он был _необходим_, schwed (?), 14:02 , 04-Июн-12, (187)

придурок, рейд не обеспечивает проверку данных, он _не_ считает контрольные сумм, Аноним (-), 20:07 , 02-Июн-12, (60) –1 //

Какой умный и вежливый аноним Вы когда-нибудь слышали, как работают пятый и шес, Аноним (-), 21:54 , 02-Июн-12, (79) +2 //

А это что-то меняет Что конкретно, на ваш взгляд, при нормальной работе может _д, iZEN (ok), 23:26 , 02-Июн-12, (91)

Если не знаете - книжки почитайте, статьи Зачем к людям-то приставать , Аноним (-), 23:40 , 02-Июн-12, (93) +2

Это же изен Не нести фигню он не может клюв перевешивает , Аноним (-), 02:01 , 04-Июн-12, (161)

Raid-6 может задетектить сбойный диск Ценой за это является лишний шпиндель пущ, Аноним (-), 01:52 , 04-Июн-12, (156)

Современные hard- и soft-контроллёры RAID-1 тоже И что Эта цена при нормальном-, iZEN (ok), 03:50 , 04-Июн-12, (173)

неужели ж 5 и 6 рейды чексуммят мою ФС осподи, чего только на опеннете не прочи, Михрютка (?), 14:04 , 03-Июн-12, (118)

В какой-то роде В общем случае код коррекции ошибок является и кодом детектиров, Аноним (-), 02:00 , 04-Июн-12, (159)

грамотей-опричник в треде you doing it wrong ну-ну я ж говорю, чего только на о, Михрютка (?), 15:54 , 05-Июн-12, (205)

hint ошибки бывают не только аппаратные, но и программные , Михрютка (?), 21:56 , 02-Июн-12, (81) //

Ну так вероятность ошибки в логике Ext4 ничуть не меньше чем вероятность ошибок , Crazy Alex (??), 22:54 , 02-Июн-12, (88) //

и что , Михрютка (?), 00:52 , 03-Июн-12, (96)

В чём хинт-то , Crazy Alex (??), 02:01 , 03-Июн-12, (101)

В том, что ошибки бывают не только аппаратные, но и программные , Аноним (-), 02:40 , 03-Июн-12, (103)
не тупи контроль целостности данных на уровне ФС и контроль целостности данных , Михрютка (?), 14:01 , 03-Июн-12, (117)

ну тогда это получается отладочная возможность для разработчиков FS, не более, Crazy Alex (??), 17:56 , 03-Июн-12, (123)

почему рейды тоже глючат и сбоят особенно саташные промисы без батареек или вс, Михрютка (?), 18:47 , 03-Июн-12, (124)
вы чего такое все курите аппаратный ECC в SDRAM может спасти от разрушения дан, а (?), 18:48 , 03-Июн-12, (127)

Имхо, бесполезно Лучше бы для RAID1 такое сделали - вот там оно действительно, , Аноним (-), 16:57 , 02-Июн-12, (29) //

Вот-вот Здесь оно на месте было бы , Crazy Alex (??), 17:45 , 02-Июн-12, (43) +1
Просто ради интереса, по сообщениям с RAID контроллера или из SMART нельзя это о, анон (?), 18:40 , 02-Июн-12, (50) //

А если они ничего не говорят, а данные с зеркал приходят разные , Аноним (-), 19:40 , 02-Июн-12, (54) //

Тогда как гарантированно определить что это не контроллер , анон (?), 20:18 , 02-Июн-12, (61)
И да, это реальная ситуация или из раздела Истории одного анонимуса Если реал, анон (?), 20:21 , 02-Июн-12, (63)

От балды Одно из зеркал назначается первичным , и при несовпадении данных, бло, Аноним (-), 21:53 , 02-Июн-12, (77)

А в логах ошибок при этом ни каких не пишется и SMART не меняется Т е тупо по , анон (?), 22:09 , 02-Июн-12, (84)

А вот это - как повезет Вообще, как бы не сильно то удобно и быстро SMART пос, Аноним (-), 01:55 , 04-Июн-12, (157)

Т е валидность одного из зеркал определяется сторонними средствами относительно, анон (?), 02:48 , 04-Июн-12, (170)

имелось ввиду НЕ проблемами железа , анон (?), 02:50 , 04-Июн-12, (171)

Для RAID1 надо сделать скоростную доставку в ближайшую дурку Бо находящие в здр, Аноним (-), 22:33 , 03-Июн-12, (134)

Интересно, а поддержка вторых контрольных сумм для проверки целостности этих уже, Аноним (-), 03:44 , 03-Июн-12, (104) //

Это делается проще Берут другой алгоритм подсчета CRC и просчитывают им все тож, dalco (ok), 07:56 , 03-Июн-12, (105) //

это вы сейчас через задницу увеличили битность контрольной суммы, Аноним (-), 22:55 , 03-Июн-12, (137) +2 //

И да, и нет Половинки мегаCRC получаются независимы друг от друга Их вычисля, dalco (ok), 12:49 , 04-Июн-12, (185)

две CRC вычесленные по разным алгоритмам дают меньшую битность чем одно CRC с бо, all_glory_to_the_hypnotoad (ok), 22:53 , 04-Июн-12, (194)

Так, стоп, а кто будет проверять что вторые контрольные суммы - правильные , Аноним (-), 01:58 , 04-Июн-12, (158) //

Если уж прикалываться, и делать контрольную сумму на контрольную сумму, то предл, анон (?), 03:07 , 04-Июн-12, (172)

Вы бы хоть почитали что-нибудь про CRC вместо того чтобы бред нести , ыгчч (?), 10:34 , 04-Июн-12, (182) +1

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

24. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +1 +/–

Сообщение от dalco (ok), 02-Июн-12, 15:39

Да, посмотрели разработчики на ZFS/BTRFS и закричали "мы тоже такое себе хотим" :)
P.S. Если бы этот патч еще и контрольные суммы данных проверял - вообще бы красота была.

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

26. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 02-Июн-12, 15:46

> Да, посмотрели разработчики на ZFS/BTRFS и закричали "мы тоже такое себе хотим"
> :)
> P.S. Если бы этот патч еще и контрольные суммы данных проверял -
> вообще бы красота была.
Зачем это надо не расшифруете?

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

34. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от Аноним (-), 02-Июн-12, 17:31

> Зачем это надо не расшифруете?
Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент их появления, а не когда половина файловой системы превратится в какие-то макароны.

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

44. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 02-Июн-12, 18:00

>> Зачем это надо не расшифруете?
> Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент их
> появления, а не когда половина файловой системы превратится в какие-то макароны.
Во первых, на сколько мне известно, хранимая на винте информация п.у. имеет избыточность в виде хранения ее CRC, которая отслеживается самим винтом. Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое контроллеру.
Во вторых, что мешает самому вычислить CRC для требуемых данных? Возможно есть какие-либо "подводные камни" о которых я не знаю.
То, что может с бОльшей эффективностью (из-за наличия дополнительной информации) управляться на других уровнях системы хранения данных должно управляться на них, иначе будет иметь место избыточность в виде выполнения одного и того же действия (трата ресурсов) или неоправданное возрастание сложности системы (читать как наличие потенциально большего количества ошибок) в результате создания дополнительного связывания ее элементов, работающих на разных уровнях (в перспективе, из-за этого уменьшается также и ее гибкость).
В данном случае, возможно Вам не нужно отслеживать все данные или, при постоянном их изменении как в случае с БД, просчитать CRC вообще будет невозможно, либо возможно, но с большими потерями ресурсов системы.

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

51. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +2 +/–

Сообщение от dalco (ok), 02-Июн-12, 18:43

К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели записать. В реальной жизни то шлейф к винту барахлит, то питание моргает, то память сбоит, то ОС вразнос пошла. А на винте его внутренние CRC при таких неисправностях вполне правильные - он же не в курсе, что ему мусор для записи передали :) Вот для подобных случаев дополнительная CRC на уровне файловой системы и выше становится полезна.
Кстати, там еще и некоторый бонус всплывает - после сбоя проще повреждения искать. Где CRC нарушено - там точно усиленные раскопки нужны.
P.S. А если еще и данные в файловой системе CRC прикрыты, то вообще красота. При периодической фоновой проверке я не только узнаю о наличии проблем, но я еще и буду точно знать - какие конкретно файлы накрылись медным тазом, что, зачастую, крайне полезно при реанимации зомби-компа.

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

53. "Для Ext4 представлена поддержка контрольных сумм для проверк..." –1 +/–

Сообщение от анон (?), 02-Июн-12, 19:12

> К сожалению, нет гарантии, что на винте записаны те самые данные, что
> мы хотели записать. В реальной жизни то шлейф к винту барахлит,
> то питание моргает, то память сбоит, то ОС вразнос пошла. А
> на винте его внутренние CRC при таких неисправностях вполне правильные -
> он же не в курсе, что ему мусор для записи передали
> :) Вот для подобных случаев дополнительная CRC на уровне файловой системы
> и выше становится полезна.
Ошибки интерфейса отлавливаются точно (см. SMART). Буферная память ЖД также может быть проверена (MHDD, Victoria). Питание, уж извините, ИБП решает. Память тоже с избыточностью бывает, вплоть до восстановления информации "на лету". ОС оно конечно серьезно, но такого уровня компоненты, работающие внутри ядра, должны и скорее всего усиленно тестируются. Не надо также забывать и о проверке "временем", т.е. пользоваться не самым новым, а зарекомендовавшим себя ядром/софтом/железом там , где нужна повышенная надежность. Делайте копии, профилактику и будет счастье.
> Кстати, там еще и некоторый бонус всплывает - после сбоя проще повреждения
> искать. Где CRC нарушено - там точно усиленные раскопки нужны.
Никак не проще. Постройте себе дерево из CRC для интересующей части ФС и сверяйте ее с текущим. Вот и все.
> P.S. А если еще и данные в файловой системе CRC прикрыты, то
> вообще красота. При периодической фоновой проверке я не только узнаю о
> наличии проблем, но я еще и буду точно знать - какие
> конкретно файлы накрылись медным тазом, что, зачастую, крайне полезно при реанимации
> зомби-компа.
Если "зачастую крайне полезно", то у Вас уже есть примеры реализации подобных возможностей. Если не сложно поделиться инфой, поделитесь.
Делая своевременные копии информации мне все равно что случится с компом и я всегда уверен, что если выяснится факт некорректности файла - я смогу взять его из проверенной копии.
Все проблемы решаемы, и не надо придумывать себе задачи, которые кроме как к новым проблемам ни к чему не приведут, и их решать.

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

62. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +4 +/–

Сообщение от dalco (ok), 02-Июн-12, 20:19

>Ошибки интерфейса отлавливаются точно (см. SMART). Буферная память ЖД также может быть проверена (MHDD, Victoria). Питание, уж извините, ИБП решает. Память тоже с избыточностью бывает, вплоть до восстановления информации "на лету". ОС оно конечно серьезно, но такого уровня компоненты, работающие внутри ядра, должны и скорее всего усиленно тестируются. Не надо также забывать и о проверке "временем", т.е. пользоваться не самым новым, а зарекомендовавшим себя ядром/софтом/железом там , где нужна повышенная надежность. Делайте копии, профилактику и будет счастье.
В идеальном мире из идеальных программ и идеальной аппаратуры вообще ни журналов, ни fsck не нужно. Одна беда - живем-то мы в реальном :) И смарт не всегда отслеживается, и рейд-контроллер глючит, и банальная несовместимость железа при конкретной версии прошивки винта.
Особенно весело, когда винт не один, а сотня-другая, и тестить их все через MHDD, мягко говоря, некогда.
>Если "зачастую крайне полезно", то у Вас уже есть примеры реализации подобных >возможностей. Если не сложно поделиться инфой, поделитесь.
>   Делая своевременные копии информации мне все равно что случится с компом и я всегда >уверен, что если выяснится факт некорректности файла - я смогу взять его из проверенной >копии.
>
>   Все проблемы решаемы, и не надо придумывать себе задачи, которые кроме как к новым >проблемам ни к чему не приведут, и их решать.
Ок, пример из реальной жизни. Глючит рейд-контролер. Не так, чтобы вообще сплошной мусор пишет, но иногда с ним такое случается. И до вас это дошло только сейчас.
В разделе несколько десятков терабайт информации, сервак работает и останавливать его крайне не желательно. Восстановление информации из бэкапа - гарантированные пол-суток простоя. Самое обидное, что непонятно - нужно ли вообще делать эти действия, быть может, вся инфа на разделе вполне валидная.
И я попадал в эту ситуацию. Единственный плюс - начальство знало, что сервак глючит, и было морально готово к его остановке, благо, его близнец на другом краю России работал без сбоев.
В случае того же ZFS/BTRFS раз в сколько-то времени в фоновом режиме по всему диску проходит демон, проверяя файловые CRC. Если что, он просто кидает мне письмо, что файлы такие-то и такие-то накрылись и резервной копии у системы нет (а бывает, что есть, и демон сам все восстановит). И, зная конкретный убитый файл, я уже буду распаковывать не весь бэкап, а только его малую часть, сэкономив кучу времени. Заодно я буду в курсе, что с файловой системой что-то не так, хотя вся аппаратура мониторинга молчит, как партизан.
P.S. Если какая-то фича для вас не очевидна и не особо нужна, то это еще не значит, что она не нужна другим.

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

65. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 02-Июн-12, 20:35

> В идеальном мире из идеальных программ и идеальной аппаратуры вообще ни журналов,
> ни fsck не нужно. Одна беда - живем-то мы в реальном
> :) И смарт не всегда отслеживается, и рейд-контроллер глючит, и банальная
> несовместимость железа при конкретной версии прошивки винта.
Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения. Согласен, что она должна по возможности сопротивляться реалиям, но требовать от нее полного обеспечения безопасности хранения как минимум недальновидно по причине неминуемого падения других характеристик (скорость, простота использования, падение эффективности использования ресурсов системы) и как максимум невозможно т.к. она полностью зависит от системы, где она работает, на которую она не в силах никак повлиять.
> Ок, пример из реальной жизни. Глючит рейд-контролер. Не так, чтобы вообще сплошной
> мусор пишет, но иногда с ним такое случается. И до вас
> это дошло только сейчас...
> В случае того же ZFS/BTRFS раз в сколько-то времени в фоновом режиме
> по всему диску проходит демон, проверяя файловые CRC. ...
Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое.
> P.S. Если какая-то фича для вас не очевидна и не особо нужна,
> то это еще не значит, что она не нужна другим.
Я где-то написал что это не нужно? Странно что нормальные вопросы и попытки добраться до истины вещей у вас вызывают такие чувства.

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

67. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от Аноним (-), 02-Июн-12, 20:47

> Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое.
кто будет восстанавливать запорченные реплики нормальными? Что вы тут вещаете это костыль для ФС которые не умеют этого делать.
У систем безопасности юз-кейсы совсем другие и их использование мягко говоря, геморное. Как собираешься отслеживать изменение данных без поддрежки ФС? Придётся вещать кучу костылей в ОС и городить прочие подпорки.

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

70. "Для Ext4 представлена поддержка контрольных сумм для проверк..." –2 +/–

Сообщение от анон (?), 02-Июн-12, 20:57

>> Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое.
> кто будет восстанавливать запорченные реплики нормальными? Что вы тут вещаете это костыль
> для ФС которые не умеют этого делать.
То, что я "вещаю" есть способ решения задачи. То, что Вы говорите (заметьте отсутствие хамского тона), что это костыль, еще не значит, что встроенная поддержка в ФС решает эти задачи лучше. По вашей логике, все программы надо объединить с ядром ОС и запускать всю систему как единый исполняемый файл иначе все будет в виде костылей к ядру.
> У систем безопасности юз-кейсы совсем другие и их использование мягко говоря, геморное.
> Как собираешься отслеживать изменение данных без поддрежки ФС? Придётся вещать кучу
> костылей в ОС и городить прочие подпорки.
И какие данные на сервере изменяются? БД? И как их поможет отслеживать хваленые ZFS/BTRFS?

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

69. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от dalco (ok), 02-Июн-12, 20:56

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

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

72. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 02-Июн-12, 21:10

>>Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения.
> Имеет, к сожалению. Целостность FS от всего вышеперечисленного нехило зависит. И если
> FS не знает о наличии проблем в аппаратуре, то это еще
> не значит, что этих проблем нет.
А то, что все это зависит от прямости рук админа? От этого она не должна защищать? Может и руки продублировать? Есть же предел издевательствам! Или нет?
> А никто и не требует от FS невозможного. Просто добавили ей еще
> один шанс, который иногда помогает.
Просто не надо на этом концентрировать внимание. Добавили - хорошо. Кстати я в обсуждении имел ввиду проверку именно данных, а не внутренних данных ФС. Если вы имеете ввиду второе и спорите на счет первого, то мы не договоримся.
>>Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое.
> А зачем мне изобретать велосипед, городить скрипты, когда со всем этим легко
> и не напряжно справится утилита из состава этой самой FS.
Т.е. у вас нет проблемы стабильности т.к. вы не решали ее скриптом, но задарма получая возможность это делать, вы готовы "сровнять с землей" другие решения лишь бы оправдать свое неосиляторство. Или я не прав и есть реальные доводы в пользу ФС?
> Почему мне не нравится отдельная прога? Элементарно - FS лучше знает -
> где и как ей лучше себя проверять, не мешая другим, и
> как лучше восстановиться, не прерывая рабочего процесса (если таковая возможность есть).
> К тому же, подобная проверка вполне может идти на уровне ядра -
> т.е. быстро и без заморочек с правами.
Лучше всего знает админ когда ему требуется проверка данных, каких конкретно данных, и насколько ему это надо (в ущерб производительности или во время простоя). Этого ФС знать не может.
В ином случае это объединение решения различных задач в одном месте - комбайн. Еще раз, ИМХО CRC метаданных - хоошо, CRC данных пользователя - отчасти невозможно и полностью не нужно.

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

75. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +1 +/–

Сообщение от dalco (ok), 02-Июн-12, 21:39

Хм, попробую объяснить последний раз...
Есть железо, НЕидеальное железо. Есть FS, которая живет на этом НЕидеальном железе. Все, что мне от этой FS нужно - чтобы она надежно хранила данные или хотя бы сообщала, где она лажанулась. Т.е. я либо получаю от нее данные, которым я верю без дополнительных проверок с моей стороны, либо 100% же уверенность, что такой-то файл в такой-то ноде потерян. Для этого и нужно полное CRC (не только метаданные, но и сами данные).
Для меня, как конечного пользователя, FS - "черный ящик". Что и как она там делает - не моя забота, главное, чтобы данные были целы. И я не должен бегать за FS и подтирать ей сопли каждый раз, когда она споткнется. Пусть выживает сама по мере сил.
В случае одного-двух серверов я могу потратить время на тонкий тюнинг FS, доскональное тестирование железа и навешивание third party костылей. Когда серверов сотни, мне заниматься этим некогда.
Вот отсюда и растут ноги у ZFS/BTRFS - они выживать в реальном мире научились (по крайней мере, на бумаге).
P.S. Усе, иду баиньки, буду сверять CRC нейронов :)))

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

78. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 02-Июн-12, 21:54

Все, что я узнал из вашего поста - не хочу знать где как и что работает, хочу всех проверок на всех уровнях и много денег на железо, которое все это потянет. Это похоже на паранойю. Когда в меру, то все нормально ибо некоторый запас всегда должен быть, но тут уже тяжелый случай.
Объяснять начиная каждую фразу "Все, что мне нужно", "Для меня", "И я не должен" и т.д. как-то странно. Не много ли зависит от Вашей личности? Вы или идеальный и безгранично опытный админ и ваша речь что-то значит, либо админ не знающий своего железа и Ваша речь не более чем болтовня и сказки.
ЗЫ Спокойной ночи.

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

95. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от mix (??), 02-Июн-12, 23:47

страшно похоже на знакомую на шкуре  полемику
ленивого(по определению) админа и манагера )
типа - а сделайте мне красиво и бесплатно.

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

119. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от Аноним (-), 03-Июн-12, 15:49

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

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

121. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 03-Июн-12, 16:28

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

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

128. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +1 +/–

Сообщение от dalco (ok), 03-Июн-12, 19:11

Господа, все довольно просто.
Были времена, когда мне действительно было интересно устройство каждой железки и каждой софтины в компе. Мне не влом было сотворить собственными руками какой-нибудь аппаратный или програмный прибамбас для компа. Очередной велосипед изобретался ради самого процесса изобретения. Генерилась куча кода на асме и Си ради повышения ЧСВ и просто ради фана.
Но время шло, я все дальше уходил в глубины энтерпрайза... И обнаружил пренеприятнейшие вещи. Оказалось, что велосипеды не столько повышают ЧСВ, сколько приносят попоболи. Каждый велосипед надо подробно документировать, за его поведение материальную ответственность несешь именно ты, а вот бонусов никаких, кроме устного поощрения от начальства (очень изредка). К тому же, в энтерпрайзе ценятся не те решения, которые красивые, а те, что надежные, документированные,требующие минимальной поддержки и, в случае чего, легко починяемые/заменяемые не очень квалифицированным персоналом типа приходящего админа-студента.
Так что теперь я копаю документацию ровно настолько, сколько необходимо и достаточно для запуска очередного "черного ящика". В случае проблем оказывается гораздо быстрее и дешевле взять аналогичную деталь со склада или типовую виртуалку из бэкапа, чем рыться во внутренностях железки с паяльником или искать в каком конфиге что слетело.
Да, теперь я почти не думаю, ибо для 99% ситуаций уже готовы типовые решения. И я не бегаю со взмыленной задницей, лихорадочно вспоминая где и за какую хрень у компа XYZ надо дернуть, чтобы оно опять полетело в правильном направлении. И, самое странное, меня это вполне устраивает :)

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

133. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 03-Июн-12, 22:29

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

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

163. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от Аноним (-), 04-Июн-12, 02:05

> Так что теперь я копаю документацию ровно настолько, сколько необходимо и достаточно
> для запуска очередного "черного ящика".
Поздравляю, ваш мозг заржавел. Правда с этим обычно не поздравляют...
> И, самое страшное, меня это вполне устраивает :)
Небольшой фикс. Ибо когда мозг заржавел - это страшно. По сути это уже отработанный материал.


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

136. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +2 +/–

Сообщение от Аноним (-), 03-Июн-12, 22:51

Ваша точка зрения не требует знаний, она ровно такая же модная как и все здесь остальные. Да, были времена, лет эдак 15-20 назад, когда на любую проблему был подход подобный вашему и тогда это был модно. Подобный это найти близкую по звучанию технологию для проблемы X и пихать её куда попало, мол 'зачем решать эту проблему, мы же можем прикостылять сюда X или Y'. У некоторых даже поворачивался язык называть этот бред юникс веем.
К счастью, эти времена ушли, многие успели набить на этом ишики и стали ценить технологичность решений. А о тех временах сейчас напоминает некоторое легаси  и немногочисленные  личности вроде вас, которые остались в своём понимании и видении развития технологий в 8х-9х годах.

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

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

138. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 03-Июн-12, 22:56

Ваше мнение очень важно для нас. Ждите, мы сами Вам позвоним.
ЗЫ Еще один аноним не умеющий читать от начала до конца.

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

116. "Для Ext4 представлена поддержка контрольных сумм для проверк..." –1 +/–

Сообщение от kurokaze (ok), 03-Июн-12, 13:56

>Когда серверов сотни, мне заниматься этим некогда.
Что, в две смены бедняга поди ишачишь? Завтра серверов старент сотни тысяч и тебе прийдется в третью смену выходить, бггг

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

155. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от Аноним (-), 04-Июн-12, 01:49

> Во первых, на сколько мне известно, хранимая на винте информация п.у. имеет
> избыточность в виде хранения ее CRC, которая отслеживается самим винтом.
Даже круче: ECC, которая при сбое чтения пытается скорректироваться самим винтом, прозрачно для вас. В идеале фирмваре еще и проблемный сектор на резервный ремапнуть должно бы (правда у некоторых дисков оно столь тупое что убедить его увидеть сбойный сектор можно только спецпинком по болючему месту).
> Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое
> контроллеру.
Нифига он не сообщит - если удалось починить то вы получаете данные. Если не удалось - read error. Статистика полетов - в SMART.
> Во вторых, что мешает самому вычислить CRC для требуемых данных? Возможно есть
> какие-либо "подводные камни" о которых я не знаю.
Ничто не мешает, кроме того что ФС это может делать прозрачно и для всего, а в остальных случаях - надо явно позаботиться.
> постоянном их изменении как в случае с БД, просчитать CRC вообще
> будет невозможно, либо возможно, но с большими потерями ресурсов системы.
Что за идиотека? Кто запретил считать CRC поблочно?

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

193. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 04-Июн-12, 22:13

> Нифига он не сообщит - если удалось починить то вы получаете данные. Если не удалось - read error. Статистика полетов - в SMART.
И что вам не понравилось, будет ошибка - сообщит, будет исправимая ошибка - не сообщит. В чем проблема? Или Вам надо по каждой проблеме свой лог вести, даже если проблема и не проблема вовсе?
На счет работы ЖД я в курсе. Ремап можно запустить многократной записью в сектор с большим временем доступа. Предполагаю, что с некоторыми конкретными моделями есть нюансы, но это не суть важно.
> Ничто не мешает, кроме того что ФС это может делать прозрачно и для всего,
> а в остальных случаях - надо явно позаботиться.
dalco уже говорил, что в случае ZFS/BTRFS по диску проходит демон и проверяет CRC. Точно такого же демона (по сути, это та же программа или, с определенной натяжкой в деталях реализации, скрипт) можно сделать универсальным для всех ФС. Так зачем делать из кода поддержки ФС кухонный комбайн и жить в ожидании что какая-нибудь из тех встроенных хреновин, без которых "нельзя" прожить, не "накроет" всю информацию на винте? Из практических соображений критические области, коей по факту важности и является ФС, необходимо уменьшать и упрощать, а тут предлагают сделать разжиревшее и потенциально небезопасное с точки зрения хранения информации, мягко говоря, уродство.
Ошибки надо исправлять на том уровне, на котором их возможно в наиболее полной мере исправить. Это возможно при обладании максимально полной информацией о том, чего Вы хотите. ФС этого знать не может. Можно конечно сделать механизм, позволяющей сделать это, но надо ли это все, если вполне реально обеспечить ту же функциональность другими, более универсальными, а скорее всего и не мене (если не более) эффективными средствами, в наибольшей степени отвечающим вашим потребностям. Именно по этому CRC метаданных - есть правильное решение т.к. кроме ФС, владеющей ими, о них толком ни кто не знает (и не должен) и решения должны приниматься именно на этом уровне. В случае же с данными пользователя, они принадлежат именно ему, а не ФС, именно по этому решения по их обслуживанию и само обслуживание должно приниматься и производиться им, конечно при условии, что его интересы не настолько жестко завязаны на конкретную ФС и не требуют проведения специфичных операций. В случае CRC данных пользователя никаких специфичных операций производиться не должно.
> постоянном их изменении как в случае с БД, просчитать CRC вообще
> будет невозможно, либо возможно, но с большими потерями ресурсов системы.
> Что за идиотека? Кто запретил считать CRC поблочно?
И как посчитать CRC БД так, чтобы им можно было воспользоваться, при условии, что БД все же используется, а не просто хранится? Подсказка: конечная цель всей этой "камасутры" не посчитать CRC, а установить корректность и неизменность данных, что без привлечения самой СУБД с этой БД невозможно в принципе. Даже если ФС позволяет "заморозить" данные для расчета CRC, то установить момент для "заморозки", когда дынные в БД будут в валидном состоянии, без самой СУБД невозможно. Связь же между СУБД и ФС, которая могла бы включать такую возможность, вообще маразм высшей степени.

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

197. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от all_glory_to_the_hypnotoad (ok), 04-Июн-12, 23:53

> Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое контроллеру.
ему аналог CRC нужен совсем по другой причине. Чтение с физического носителя идёт с ошибками и сумму контроллер диска использует для N-кратного перечтения сектора. Только если после M попыток так и не удалось считать блок, то получается ошибка IO. Это рядовое событие для диска (в смысле, перечтение сектора) и здесь нет наложения "уровней", сумма на диске служит совсем иным целям.

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

198. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 05-Июн-12, 00:45

Во-первых, спасибо за детали работы, не знал, хоть к делу это и не имеет отношения.
Во-вторых, процетирую dalco:
> Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент
> их появления, а не когда половина файловой системы превратится в какие-то макароны.
и после моего коммента (он же):
> К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели записать.
Так что то, что я имел ввиду я ввиду и имел, что подтверждаете и Вы
> Только если после M попыток так и не удалось считать блок, то получается ошибка IO.
т.к. потеря доли информации из-за неудачного чтения эквивалентно ее испорченному состоянию.
> сумма на диске служит совсем иным целям.
Это да, но также она гарантирует и то, что данные считанные с диска - это те же данные, что на него и записывались.
Тут же, усиленно предлагают, и за это неистово "плюсуют", ввести второй уровень проверки корректности данных на диске исходя из того, что эта гарантия не работает, причем встроить эту проверку в код работы ФС.
Единственное, для чего это может пригодиться, так это для аудита системы и проверки того, что никто не изменил данные извне. Но это вообще к ФС отношения не имеет и в код включаться не должно. Также тут упоминается про ZFS и BTRFS, в которых, со слов того же dalco, имеется встроенная возможность проверки контрольных сумм файлов в ФС. Правда он заметил, что она реализована через демон и работает на уровне ядра (тут у меня есть некоторые сомнения, но разбираться не хочу за ненадобностью).
Мной предлагался способ считать контрольные суммы без участия ФС, что я считаю как минимум более логичным.

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

200. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от all_glory_to_the_hypnotoad (ok), 05-Июн-12, 10:50

> Это да, но также она гарантирует и то, что данные считанные с диска - это те же данные, что на него и записывались.
Не гарантирует. Кроме чтения с физического носителя есть ещё firmware котроллера самого диска, а там внутри кэш который навряд ли в лоу энде чем-то вообще защищён. И само firmware тоже нередко бывает с ошибками. HDD это уже давно не просто набор блинов. Ещё раз попробую донести смысл суммы на диске - это часть механизма общения между физ. носителем и firmware диска, и всё.
> Тут же, усиленно предлагают, и за это неистово "плюсуют", ввести второй уровень проверки корректности данных
нет тут второго уровня, это ваша фантазия и какое-то непонимание что, как и где нужно.
> Единственное, для чего это может пригодиться, так это для аудита системы и проверки того, что никто не изменил данные извне.
Аудит это совсем другая область и она не имеет отношения к суммам на уровне ФС. Суммы для аудита реализуются совсем другими методами с точки зрения реализации, у них разные временные характеристики и т.п.
> Мной предлагался способ считать контрольные суммы без участия ФС, что я считаю как минимум более логичным.
если вам нужно просто считать суммы непонятно для какой цели и для чего, то да, их можно считать без ФС и даже без участия каких-либо полезных данных. Тупо можно взять /dev/urandom, посчитать сумму и считать это более логичным чем суммы в ФС

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

204. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 05-Июн-12, 13:54

Приведу ссылку
http://rlab.ru/doc/s.m.a.r.t..html#1511
и цитату:
> UltraDMA CRC Error Count
> Общее количество ошибок CRC в режиме UltraDMA.
> Поле raw value содержит количество ошибок, возникших в режиме передачи
> данных UltraDMA в контрольной сумме (ICRC - Interface CRC).
> Примечание автора. Практика, собранная статистика и изучение журналов ошибок SMART
> показывают: в большинстве случаев ошибки CRC возникают при сильном завышении частоты PCI
>(больше номинальных 33.6 MHz), сильно перекрученом кабеле, а также - по вине драйверов ОС,
> которые не соблюдают требований к передачи/приему данных в режимах UltraDMA.
Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже). Если посмотрите более внимательно то заметите, что HDD отлавливает массу ошибок как аппаратного происхождения, так и программного и, по моему мнению, данным с него можно доверять практически не проверяя (абсолютно конечно, в силу вероятностной природы самого CRC, ничто не может гарантировать, тут я согласен). Можете спорить дальше на этот счет и цепляться к тому, что не ATA единым и что SMART не связана с контроллером и чем либо еще, кроме HDD, но мне все равно, т.к. ваши оправдания в своем же лице подведомственны только специалисту (психиатру).
> Ещё раз попробую донести смысл суммы на диске - это часть механизма общения между физ. носителем и firmware диска, и всё.
Надо смотреть шире на вещи. Если "внутренние" гарантии (считывание с блинов и передача по интерфейсу) обеспечивают также и "внешние" (гарантия соответствия считанных данных записанным), то это так и есть. А Ваша логика - если проверяется в HDD, то кроме как в HDD это не имеет смысла. В этом плане вы не менее упоротый теоретик, на сколько упорот и практик выше по ветке, но если его можно понять, то Вас я понимать решительно отказываюсь за отсутствие желания заниматься мозговым онанизмом.
> нет тут второго уровня, это ваша фантазия и какое-то непонимание что, как и где нужно.
На счет своего непонимания слышу от "профессионалов" в каждом посте этой ветки, только вот беда, все доводы они основывают на личных убеждениях и уничижении других.
> если вам нужно просто считать суммы непонятно для какой цели...
Я даже отвечать на эти "обрубки" моего поста не буду. Если бы Вы умели читать, то поняли, что мне эти CRC никуда не вперлись и ради интереса в мотивации неприменул спросить у "виновника" этого обсуждения. Далее понеслась вся эта тупость, которую Вы безаппиляционно продолжаете.

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

209. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от all_glory_to_the_hypnotoad (ok), 05-Июн-12, 22:06

> Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже).
это пример медийных ошибок, а не буфера.  Точно такие же ошибки как при чтении с носителя, но вдругом месте. Откуда у вас эта трафа на счёт 'вашего буфера'? Достаточно уже кидать ссылки содержимое кторых вам не понятно.
> и уничижении других.
что же поделать, таков закон джунглей.

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

210. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 05-Июн-12, 23:43

Вы либо студент-идиот, либо умело здесь им прикидываетесь.
Я разговариваю с вами только из-за того, что мне это по приколу. Не злоупотребляйте.
Если решите оправдать себя, то пожалуйста приведите ссылки из сторонних, относительно вашего ума, источников (сразу уточняю, что соц. сети и ваша личная страница не покатят) по поводу:
1. "медийная ошибка" (и какие еще в этой классификации присутствуют)
2. "трафа" (цитата "Откуда у вас эта трафа на счёт 'вашего буфера'")
3. "аналог CRC" (сумма на диске; уточните чем фактически отличается если аналог)
Как Вы понимаете суть проблемы в данной ветке т.к. мне кажется, что вы ее не понимаете?
ЗЫ При условии продолжения безосновательной глупости с Вашей стороны буду считать полный Ваш слив по всем вопросам.

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

199. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от анон (?), 05-Июн-12, 00:47

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

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

59. "Для Ext4 представлена поддержка контрольных сумм для проверк..." +/–

Сообщение от Аноним (-), 02-Июн-12, 20:02

> P.S. Если бы этот патч еще и контрольные суммы данных проверял - вообще бы красота была.
ты же сам сбежишь от такой ФС первым.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

24. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
Сообщение от dalco (ok), 02-Июн-12, 15:39
Да, посмотрели разработчики на ZFS/BTRFS и закричали "мы тоже такое себе хотим" :) P.S. Если бы этот патч еще и контрольные суммы данных проверял - вообще бы красота была.
Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 02-Июн-12, 15:46
	> Да, посмотрели разработчики на ZFS/BTRFS и закричали "мы тоже такое себе хотим" > :) > P.S. Если бы этот патч еще и контрольные суммы данных проверял - > вообще бы красота была. Зачем это надо не расшифруете?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (-), 02-Июн-12, 17:31
	> Зачем это надо не расшифруете? Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент их появления, а не когда половина файловой системы превратится в какие-то макароны.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 02-Июн-12, 18:00
	>> Зачем это надо не расшифруете? > Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент их > появления, а не когда половина файловой системы превратится в какие-то макароны. Во первых, на сколько мне известно, хранимая на винте информация п.у. имеет избыточность в виде хранения ее CRC, которая отслеживается самим винтом. Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое контроллеру. Во вторых, что мешает самому вычислить CRC для требуемых данных? Возможно есть какие-либо "подводные камни" о которых я не знаю. То, что может с бОльшей эффективностью (из-за наличия дополнительной информации) управляться на других уровнях системы хранения данных должно управляться на них, иначе будет иметь место избыточность в виде выполнения одного и того же действия (трата ресурсов) или неоправданное возрастание сложности системы (читать как наличие потенциально большего количества ошибок) в результате создания дополнительного связывания ее элементов, работающих на разных уровнях (в перспективе, из-за этого уменьшается также и ее гибкость). В данном случае, возможно Вам не нужно отслеживать все данные или, при постоянном их изменении как в случае с БД, просчитать CRC вообще будет невозможно, либо возможно, но с большими потерями ресурсов системы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от dalco (ok), 02-Июн-12, 18:43
	К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели записать. В реальной жизни то шлейф к винту барахлит, то питание моргает, то память сбоит, то ОС вразнос пошла. А на винте его внутренние CRC при таких неисправностях вполне правильные - он же не в курсе, что ему мусор для записи передали :) Вот для подобных случаев дополнительная CRC на уровне файловой системы и выше становится полезна. Кстати, там еще и некоторый бонус всплывает - после сбоя проще повреждения искать. Где CRC нарушено - там точно усиленные раскопки нужны. P.S. А если еще и данные в файловой системе CRC прикрыты, то вообще красота. При периодической фоновой проверке я не только узнаю о наличии проблем, но я еще и буду точно знать - какие конкретно файлы накрылись медным тазом, что, зачастую, крайне полезно при реанимации зомби-компа.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от анон (?), 02-Июн-12, 19:12
	> К сожалению, нет гарантии, что на винте записаны те самые данные, что > мы хотели записать. В реальной жизни то шлейф к винту барахлит, > то питание моргает, то память сбоит, то ОС вразнос пошла. А > на винте его внутренние CRC при таких неисправностях вполне правильные - > он же не в курсе, что ему мусор для записи передали > :) Вот для подобных случаев дополнительная CRC на уровне файловой системы > и выше становится полезна. Ошибки интерфейса отлавливаются точно (см. SMART). Буферная память ЖД также может быть проверена (MHDD, Victoria). Питание, уж извините, ИБП решает. Память тоже с избыточностью бывает, вплоть до восстановления информации "на лету". ОС оно конечно серьезно, но такого уровня компоненты, работающие внутри ядра, должны и скорее всего усиленно тестируются. Не надо также забывать и о проверке "временем", т.е. пользоваться не самым новым, а зарекомендовавшим себя ядром/софтом/железом там , где нужна повышенная надежность. Делайте копии, профилактику и будет счастье. > Кстати, там еще и некоторый бонус всплывает - после сбоя проще повреждения > искать. Где CRC нарушено - там точно усиленные раскопки нужны. Никак не проще. Постройте себе дерево из CRC для интересующей части ФС и сверяйте ее с текущим. Вот и все. > P.S. А если еще и данные в файловой системе CRC прикрыты, то > вообще красота. При периодической фоновой проверке я не только узнаю о > наличии проблем, но я еще и буду точно знать - какие > конкретно файлы накрылись медным тазом, что, зачастую, крайне полезно при реанимации > зомби-компа. Если "зачастую крайне полезно", то у Вас уже есть примеры реализации подобных возможностей. Если не сложно поделиться инфой, поделитесь. Делая своевременные копии информации мне все равно что случится с компом и я всегда уверен, что если выяснится факт некорректности файла - я смогу взять его из проверенной копии. Все проблемы решаемы, и не надо придумывать себе задачи, которые кроме как к новым проблемам ни к чему не приведут, и их решать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+4 +/–
	Сообщение от dalco (ok), 02-Июн-12, 20:19
	>Ошибки интерфейса отлавливаются точно (см. SMART). Буферная память ЖД также может быть проверена (MHDD, Victoria). Питание, уж извините, ИБП решает. Память тоже с избыточностью бывает, вплоть до восстановления информации "на лету". ОС оно конечно серьезно, но такого уровня компоненты, работающие внутри ядра, должны и скорее всего усиленно тестируются. Не надо также забывать и о проверке "временем", т.е. пользоваться не самым новым, а зарекомендовавшим себя ядром/софтом/железом там , где нужна повышенная надежность. Делайте копии, профилактику и будет счастье. В идеальном мире из идеальных программ и идеальной аппаратуры вообще ни журналов, ни fsck не нужно. Одна беда - живем-то мы в реальном :) И смарт не всегда отслеживается, и рейд-контроллер глючит, и банальная несовместимость железа при конкретной версии прошивки винта. Особенно весело, когда винт не один, а сотня-другая, и тестить их все через MHDD, мягко говоря, некогда. >Если "зачастую крайне полезно", то у Вас уже есть примеры реализации подобных >возможностей. Если не сложно поделиться инфой, поделитесь. > Делая своевременные копии информации мне все равно что случится с компом и я всегда >уверен, что если выяснится факт некорректности файла - я смогу взять его из проверенной >копии. > > Все проблемы решаемы, и не надо придумывать себе задачи, которые кроме как к новым >проблемам ни к чему не приведут, и их решать. Ок, пример из реальной жизни. Глючит рейд-контролер. Не так, чтобы вообще сплошной мусор пишет, но иногда с ним такое случается. И до вас это дошло только сейчас. В разделе несколько десятков терабайт информации, сервак работает и останавливать его крайне не желательно. Восстановление информации из бэкапа - гарантированные пол-суток простоя. Самое обидное, что непонятно - нужно ли вообще делать эти действия, быть может, вся инфа на разделе вполне валидная. И я попадал в эту ситуацию. Единственный плюс - начальство знало, что сервак глючит, и было морально готово к его остановке, благо, его близнец на другом краю России работал без сбоев. В случае того же ZFS/BTRFS раз в сколько-то времени в фоновом режиме по всему диску проходит демон, проверяя файловые CRC. Если что, он просто кидает мне письмо, что файлы такие-то и такие-то накрылись и резервной копии у системы нет (а бывает, что есть, и демон сам все восстановит). И, зная конкретный убитый файл, я уже буду распаковывать не весь бэкап, а только его малую часть, сэкономив кучу времени. Заодно я буду в курсе, что с файловой системой что-то не так, хотя вся аппаратура мониторинга молчит, как партизан. P.S. Если какая-то фича для вас не очевидна и не особо нужна, то это еще не значит, что она не нужна другим.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	65. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 02-Июн-12, 20:35
	> В идеальном мире из идеальных программ и идеальной аппаратуры вообще ни журналов, > ни fsck не нужно. Одна беда - живем-то мы в реальном > :) И смарт не всегда отслеживается, и рейд-контроллер глючит, и банальная > несовместимость железа при конкретной версии прошивки винта. Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения. Согласен, что она должна по возможности сопротивляться реалиям, но требовать от нее полного обеспечения безопасности хранения как минимум недальновидно по причине неминуемого падения других характеристик (скорость, простота использования, падение эффективности использования ресурсов системы) и как максимум невозможно т.к. она полностью зависит от системы, где она работает, на которую она не в силах никак повлиять. > Ок, пример из реальной жизни. Глючит рейд-контролер. Не так, чтобы вообще сплошной > мусор пишет, но иногда с ним такое случается. И до вас > это дошло только сейчас... > В случае того же ZFS/BTRFS раз в сколько-то времени в фоновом режиме > по всему диску проходит демон, проверяя файловые CRC. ... Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. > P.S. Если какая-то фича для вас не очевидна и не особо нужна, > то это еще не значит, что она не нужна другим. Я где-то написал что это не нужно? Странно что нормальные вопросы и попытки добраться до истины вещей у вас вызывают такие чувства.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (-), 02-Июн-12, 20:47
	> Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. кто будет восстанавливать запорченные реплики нормальными? Что вы тут вещаете это костыль для ФС которые не умеют этого делать. У систем безопасности юз-кейсы совсем другие и их использование мягко говоря, геморное. Как собираешься отслеживать изменение данных без поддрежки ФС? Придётся вещать кучу костылей в ОС и городить прочие подпорки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–2 +/–
	Сообщение от анон (?), 02-Июн-12, 20:57
	>> Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. > кто будет восстанавливать запорченные реплики нормальными? Что вы тут вещаете это костыль > для ФС которые не умеют этого делать. То, что я "вещаю" есть способ решения задачи. То, что Вы говорите (заметьте отсутствие хамского тона), что это костыль, еще не значит, что встроенная поддержка в ФС решает эти задачи лучше. По вашей логике, все программы надо объединить с ядром ОС и запускать всю систему как единый исполняемый файл иначе все будет в виде костылей к ядру. > У систем безопасности юз-кейсы совсем другие и их использование мягко говоря, геморное. > Как собираешься отслеживать изменение данных без поддрежки ФС? Придётся вещать кучу > костылей в ОС и городить прочие подпорки. И какие данные на сервере изменяются? БД? И как их поможет отслеживать хваленые ZFS/BTRFS?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от dalco (ok), 02-Июн-12, 20:56
	>Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения. Имеет, к сожалению. Целостность FS от всего вышеперечисленного нехило зависит. И если FS не знает о наличии проблем в аппаратуре, то это еще не значит, что этих проблем нет. >Согласен, что она должна по возможности сопротивляться реалиям, но требовать от нее полного обеспечения безопасности хранения как минимум недальновидно по причине неминуемого падения других характеристик (скорость, простота использования, падение эффективности использования ресурсов системы) и как максимум невозможно т.к. она полностью зависит от системы, где она работает, на которую она не в силах никак повлиять. А никто и не требует от FS невозможного. Просто добавили ей еще один шанс, который иногда помогает. >Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. А зачем мне изобретать велосипед, городить скрипты, когда со всем этим легко и не напряжно справится утилита из состава этой самой FS. Почему мне не нравится отдельная прога? Элементарно - FS лучше знает - где и как ей лучше себя проверять, не мешая другим, и как лучше восстановиться, не прерывая рабочего процесса (если таковая возможность есть). К тому же, подобная проверка вполне может идти на уровне ядра - т.е. быстро и без заморочек с правами.
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	72. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 02-Июн-12, 21:10
	>>Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения. > Имеет, к сожалению. Целостность FS от всего вышеперечисленного нехило зависит. И если > FS не знает о наличии проблем в аппаратуре, то это еще > не значит, что этих проблем нет. А то, что все это зависит от прямости рук админа? От этого она не должна защищать? Может и руки продублировать? Есть же предел издевательствам! Или нет? > А никто и не требует от FS невозможного. Просто добавили ей еще > один шанс, который иногда помогает. Просто не надо на этом концентрировать внимание. Добавили - хорошо. Кстати я в обсуждении имел ввиду проверку именно данных, а не внутренних данных ФС. Если вы имеете ввиду второе и спорите на счет первого, то мы не договоримся. >>Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. > А зачем мне изобретать велосипед, городить скрипты, когда со всем этим легко > и не напряжно справится утилита из состава этой самой FS. Т.е. у вас нет проблемы стабильности т.к. вы не решали ее скриптом, но задарма получая возможность это делать, вы готовы "сровнять с землей" другие решения лишь бы оправдать свое неосиляторство. Или я не прав и есть реальные доводы в пользу ФС? > Почему мне не нравится отдельная прога? Элементарно - FS лучше знает - > где и как ей лучше себя проверять, не мешая другим, и > как лучше восстановиться, не прерывая рабочего процесса (если таковая возможность есть). > К тому же, подобная проверка вполне может идти на уровне ядра - > т.е. быстро и без заморочек с правами. Лучше всего знает админ когда ему требуется проверка данных, каких конкретно данных, и насколько ему это надо (в ущерб производительности или во время простоя). Этого ФС знать не может. В ином случае это объединение решения различных задач в одном месте - комбайн. Еще раз, ИМХО CRC метаданных - хоошо, CRC данных пользователя - отчасти невозможно и полностью не нужно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от dalco (ok), 02-Июн-12, 21:39
	Хм, попробую объяснить последний раз... Есть железо, НЕидеальное железо. Есть FS, которая живет на этом НЕидеальном железе. Все, что мне от этой FS нужно - чтобы она надежно хранила данные или хотя бы сообщала, где она лажанулась. Т.е. я либо получаю от нее данные, которым я верю без дополнительных проверок с моей стороны, либо 100% же уверенность, что такой-то файл в такой-то ноде потерян. Для этого и нужно полное CRC (не только метаданные, но и сами данные). Для меня, как конечного пользователя, FS - "черный ящик". Что и как она там делает - не моя забота, главное, чтобы данные были целы. И я не должен бегать за FS и подтирать ей сопли каждый раз, когда она споткнется. Пусть выживает сама по мере сил. В случае одного-двух серверов я могу потратить время на тонкий тюнинг FS, доскональное тестирование железа и навешивание third party костылей. Когда серверов сотни, мне заниматься этим некогда. Вот отсюда и растут ноги у ZFS/BTRFS - они выживать в реальном мире научились (по крайней мере, на бумаге). P.S. Усе, иду баиньки, буду сверять CRC нейронов :)))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 02-Июн-12, 21:54
	Все, что я узнал из вашего поста - не хочу знать где как и что работает, хочу всех проверок на всех уровнях и много денег на железо, которое все это потянет. Это похоже на паранойю. Когда в меру, то все нормально ибо некоторый запас всегда должен быть, но тут уже тяжелый случай. Объяснять начиная каждую фразу "Все, что мне нужно", "Для меня", "И я не должен" и т.д. как-то странно. Не много ли зависит от Вашей личности? Вы или идеальный и безгранично опытный админ и ваша речь что-то значит, либо админ не знающий своего железа и Ваша речь не более чем болтовня и сказки. ЗЫ Спокойной ночи.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от mix (??), 02-Июн-12, 23:47
	страшно похоже на знакомую на шкуре полемику ленивого(по определению) админа и манагера ) типа - а сделайте мне красиво и бесплатно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	119. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (-), 03-Июн-12, 15:49
	тут всё прозаичнее, полемика условного технаря с ламерьём (это анон). Только ламерьё какое-то усердно-упороте попалось
	Ответить \| Правка \| К родителю #95 \| Наверх \| Cообщить модератору


	121. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 03-Июн-12, 16:28
	Прозаичнее, это да. Думаю что проблема в том, что моя точка зрения "не модная" и требует некоторых знаний, а тут попался практик (я серьезно), который не привык думать как и что работает, а привык получать результат. Это в общем-то нормально - каждому свое. Отсюда и безосновательные высказывания и призывы к тому, что он считает верным. Одно "но", его мнение и реальное положение дел - это разные вещи, что из-за "скромности" понять ему не дано. Я вполне допускаю, что я также могу ошибаться, но соглашаться со мнениями других без каких либо реальных доводов...
	Ответить \| Правка \| К родителю #119 \| Наверх \| Cообщить модератору


	128. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от dalco (ok), 03-Июн-12, 19:11
	Господа, все довольно просто. Были времена, когда мне действительно было интересно устройство каждой железки и каждой софтины в компе. Мне не влом было сотворить собственными руками какой-нибудь аппаратный или програмный прибамбас для компа. Очередной велосипед изобретался ради самого процесса изобретения. Генерилась куча кода на асме и Си ради повышения ЧСВ и просто ради фана. Но время шло, я все дальше уходил в глубины энтерпрайза... И обнаружил пренеприятнейшие вещи. Оказалось, что велосипеды не столько повышают ЧСВ, сколько приносят попоболи. Каждый велосипед надо подробно документировать, за его поведение материальную ответственность несешь именно ты, а вот бонусов никаких, кроме устного поощрения от начальства (очень изредка). К тому же, в энтерпрайзе ценятся не те решения, которые красивые, а те, что надежные, документированные,требующие минимальной поддержки и, в случае чего, легко починяемые/заменяемые не очень квалифицированным персоналом типа приходящего админа-студента. Так что теперь я копаю документацию ровно настолько, сколько необходимо и достаточно для запуска очередного "черного ящика". В случае проблем оказывается гораздо быстрее и дешевле взять аналогичную деталь со склада или типовую виртуалку из бэкапа, чем рыться во внутренностях железки с паяльником или искать в каком конфиге что слетело. Да, теперь я почти не думаю, ибо для 99% ситуаций уже готовы типовые решения. И я не бегаю со взмыленной задницей, лихорадочно вспоминая где и за какую хрень у компа XYZ надо дернуть, чтобы оно опять полетело в правильном направлении. И, самое странное, меня это вполне устраивает :)
	Ответить \| Правка \| К родителю #121 \| Наверх \| Cообщить модератору


	133. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 03-Июн-12, 22:29
	Так с этого и надо было начинать. ИМХО все хорошее начинается с велосипедов и нестандартных решений иначе было бы все одинаковое. Просто есть гарантированные общеизвестные вещи, о которых если знаешь, то становится жить легче, а то можно дойти что все проги в отладочном режиме запускать что бы ни одна ошибка не прошла мимо. А так полностью согласен, кому-то нужен результат, а кому-то процесс и/или перспектива.
	Ответить \| Правка \| К родителю #128 \| Наверх \| Cообщить модератору


	163. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (-), 04-Июн-12, 02:05
	> Так что теперь я копаю документацию ровно настолько, сколько необходимо и достаточно > для запуска очередного "черного ящика". Поздравляю, ваш мозг заржавел. Правда с этим обычно не поздравляют... > И, самое страшное, меня это вполне устраивает :) Небольшой фикс. Ибо когда мозг заржавел - это страшно. По сути это уже отработанный материал.
	Ответить \| Правка \| К родителю #128 \| Наверх \| Cообщить модератору


	136. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от Аноним (-), 03-Июн-12, 22:51
	Ваша точка зрения не требует знаний, она ровно такая же модная как и все здесь остальные. Да, были времена, лет эдак 15-20 назад, когда на любую проблему был подход подобный вашему и тогда это был модно. Подобный это найти близкую по звучанию технологию для проблемы X и пихать её куда попало, мол 'зачем решать эту проблему, мы же можем прикостылять сюда X или Y'. У некоторых даже поворачивался язык называть этот бред юникс веем. К счастью, эти времена ушли, многие успели набить на этом ишики и стали ценить технологичность решений. А о тех временах сейчас напоминает некоторое легаси и немногочисленные личности вроде вас, которые остались в своём понимании и видении развития технологий в 8х-9х годах. > который не привык думать как и что работает, а привык получать результат. а кто тут привык думать, вы чтоли? Не очень это заметно, по крайней мере, совсем не похоже что область ваших дум как-то пересекается с айти.
	Ответить \| Правка \| К родителю #121 \| Наверх \| Cообщить модератору


	138. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 03-Июн-12, 22:56
	Ваше мнение очень важно для нас. Ждите, мы сами Вам позвоним. ЗЫ Еще один аноним не умеющий читать от начала до конца.
	Ответить \| Правка \| К родителю #136 \| Наверх \| Cообщить модератору


	116. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от kurokaze (ok), 03-Июн-12, 13:56
	>Когда серверов сотни, мне заниматься этим некогда. Что, в две смены бедняга поди ишачишь? Завтра серверов старент сотни тысяч и тебе прийдется в третью смену выходить, бггг
	Ответить \| Правка \| К родителю #75 \| Наверх \| Cообщить модератору


	155. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (-), 04-Июн-12, 01:49
	> Во первых, на сколько мне известно, хранимая на винте информация п.у. имеет > избыточность в виде хранения ее CRC, которая отслеживается самим винтом. Даже круче: ECC, которая при сбое чтения пытается скорректироваться самим винтом, прозрачно для вас. В идеале фирмваре еще и проблемный сектор на резервный ремапнуть должно бы (правда у некоторых дисков оно столь тупое что убедить его увидеть сбойный сектор можно только спецпинком по болючему месту). > Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое > контроллеру. Нифига он не сообщит - если удалось починить то вы получаете данные. Если не удалось - read error. Статистика полетов - в SMART. > Во вторых, что мешает самому вычислить CRC для требуемых данных? Возможно есть > какие-либо "подводные камни" о которых я не знаю. Ничто не мешает, кроме того что ФС это может делать прозрачно и для всего, а в остальных случаях - надо явно позаботиться. > постоянном их изменении как в случае с БД, просчитать CRC вообще > будет невозможно, либо возможно, но с большими потерями ресурсов системы. Что за идиотека? Кто запретил считать CRC поблочно?
	Ответить \| Правка \| К родителю #44 \| Наверх \| Cообщить модератору


	193. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 04-Июн-12, 22:13
	> Нифига он не сообщит - если удалось починить то вы получаете данные. Если не удалось - read error. Статистика полетов - в SMART. И что вам не понравилось, будет ошибка - сообщит, будет исправимая ошибка - не сообщит. В чем проблема? Или Вам надо по каждой проблеме свой лог вести, даже если проблема и не проблема вовсе? На счет работы ЖД я в курсе. Ремап можно запустить многократной записью в сектор с большим временем доступа. Предполагаю, что с некоторыми конкретными моделями есть нюансы, но это не суть важно. > Ничто не мешает, кроме того что ФС это может делать прозрачно и для всего, > а в остальных случаях - надо явно позаботиться. dalco уже говорил, что в случае ZFS/BTRFS по диску проходит демон и проверяет CRC. Точно такого же демона (по сути, это та же программа или, с определенной натяжкой в деталях реализации, скрипт) можно сделать универсальным для всех ФС. Так зачем делать из кода поддержки ФС кухонный комбайн и жить в ожидании что какая-нибудь из тех встроенных хреновин, без которых "нельзя" прожить, не "накроет" всю информацию на винте? Из практических соображений критические области, коей по факту важности и является ФС, необходимо уменьшать и упрощать, а тут предлагают сделать разжиревшее и потенциально небезопасное с точки зрения хранения информации, мягко говоря, уродство. Ошибки надо исправлять на том уровне, на котором их возможно в наиболее полной мере исправить. Это возможно при обладании максимально полной информацией о том, чего Вы хотите. ФС этого знать не может. Можно конечно сделать механизм, позволяющей сделать это, но надо ли это все, если вполне реально обеспечить ту же функциональность другими, более универсальными, а скорее всего и не мене (если не более) эффективными средствами, в наибольшей степени отвечающим вашим потребностям. Именно по этому CRC метаданных - есть правильное решение т.к. кроме ФС, владеющей ими, о них толком ни кто не знает (и не должен) и решения должны приниматься именно на этом уровне. В случае же с данными пользователя, они принадлежат именно ему, а не ФС, именно по этому решения по их обслуживанию и само обслуживание должно приниматься и производиться им, конечно при условии, что его интересы не настолько жестко завязаны на конкретную ФС и не требуют проведения специфичных операций. В случае CRC данных пользователя никаких специфичных операций производиться не должно. > постоянном их изменении как в случае с БД, просчитать CRC вообще > будет невозможно, либо возможно, но с большими потерями ресурсов системы. > Что за идиотека? Кто запретил считать CRC поблочно? И как посчитать CRC БД так, чтобы им можно было воспользоваться, при условии, что БД все же используется, а не просто хранится? Подсказка: конечная цель всей этой "камасутры" не посчитать CRC, а установить корректность и неизменность данных, что без привлечения самой СУБД с этой БД невозможно в принципе. Даже если ФС позволяет "заморозить" данные для расчета CRC, то установить момент для "заморозки", когда дынные в БД будут в валидном состоянии, без самой СУБД невозможно. Связь же между СУБД и ФС, которая могла бы включать такую возможность, вообще маразм высшей степени.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	197. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 04-Июн-12, 23:53
	> Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое контроллеру. ему аналог CRC нужен совсем по другой причине. Чтение с физического носителя идёт с ошибками и сумму контроллер диска использует для N-кратного перечтения сектора. Только если после M попыток так и не удалось считать блок, то получается ошибка IO. Это рядовое событие для диска (в смысле, перечтение сектора) и здесь нет наложения "уровней", сумма на диске служит совсем иным целям.
	Ответить \| Правка \| К родителю #44 \| Наверх \| Cообщить модератору


	198. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 05-Июн-12, 00:45
	Во-первых, спасибо за детали работы, не знал, хоть к делу это и не имеет отношения. Во-вторых, процетирую dalco: > Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент > их появления, а не когда половина файловой системы превратится в какие-то макароны. и после моего коммента (он же): > К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели записать. Так что то, что я имел ввиду я ввиду и имел, что подтверждаете и Вы > Только если после M попыток так и не удалось считать блок, то получается ошибка IO. т.к. потеря доли информации из-за неудачного чтения эквивалентно ее испорченному состоянию. > сумма на диске служит совсем иным целям. Это да, но также она гарантирует и то, что данные считанные с диска - это те же данные, что на него и записывались. Тут же, усиленно предлагают, и за это неистово "плюсуют", ввести второй уровень проверки корректности данных на диске исходя из того, что эта гарантия не работает, причем встроить эту проверку в код работы ФС. Единственное, для чего это может пригодиться, так это для аудита системы и проверки того, что никто не изменил данные извне. Но это вообще к ФС отношения не имеет и в код включаться не должно. Также тут упоминается про ZFS и BTRFS, в которых, со слов того же dalco, имеется встроенная возможность проверки контрольных сумм файлов в ФС. Правда он заметил, что она реализована через демон и работает на уровне ядра (тут у меня есть некоторые сомнения, но разбираться не хочу за ненадобностью). Мной предлагался способ считать контрольные суммы без участия ФС, что я считаю как минимум более логичным.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	200. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 05-Июн-12, 10:50
	> Это да, но также она гарантирует и то, что данные считанные с диска - это те же данные, что на него и записывались. Не гарантирует. Кроме чтения с физического носителя есть ещё firmware котроллера самого диска, а там внутри кэш который навряд ли в лоу энде чем-то вообще защищён. И само firmware тоже нередко бывает с ошибками. HDD это уже давно не просто набор блинов. Ещё раз попробую донести смысл суммы на диске - это часть механизма общения между физ. носителем и firmware диска, и всё. > Тут же, усиленно предлагают, и за это неистово "плюсуют", ввести второй уровень проверки корректности данных нет тут второго уровня, это ваша фантазия и какое-то непонимание что, как и где нужно. > Единственное, для чего это может пригодиться, так это для аудита системы и проверки того, что никто не изменил данные извне. Аудит это совсем другая область и она не имеет отношения к суммам на уровне ФС. Суммы для аудита реализуются совсем другими методами с точки зрения реализации, у них разные временные характеристики и т.п. > Мной предлагался способ считать контрольные суммы без участия ФС, что я считаю как минимум более логичным. если вам нужно просто считать суммы непонятно для какой цели и для чего, то да, их можно считать без ФС и даже без участия каких-либо полезных данных. Тупо можно взять /dev/urandom, посчитать сумму и считать это более логичным чем суммы в ФС
	Ответить \| Правка \| Наверх \| Cообщить модератору


	204. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон (?), 05-Июн-12, 13:54
	Приведу ссылку http://rlab.ru/doc/s.m.a.r.t..html#1511 и цитату: > UltraDMA CRC Error Count > Общее количество ошибок CRC в режиме UltraDMA. > Поле raw value содержит количество ошибок, возникших в режиме передачи > данных UltraDMA в контрольной сумме (ICRC - Interface CRC). > Примечание автора. Практика, собранная статистика и изучение журналов ошибок SMART > показывают: в большинстве случаев ошибки CRC возникают при сильном завышении частоты PCI >(больше номинальных 33.6 MHz), сильно перекрученом кабеле, а также - по вине драйверов ОС, > которые не соблюдают требований к передачи/приему данных в режимах UltraDMA. Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже). Если посмотрите более внимательно то заметите, что HDD отлавливает массу ошибок как аппаратного происхождения, так и программного и, по моему мнению, данным с него можно доверять практически не проверяя (абсолютно конечно, в силу вероятностной природы самого CRC, ничто не может гарантировать, тут я согласен). Можете спорить дальше на этот счет и цепляться к тому, что не ATA единым и что SMART не связана с контроллером и чем либо еще, кроме HDD, но мне все равно, т.к. ваши оправдания в своем же лице подведомственны только специалисту (психиатру). > Ещё раз попробую донести смысл суммы на диске - это часть механизма общения между физ. носителем и firmware диска, и всё. Надо смотреть шире на вещи. Если "внутренние" гарантии (считывание с блинов и передача по интерфейсу) обеспечивают также и "внешние" (гарантия соответствия считанных данных записанным), то это так и есть. А Ваша логика - если проверяется в HDD, то кроме как в HDD это не имеет смысла. В этом плане вы не менее упоротый теоретик, на сколько упорот и практик выше по ветке, но если его можно понять, то Вас я понимать решительно отказываюсь за отсутствие желания заниматься мозговым онанизмом. > нет тут второго уровня, это ваша фантазия и какое-то непонимание что, как и где нужно. На счет своего непонимания слышу от "профессионалов" в каждом посте этой ветки, только вот беда, все доводы они основывают на личных убеждениях и уничижении других. > если вам нужно просто считать суммы непонятно для какой цели... Я даже отвечать на эти "обрубки" моего поста не буду. Если бы Вы умели читать, то поняли, что мне эти CRC никуда не вперлись и ради интереса в мотивации неприменул спросить у "виновника" этого обсуждения. Далее понеслась вся эта тупость, которую Вы безаппиляционно продолжаете.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	209. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 05-Июн-12, 22:06
	> Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже). это пример медийных ошибок, а не буфера. Точно такие же ошибки как при чтении с носителя, но вдругом месте. Откуда у вас эта трафа на счёт 'вашего буфера'? Достаточно уже кидать ссылки содержимое кторых вам не понятно. > и уничижении других. что же поделать, таков закон джунглей.
	Ответить \| Правка \| Наверх \| Cообщить модератору