Дефрагментация Raid 0

Нигде нет однозначного ответа на вопрос, дефрагментировать Рейд-0 или нет, а если и дефрагментировать, то чем? Может здесь есть знающие люди? У меня Рейд 0 из двух хардов.

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

Просто появились проги, которые типа могут, но также есть пострадавшие, у которых накрылась или замедлилась винда.

Для начала, есть ли хоть какая-то реальная польза от Raid0 обычному юзеру, очень большой вопрос. Выигрыш в скорости должен достигаться при одновременном обращении к двум винчестерам, а при каких условиях это достигается? Например, при одновременной работе двух и более программ, которые активно обращаются к винчестеру. Это условие выполняется? Сомневаюсь, что для DCS такое нужно.

Далее, классический винчестер в основном тратит время на перемещения головок. Порядок величин такой (очень грубо, точныз цифр я сейчас не помню): 10мс на перемещение, 0.1мс на чтение 4k. Один мегабайт мы можем прочитать так:

одно позиционирование, 256 чтений = 35мс (последовательное крупноблочное чтение)

256 позиционирований, 256 чтений = 2585мс (случайное мелкоблочное чтение)

разница гигантская.

И если у вашего raid0 единица размещения мелкая, а чтения крупноблочные, будет только вред.

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

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

Для железного RAID нет стандартного способа работать с физическим представлением геометрии. При дефрагментации внешнего представления штатными средствами данные не потеряются, но в физическом представлении данные вполне могут расположиться не оптимально.

Чувак, разница видна даже тупо по времени загрузки игор.

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

Для железного RAID нет стандартного способа работать с физическим представлением геометрии. При дефрагментации внешнего представления штатными средствами данные не потеряются, но в физическом представлении данные вполне могут расположиться не оптимально.

У меня простой Рейд с материнки, без всяких pci express плат. Мне бояться или нет? Хотя замедления работы у меня пока нет. Так, на будущее.

vvm13

RAID0 всегда будет быстрее чистого диска, причем реально примерно кратно количеству дисков на любых операциях.

У меня простой Рейд с материнки, без всяких pci express плат. Мне бояться или нет? Хотя замедления работы у меня пока нет. Так, на будущее.

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

Мне бояться или нет?

С RAID-0 - бояться и постоянно делать бэкапы если данные на таком разделе имеют хоть какую-то ценность.

нет однозначного ответа на вопрос

Фрагментация файлов однозначно плохо влияет на скорость чтения файлов с жёсткого диска, независимо от размещения раздела на RAID или нет.

На флеше конечно это не так критично, т.к. там время поиска почти нулевое и дефрагментация практически становится не нужна.

vvm13

RAID0 всегда будет быстрее чистого диска, причем реально примерно кратно количеству дисков на любых операциях.

Просто потому, что вы так сказали? Я уже объяснил, как оно работает. Какие-нибудь обзоры с IOMeter и тому подобным не являются опровержением того, что я сказал.

Ситуация в точности как многоядерными процессорами (или хуже, потому что надо ещё про allocation size помнить и ещё о кое-каких вещах). Неважно, сколько у вас дисков, если в единицу времени используется один. Удаётся ли использовать более одного - это вопрос.

С RAID-0 - бояться и постоянно делать бэкапы если данные на таком разделе имеют хоть какую-то ценность.

Без RAID-0 - аналогично.

Без RAID-0 - аналогично.

Полностью согласен :yes:

Просто потому, что вы так сказали? Я уже объяснил, как оно работает. Какие-нибудь обзоры с IOMeter и тому подобным не являются опровержением того, что я сказал.

 

Ситуация в точности как многоядерными процессорами (или хуже, потому что надо ещё про allocation size помнить и ещё о кое-каких вещах). Неважно, сколько у вас дисков, если в единицу времени используется один. Удаётся ли использовать более одного - это вопрос.

Не, чистая теория без всяких иометров и прочего. Предположим что RAID0 из двух дисков, кэша ни в контроллере, ни в дисках нет чтобы на заморачиваться на помещающиеся в кэш мгновенные операции, скорость последовательного чтения/записи 128М в секунду, время позиционирования головок 0.01 секунды. Пишем гигабайт, контроллер положит по 512M на каждый диск, причем писать будет одновременно на два. Выходит запись будет длиться 1024M/(2*128M)=4 секунды вместо 1024M/(1*128M)=8 секунд. Положит он подряд первую половину на первый диск и вторую на второй или же размешает это хоть побитно не имеет значения. Теперь предположим что будем читать тот же гиг блоками по 1M физически раскиданными по всему диску, считаем что для каждого блока требуется орерация позиционирования головок, даже предположим что контроллер тут ничего не пытается соптимизировать. Получается общее время позиционирования tp = 1024M (общий объем)/1М (размер блока)*0.01 (время одного позиционирования)=10.24c, общее время чтения tc = 1024M (общий объем)/128M (скорость последовательного чтения, внутри блока данные идут последовательно)=8с. В случае RAID0 мы делим tp и tc на количество дисков так как операции идут одновременно на всех дисках.

Без RAID-0 - аналогично.

Не аналогично, а вдвое страшнее поскольку вероятность умирания одного из двух дисков вдвое выше чем вероятность умирания одного диска, а с половины данных толку нет. У меня тут RAID5 из 7 дисков развалился - большая часть данных как-бы есть, но большинство файлов содержат неправильные фрагменты.

Вероятность умирания хотя-бы одного диска больше почти в два раза) Она меньше двух.

Блин, не двух, а меньше чем в два раза.

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

так а это...

контроллер же не отдает реальную геометрию дисков, подсовывает логическую

и для винды вроде все дефрагментировано, а по факту головы все равно за файлами по всему винту будут бегать

ибо как их там контроллер рассовал, про то винде не ведомо

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

Не суть, всем спасибо за ответы.:)

Кстати даже не так, вероятность вычахания M элементов из N линейна при любом N если M=1.