Сообщений в теме: 1031

[Gamma Ray]

Gamma Ray, вам нужно всего-лишь найти контроллер/материнку с такой функцией...

Порылся в биосе - нету такой функции. Походу материнка не поддерживает=(

[Andy_Scull]

Ёлки, прям кризис. Нет нормальных 2ТБ дисков для архива...
ВД и Самсунги - с кретинскими 4кб секторами (ну ладно бы сектора, так они навязывают эмуляцию в 512б для "тупых" систем без возможности отключить это)
Сигейты я брать не собираюсь после небольшого исследования.
Хитачи только дорогие и горячие 7200...
Пипец просто

п.с. кто знает, где купить 7 штук самсунгов HD203WI в Москве по ~4k - в личку, век буду благодарен.

Сообщение отредактировал Andy_Scull: 07 Октябрь 2010 - 13:18

[:-)]

Характеристики HD204UI А вот эти плохие? Они вроде по характеристикам идентичные и даже в некоторых моментах побыстрее чуток, чем HD203WI
И стоят примерно столько же ~ 3,7к HD204UI и здесь HD204UI

Сообщение отредактировал -=/Роман/=-: 07 Октябрь 2010 - 18:06

[Andy_Scull]

А вот эти плохие?

Если б не КРЕТИНСКАЯ эмуляция 4кб секторов в 512, их бы и взял.
Поясню, что имеется в виду.
Есть нормальная, "не тупая" ОС. Она видит, что на диске секторы размером Х байт (диск ей так говорит, это и есть та самая эмуляция). Она пытается сохранить один сектор данных на диск. В результате варианты -
1. как было б на обычном диске с 512 - запись сектора и всё.
2. на диске с 4096 "честными" секторами - запись сектора большего размера и всё.
3. на диске с "поддельными" 512 секторами - фигня. Диск не может сохранить отдельно 512 байт, у него сектора 4096. Он ЧИТАЕТ один сектор (4096), куда попадает наш "виртуальный" подсектор, у себя в памяти вносит в эти 4096 байт наши 512 на нужное место и пишет назад полные 4096.
Вот так я понял этот процесс. В винде дефолтный формат диска в NTFS делает программные секторы 4096 байт, поэтому её не задевает - винда всегда пишет сектором. Задевает более продвинутые файловые системы.
Чтобы разговор шел о конкретных вещах - я собрался ставить себе файлопомойку с ZFS, где-то пишут что работает, а в каких-то случаях запись падает ниже 10мб/с

Всё бы было шоколадно, если б эти г...ые производители делали опцию "отключить эмуляцию и показать реальные 4096 сектора"

Сообщение отредактировал Andy_Scull: 07 Октябрь 2010 - 21:45

[:-)]

Всё бы было шоколадно, если б эти г...ые производители делали опцию "отключить эмуляцию и показать реальные 4096 сектора"

Понятно. Не заметил что на HD203WI просто 512б без всяких эмуляций. Особо в них не разбираюсь вот лазию посматриваю, и с камланием выбираю какой-нибудь 3,5 HDD для внешнего использования. После того как стеклянный дятел от IBM умер - больше не смотрю в их сторону и сторону их приемников. Такая же песня с WD. 500 Гб брал как-то, так эта падла отработал магазинную гарантию и также полумёртвый сейчас. Работает минут 20 и зависает, но после выключения опять запускается.
Правда мои цели не такие глобальные - всего лишь нужен диск для резервного хранения важных данных.

И вопрос появился - Win7 с настройками по умолчанию постоянно включает выключает жёсткие диски, вот интересно она их не ушатает или лучше вообше выключить их отключение?

Сообщение отредактировал -=/Роман/=-: 07 Октябрь 2010 - 22:25

[Dvvarf]

Andy_Scull, не знаю, как на остальных хардах, а на WD прямо написано: диск по дефолту работает в 4КБ-режиме и только если очень хочется - можно поставить джампер в последнее окно и тогда диск будет работать в 512б-совместимом режиме (а джампера нету, что как бы намекает нам =)). У меня всё работает на NTFS-е нормально в рейде.

[Andy_Scull]

Andy_Scull, не знаю, как на остальных хардах, а на WD прямо написано: диск по дефолту работает в 4КБ-режиме и только если очень хочется - можно поставить джампер в последнее окно и тогда диск будет работать в 512б-совместимом режиме (а джампера нету, что как бы намекает нам =)). У меня всё работает на NTFS-е нормально в рейде.

WD я не верю уже, после того как они в последних прошивках отключили опцию smart'a называемую scterc (через опенсорсные утилиты smartmontools её можно выставить на Х секунд). Это как раз тот таймаут попыток перечитать ошибочный сектор, из-за которого чаще всего отваливаются десктопные диски, воткнутые в серверные рейд-контроллеры.
Кстати где-то краем глаза читал (ака слух) что этот параметр смарт входит в официальную спецификацию, и формально ВДшники нарушают её, отключая эту поддержку. Чего не сделаешь в погоне за долларами...
Вроде ещё где-то читал (тоже считайте слухом) что ВД по просьбам трудящихся выпустила-таки прошивку, которая отключала на гринах эту эмуляцию. Может как раз с этим джампером и связанную, хз. Я не расследовал до конца, может вообще "послышалось" из форумных базаров.

Если интересно - я тут в блоге писал подробнее, какие знания я вынес из своего эпичного квеста в поисках идеальной системы для файлопомойки. Уходил в него с твердой уверенностью, что достаточно купить много винтов и сунуть в рейд-5, а вернулся с сомнениями насчет прочности земной поверхности...
Я вполне мог что-то не так понять, так что на 100% верить не надо. Просто как наводка, что если уйдете в такой же квест, то обязательно стоит поискать инфу как минимум по этим же темам и проблемам. Какие-то могут быть не актуальны на то время и в той ситуации, какие-то уже по другому обходятся и тп.

Самсунги эти просто понравились по статистике магазина NewEgg. Если сравнить у них все "зеленые" 2тбайтники, то у самсунгов примерно наполовину меньше процент "очень плохих" отзывов. Вот тут начинаешь жалеть, что "Ультру" закрыли, в ней классно была сделана статистика возвратов по гарантии на каждый товар

Сообщение отредактировал Andy_Scull: 07 Октябрь 2010 - 23:17

[Dvvarf]

Если интересно - я тут в блоге писал подробнее, какие знания я вынес из своего эпичного квеста в поисках идеальной системы для файлопомойки. Уходил в него с твердой уверенностью, что достаточно купить много винтов и сунуть в рейд-5, а вернулся с сомнениями насчет прочности земной поверхности...

Интересно, почитал. Так как это не оффтоп, то свои замечания напишу сюда. В первом сообщении (и далее) вы опираетесь на то, что существует вероятность ошибки и т.д. Спешу вас обрадовать: современные диски могут жить (и часто живут) с некоторым количеством ошибок вполне спокойно не рискуя потерять информацию (в смарте часто можно увидеть страшные цифры в строке Hardware ECC Recovered, о чём подробнее - http://en.wikipedia....#Error_handling ). Поэтому вероятность ошибки != вероятность потери данных, которая, благодаря избыточности информации много меньше (к сожалению, никаких точных цифр у меня нет). Сам совсем недавно мучился вопросом как обеспечить сохранность всего, накопленного непосильным трудом. В итоге остановился на полу-софтварном варианте рейд5. Планирую, правда, когда стану очень богатым, всё переместить на полностью хардварный рейд с хорошими серверными дисками, но когда это произойдёт - пока не известно.

Вот тут начинаешь жалеть, что "Ультру" закрыли

Разделяю вашу печаль. =)

Сообщение отредактировал Dvvarf: 08 Октябрь 2010 - 00:53

[Andy_Scull]

к сожалению, никаких точных цифр у меня нет

Точные цифры мы скорее всего никогда не получим, если не потратим полжизни на то чтобы стать великими технологами в этой области... Потому как неоткуда получить сведения, какая избыточность в ЕСС (которая скорее всего разнится по брэндам), да и потом расчет вероятности я даже в мыслях не хочу представлять
Но даже если хоть 1% побитых битов может восстановить - то это уже делает недействительными все мои расчеты, и скорее всего вероятность настолько мала, что этой проблемы глупо бояться.

Что я там не написал (возможно сделаю в будущем) плохого про рейд-5, это ещё -
1. такая вещь как "write hole". Поскольку он работает с физическими блоками, то при перезаписи инфы пишет сразу поверх. Если нет контроллера с батарейкой, то при сбросе питания может на часть винтов успеть записать, на часть - нет. Получится что и прошлая инфа потеряна, и новая не записалась. А контроллер с батарейкой - это уже не "Redundant Array of Inexpensive Disks" То есть диски-то конечно и дешевые можно, но сам контроллер влетит в копеечку и батареи придется менять каждые несколько лет (о ценах вы наверное в курсе - я брал ретэйл со шлейфами за 16к, хотя сейчас не жалею - сбоев не было, и стоит он сейчас уже 20 только ОЕМ. Батарея к нему стоит больше 5к, так что я предпочел поставить ибп. не то же самое, но пока проносило).
Кстати логически рассуждая, контроллер в этом случае в кэш должен писать лог операций, чтобы после случайной перезагрузки проверял - а записался ли такой-то сектор на такой-то винт. Но наверное там тоже не дураки прошивки пишут, и именно так он и действует после загрузки.
2. "Bit Rot". Тихая - мирная деградация магнитной поверхности если её долго не обновлять перезаписью. Живешь себе, у тебя пылится образ игрушки, потом через год хочешь поставить - ах, при установке с исошника пишет что "checksum error". Просто в каком-то секторе какой-то десяток битов сменил полярность (или что у них там), ЕСС это или профукала или не смогла восстановить, и рейд-5 после такого ничем не поможет. Потерю одного диска (читай - блока из парити) он восстановит, но тут он даже не знает, на каком из винтов неправильные данные (если ему встроенная ЕСС винта не подскажет, вот этого пока не расследовал), которые хорошо бы отбросить и восстановить четностью с других винтов. Он только может сказать что данные не сходятся, и спасений от такого три - бэкапы, рейд-6 (который может эту "партию" блоков по разному просчитать и вычислить мешеющий блок), и создание ECC/PAR2 файлов к каждому залитому на массив образу.
Вот с этой проблемой я натыкался на посты людей, которые писали про побитые файлы. У самого тьфу-тьфу-ЕСС на отдельном двд хранятся

Вот что нашел в поисках винтов - http://www.taobackup.com/ (англ, но прикольно)
Ещё небольшой апдейт - вчера запускал проверку рейд-5 с контроллера, одна ошибка чтения была на весь 5ТБ. Хз, то ли я такой везучий что получил её, то ли где-то мы не так на ECC надеемся. (или может в энтерпрайзовских винтах оно тупо отрублено и передано на усмотрение контроллера, вроде что-то такое я давным-давно слышал про WD Raid Edition'ы)

Сообщение отредактировал Andy_Scull: 08 Октябрь 2010 - 08:08

[Dvvarf]

"write hole".

Абсолютно верно, есть такая фиговина. У меня контроллер недорогой (полусофт от highpoint за 4к), но поддерживает функцию Writt-Through. Выдержка из хелпа по этому поводу:

6. If you are creating RAID5, specify a cache policy for the array:
Write-back When the write-back setting is selected, writes to the array are cached. This will result in higher performance but data loss may occur in case of a power failure.
Write-through When the write-through setting is selected, writes to the array are always passed to the disks. Subsequence reads may still be completed from the cache if appropriate.

Сейчас как раз включил - один раз уже электричество отрубали, но ничего не потерялось, тьфу-тьфу-тьфу.

"Bit Rot"

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

На самом деле не так страшен чёрт, как его малюют. Конечно, всё может произойти (и происходит, например, выпадение двух дисков из массива в 5м рейде), но всё-таки вероятность этого довольно мала. Волков боятся - в лес не ходить, на все случаи жизни перестраховаться очень дорого выйдет и всё равно может произойти форс-мажор (например, протечёт крыша или верхнюю квартиру пожарники водой зальют).

Вот что нашел в поисках винтов - http://www.taobackup.com/ (англ, но прикольно)

Забавно. Интересно, сколько людей он наставил на путь истинный за эти 13 лет.

вчера запускал проверку рейд-5 с контроллера, одна ошибка чтения была на весь 5ТБ

А сколько лет массиву?
З.Ы. Поставил новую кэш-политику, провёл тесты. Чтение не изменилось, а запись: была - около 60 МБ/с, теперь - 16 МБ/с. Но безопасность важнее...

Сообщение отредактировал Dvvarf: 08 Октябрь 2010 - 13:49

[Andy_Scull]

А сколько лет массиву?

08/03/2008 Только хз, где день а где месяц
6*seagate 1TB 7200.11 ES (да-да, я везучий), все отдано на один большой помоечный раздел.

edit:
Насчет write hole я даже не кэш имел в виду. Просто нет же гарантии что (даже прямая) запись одновременно на всех винтах пройдет и закончится успешно, если отрубится питание.
На каком-то винте записалось, на каком-то нет, я так это понимаю.

Сообщение отредактировал Andy_Scull: 08 Октябрь 2010 - 13:57

[Dvvarf]

Насчет write hole я даже не кэш имел в виду. Просто нет же гарантии что (даже прямая) запись одновременно на всех винтах пройдет и закончится успешно, если отрубится питание.
На каком-то винте записалось, на каком-то нет, я так это понимаю.

Эта технология (если можно так назвать) работает таким образом: на диск пишутся данные и только после того, как всё на весь массив записалось контроллер посылает куда следует сигнал о том, что всё записалось успешно. Если во время записи произойдёт сбой по питанию, то сектора, которые возможно и были записаны полностью, не будут помечены в файловой системе как заполненные. Так что потерь никаких наблюдаться не должно.

08/03/2008

Наверное это всё-таки 3.08.2008 по-нашенски. Ну, за два года это не такой уж плохой результат, с другой стороны это же серверные диски.

Сообщение отредактировал Dvvarf: 08 Октябрь 2010 - 17:34

[Andy_Scull]

Эта технология (если можно так назвать) работает таким образом: на диск пишутся данные и только после того, как всё на весь массив записалось контроллер посылает куда следует сигнал о том, что всё записалось успешно. Если во время записи произойдёт сбой по питанию, то сектора, которые возможно и были записаны полностью, не будут помечены в файловой системе как заполненные. Так что потерь никаких наблюдаться не должно.

По моему, это только на копировании нового файла (т.е. практически - в условиях если использовать как домашнее хранилище, куда закидываешь файлы на валяние)
А вот если использовать как системный/базоданный/игровой - то уже другое дело. Как только начинаем перезаписывать какой-то файл (тот же реестр в винде или работаем с БД, или сэйв), то уже ёк - рейд-то ничего не знает о файлах, а файловая система ничего не знает о "подложенном" под неё рейде. Ось начинает перезаписывать файл поверх (ибо так быстрее, проще, и меньше фрагментации) и вот тут приходит писец.

п.с. немного уже отходя от темы, но все же про хранение. Сейчас проверяю найденный в инете метод, как ту же ZFS заставить работать с логическими секторами 4096 вместо 512 (т.е. писать как винда - минимумом по 4кб). Если получится в виртуалке - то на очереди покупка нескольких самсунгов F4 и проверка вживую.
Глядишь и рассосется моя проблема с винтами...

Сообщение отредактировал Andy_Scull: 08 Октябрь 2010 - 21:46

[Dvvarf]

Ось начинает перезаписывать файл поверх (ибо так быстрее, проще, и меньше фрагментации) и вот тут приходит писец.

Оси не нужно ничего знать - всё, что нужно знает драйвер, а в данном случае это целиком вотчина внутренней начинки контроллера. Ось над ним не властна совсем (например, дефрагментация всего рейда может на самом деле оказаться фрагментацией в физичесоком смысле, если дефрагментатор ничего не знает о том, что это рейд и как с ним работать). Начинаем писать что-то в реестр и сбой - этого изменения не будет, бд? - не будет, сейв - не будет. Зато, когда всё записалось мы точно знаем, что оно уже на диске и никуда не денется.
З.Ы. В другом случае (который побыстрее), система отдаёт в кэш контроллера данные и тот тут же говорит, что всё записал (хотя на самом деле это не так) и только потом записывает на самом деле (и если в этот момент произойдёт сбой, то у нас серьёзная проблема, потому что данные скорее всего испорчены).

Сообщение отредактировал Dvvarf: 08 Октябрь 2010 - 23:06

[Andy_Scull]

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

ммм. вот как я себе представляю этот процесс
в нормальном случае - система -> драйвер -> контроллер -> данные на винт1, данные на винт2, и четность на винт3 -> контроллер сказал ОК -> драйвер сказал ОК -> система поняла что ОК
при сбросе питания - система -> драйвер -> контроллер -> данные на винт1, четность на винт3, а вот винт2 на долю секунды запоздал -> сброс -> загрузка -> контроллер забыл что писал (без батарейки или у него это и не предусмотрено), драйвер и система обнулены

результаты -
- на дисках 1,3 уже новый блок, на диске 2 старый. Поскольку данные не в зеркале, а в р5, то для прочтения ему нужно либо правильные блоки со всех трех дисков, либо с двух и информация на каком диске запись не удалась.
- парити естественно не сходится, для контроллера блок битый. Каким данным верить - он не знает.
- логи нтфс могут помочь, если в них пишется последняя запись, какие данные и в какой сектор. Система повторяет неудавшуюся (или откатывает на предыдущее содержимое) нужные 4кбайтные сектора, и тут - ЕСЛИ контроллер тупо исполняет запись, не проверяя четность полного страйпа, где лежат эти данные - то все может восстановиться. Те сектора в страйпе, которые система не меняла, все так же неизменны, они уже лежат на диске как лежали, четность для этой части страйпа все та же, не сходится только четность того кусочка куда попал наш файл. Эти данные контроллер тупо перезаписывает прежними, оставляя остальное как есть, и все сходится.
Но вот если он посчитает четность, скажет что "ой, у вас тут битый страйп", и выдаст системе что сбойный сектор - то типа ёк. Все то, что лежало в страйпе помимо нашего файла, канет в лету. Опять же, у меня мало знаний на эту тему чтобы предсказать его поведение.

Сообщение отредактировал Andy_Scull: 09 Октябрь 2010 - 00:36

[Dvvarf]

- на дисках 1,3 уже новый блок, на диске 2 старый. Поскольку данные не в зеркале, а в р5, то для прочтения ему нужно либо правильные блоки со всех трех дисков, либо с двух и информация на каком диске запись не удалась.

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

[Andy_Scull]

1. Write-Through не имеет отношения к такому ремапу. Это же всего лишь режим работы кэша (не помню какие там особенности, что-то в духе что писать одновременно в кэш и напрямую на диск в надежде, что очень скоро эти данные попробуют прочитать?)
2. Могу поверить, что какие-то отдельные системы так делают. Что так делает винда - не верю. Иначе было бы бессмысленно дефрагментировать файл подкачки. Что так делает контроллер рейда сам по себе - тоже не верю. Нигде не видел в спецификациях, инструкциях и тп. Отслеживать все это дело он просто замается.

[Dvvarf]

1. Write-Through не имеет отношения к такому ремапу. Это же всего лишь режим работы кэша (не помню какие там особенности, что-то в духе что писать одновременно в кэш и напрямую на диск в надежде, что очень скоро эти данные попробуют прочитать?)

Нет, Write-back = контроллер сразу же отсылает сигнал о том, что он всё записал, хотя данные только в кэш поступили (я писал уже два сообщения назад), а Write-through - только когда всё на все диски запишет.

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

Тут дело не в ОСи, ещё раз повторяю, а в устройстве файловой системы. NTFS старается новые файлы писать отдельно, а не заполняя дырки. И обновляет файлы (если не доступен блок в конце файла, который нужно обновить) тоже в пустом месте. Файл подкачки - это один большой и толстый файл, всё, что в нём происходит управляется целиком ОСью (потому что файл подкачки - не огромный файл, а просто аллоцированное пространство определённого размера). Иначе фрагментация не возникала бы вовсе - под файлы бы выделялось на, допустим 5% места больше и все бы писали поверх данные и всё.
З.Ы. Это так же подкрепляется тем, что чтобы предотвратить деградацию поверхность харда нужно использовать разные части его поверхности, а не сгрудить всё в кучку на старте секторов.
З.З.Ы. Читаем - http://www.ntfs.com/.....0and Clusters
И ещё - Картинка (отсюда) и отсюда я признаю, что ошибался и это всё зависит не только от файловой системы, а от драйвера/контроллера.

Сообщение отредактировал Dvvarf: 09 Октябрь 2010 - 13:31

[Andy_Scull]

З.З.Ы. Читаем - http://www.ntfs.com/.....0and Clusters

Там разговор идет о "Later, if data is appended to the file and its size grows". Тут фрагментация естественна. Нигде не рассматривается запись без увеличения файла, т.е. перезаписываем блок внутри. Если б было по вашему - то у меня давно бы .vmdk расползся по всему винту ровным слоем, ан нет - один раз при создании дефрагментировал, и все. До сих пор одним кусочком.

Похоже, мы про разные вещи говорим. Я вам про изменение файлов, вы мне про создание новых и дописывание существующих...

Сообщение отредактировал Andy_Scull: 09 Октябрь 2010 - 15:59

[Dvvarf]

Похоже, мы про разные вещи говорим. Я вам про изменение файлов, вы мне про создание новых и дописывание существующих...

Окей, я кажется понял вашу мысль. Тогда давайте логически: за сколько может произойти запись годного блока (под блоком я подразумеваю нормальное обновление файла - в пределах нескольких МБ) на диск? Меньше, чем за несколько сотен мс? Даже если прямо в этот момент произойдёт отключение питания, то диск успеет записать блок (в свободную область подходящего размера, не по кусочкам, конечно) даже до того, как ему будет пора спасать читающие головки. Ну, а если объём обновления весьма большой, то тогда да, риск потери данных серьёзно увеличивается. Это всяко намного хуже, чем Write-back, когда есть риск потерять всё, что находится в кэше и уже посчитано как записанное системой + при этом повредить данные на диске.
З.Ы. Интересна по этому поводу проектировка БП: содержится ли там большее число конденсирующих элементов в цепях, которые рассчитаны на питание хардов?