VictorSh
07-08-2011, 18:53
Обновил систему до FreeBSD 7.4, установил программы контроллера 3ware (в портах не нашел, нашел на ISO образе, лежащем на официальном сайте для Codeset 9.5.3), перепрошил, создал GPT раздел и сейчас синхронизируюсь с бекапом.
сейчас осталась маленькая проблема после обновления с FreeBSD 7.2 до FreeBSD 7.4 с RoundCube, но вроде бы как почта работает из почтового клиента.
Да, mergemaster - это самое сложное в процессе обновления системы :) Кое, что пришлось самому подправлять. Единственное, я отсавил на потом файлы master.passwd и group из /etc версии FreeBSD 6.2. И вроде бы пока нормально. Надо ли с ними что то делать?
Спасибо БОЛЬШОЕ за помощь :)
Сильно упрощает апгрейд, но имеет ограничение - требует GENERIC ядро »
да, и как выяснилось изучая глубины мана, что версия может быть любая, кроме STABLE, а у меня была как раз FreeBSD-6.2 STABLE
Если получится ваша затея, то можете обозвать меня вруном. »
Ну, вообщем, вы - не врун! :)))
Я все таки по одному постепенно вставлял диски на прошлой и позапрошлой неделе и они ребилдились. Массив, естественно оставался таким же. Это понятно. Бекап я сделал, но была мысль, что может и получится без бекапа. Я рассчитывал, что когда обновлю систему до FreeBSD 7.4, перепрошью контроллер, так как он видел всего лишь 746GB из 3TB от каждого диска, потом воспользуюсь функцией расширения массива, которая есть у этого контроллера, потом думал воспользоваться программой для преобразования MBR в GPT из портов, называется gdisk. После делается growfs и на этом все заканчивается, а бекап для подстраховки. НО подстраховка оказалась не зря была сделана!
После перепрошивки контроллера до новой прошики, он стал видеть новые диски как трехтерабайтные, но юнит слетел полностью!
tw_cli /c0 show показывал, что все диски в статусе OK, но там где был юнит - было пусто!!! и в таблице дисков в колонке юнит был у всех прочерк! Вот на это я не рассчитывал, я то думал, что самым сложным будет преобразование в GPT живых данных. Из-за которого придется восстанавливаться.
Cоздал массив в BIOS контроллера, и запустил tw_cli /c0/u0 start verify
Правда непонятным для меня остались, какой лучше выбрать размер страйпа. Раньше на массиве 1 ТБ было 64К, на новом 9 ТБ поставил такой же (контроллер предлагает 16К,64К,256К). Почитал гугл - все пишут по-разному. И режим StorSave выбрал balance. Режим кеша записи выбрал вкл, хотя батарейки на контроллере нет, но есть UPS на сервере.
Еще непонятно пока с программой tw_cli. Я установливал в консоли, используя setupFreeBSD7.sh, который был на диске. ОН спросил куда ставить, я ответил, что в /usr/data/3ware, так как в других папках места не было. Теперь у меня две программы tw_cli: одна старая, которая вызывается, когда я набираю просто tw_cli, а вторая новая, которая появляется когда набираешь /usr/data/3ware/AMCC/CLI/tw_cli. Хотя и старая тоже определяет все диски корректно. Можно как нибудь старую заменить новой? например, перезаписав ее?
Перепрошивал с использованием screen, хотя находился в локальной сети, на всякий случай, вдруг соединение бы потерялось.
Создал еще журнал для UFS2 на новом массиве. Вместо soft-updates. Теперь массив видится как da0p1.journal, раньше было da0.
На счет скорости записи: gstat сейчас выдает порядка в максимуме 106000 Kbps для записи на массив и порядка 35000Kbps в максимуме для чтения с внешнего винта - правда я не понимаю, почему значение для чтения сильно меньше, чем для записи, должно же быть наоборот. Ведь записываться на массив не может быстрее, чем читаться из бекапа. Скорость, чтения честно говоря не радует :( Поэтому я и хотел делать все на живых данных, так как времени нет ждать (около 20 часов). Правда сейчас, по моим расчетам, если и дальше будет так переписываться, то процесс перегонки данных (1ТБ) из бекапа на массив займет 10 часов. Может когда писалось в бекап, диски были старые Samsung, которые скорости не выдвали, а сейчас новые Hitachi. Как те, так и другие 7200rpm. Внешний диск, на котором бекап, определяется в /var/run/dmesg.boot как SATA150 (подключен через eSata), хотя сам диск и коробка поддерживают SATA3, а материнка до SATA2. То есть по идее должно быть как SATA2. Сейчас средняя скорость записи на массив 23 МБ/c.
Еще насчет размеров диска. В принципе тут почти все понятно. Было 4 диска в RAID-5, кажый по 3 терабайта. Емкость одного уходит на избыточность данных. Остается 9 ТБ. Но, при создании новой ФС и выделения места под журнал и учета, что все отображается в единицах по снованию 2, то получаются скромные 7,9 ТБ. В десятичных терабайтах 8,7 ТБ. Что-то, по-моему, 300 ГБ - немало резервируется под ФС. Для newfs я использовал флаг -m 0. На внешнем винте 3 ТБ, тоже когда он был пустой было 2,9 ТБ. То есть 100ГБ для ФС. У меня под систему винт стоит на 80 ГБ - меньше, че резервируется под ФС :)
Вообщем, я получил немалый experience, много пришлось прочитать ссылок, README и документации. Если кому понадобится могу написать полную инструкцию, как я делал.
сейчас осталась маленькая проблема после обновления с FreeBSD 7.2 до FreeBSD 7.4 с RoundCube, но вроде бы как почта работает из почтового клиента.
Да, mergemaster - это самое сложное в процессе обновления системы :) Кое, что пришлось самому подправлять. Единственное, я отсавил на потом файлы master.passwd и group из /etc версии FreeBSD 6.2. И вроде бы пока нормально. Надо ли с ними что то делать?
Спасибо БОЛЬШОЕ за помощь :)
Сильно упрощает апгрейд, но имеет ограничение - требует GENERIC ядро »
да, и как выяснилось изучая глубины мана, что версия может быть любая, кроме STABLE, а у меня была как раз FreeBSD-6.2 STABLE
Если получится ваша затея, то можете обозвать меня вруном. »
Ну, вообщем, вы - не врун! :)))
Я все таки по одному постепенно вставлял диски на прошлой и позапрошлой неделе и они ребилдились. Массив, естественно оставался таким же. Это понятно. Бекап я сделал, но была мысль, что может и получится без бекапа. Я рассчитывал, что когда обновлю систему до FreeBSD 7.4, перепрошью контроллер, так как он видел всего лишь 746GB из 3TB от каждого диска, потом воспользуюсь функцией расширения массива, которая есть у этого контроллера, потом думал воспользоваться программой для преобразования MBR в GPT из портов, называется gdisk. После делается growfs и на этом все заканчивается, а бекап для подстраховки. НО подстраховка оказалась не зря была сделана!
После перепрошивки контроллера до новой прошики, он стал видеть новые диски как трехтерабайтные, но юнит слетел полностью!
tw_cli /c0 show показывал, что все диски в статусе OK, но там где был юнит - было пусто!!! и в таблице дисков в колонке юнит был у всех прочерк! Вот на это я не рассчитывал, я то думал, что самым сложным будет преобразование в GPT живых данных. Из-за которого придется восстанавливаться.
Cоздал массив в BIOS контроллера, и запустил tw_cli /c0/u0 start verify
Правда непонятным для меня остались, какой лучше выбрать размер страйпа. Раньше на массиве 1 ТБ было 64К, на новом 9 ТБ поставил такой же (контроллер предлагает 16К,64К,256К). Почитал гугл - все пишут по-разному. И режим StorSave выбрал balance. Режим кеша записи выбрал вкл, хотя батарейки на контроллере нет, но есть UPS на сервере.
Еще непонятно пока с программой tw_cli. Я установливал в консоли, используя setupFreeBSD7.sh, который был на диске. ОН спросил куда ставить, я ответил, что в /usr/data/3ware, так как в других папках места не было. Теперь у меня две программы tw_cli: одна старая, которая вызывается, когда я набираю просто tw_cli, а вторая новая, которая появляется когда набираешь /usr/data/3ware/AMCC/CLI/tw_cli. Хотя и старая тоже определяет все диски корректно. Можно как нибудь старую заменить новой? например, перезаписав ее?
Перепрошивал с использованием screen, хотя находился в локальной сети, на всякий случай, вдруг соединение бы потерялось.
Создал еще журнал для UFS2 на новом массиве. Вместо soft-updates. Теперь массив видится как da0p1.journal, раньше было da0.
На счет скорости записи: gstat сейчас выдает порядка в максимуме 106000 Kbps для записи на массив и порядка 35000Kbps в максимуме для чтения с внешнего винта - правда я не понимаю, почему значение для чтения сильно меньше, чем для записи, должно же быть наоборот. Ведь записываться на массив не может быстрее, чем читаться из бекапа. Скорость, чтения честно говоря не радует :( Поэтому я и хотел делать все на живых данных, так как времени нет ждать (около 20 часов). Правда сейчас, по моим расчетам, если и дальше будет так переписываться, то процесс перегонки данных (1ТБ) из бекапа на массив займет 10 часов. Может когда писалось в бекап, диски были старые Samsung, которые скорости не выдвали, а сейчас новые Hitachi. Как те, так и другие 7200rpm. Внешний диск, на котором бекап, определяется в /var/run/dmesg.boot как SATA150 (подключен через eSata), хотя сам диск и коробка поддерживают SATA3, а материнка до SATA2. То есть по идее должно быть как SATA2. Сейчас средняя скорость записи на массив 23 МБ/c.
Еще насчет размеров диска. В принципе тут почти все понятно. Было 4 диска в RAID-5, кажый по 3 терабайта. Емкость одного уходит на избыточность данных. Остается 9 ТБ. Но, при создании новой ФС и выделения места под журнал и учета, что все отображается в единицах по снованию 2, то получаются скромные 7,9 ТБ. В десятичных терабайтах 8,7 ТБ. Что-то, по-моему, 300 ГБ - немало резервируется под ФС. Для newfs я использовал флаг -m 0. На внешнем винте 3 ТБ, тоже когда он был пустой было 2,9 ТБ. То есть 100ГБ для ФС. У меня под систему винт стоит на 80 ГБ - меньше, че резервируется под ФС :)
Вообщем, я получил немалый experience, много пришлось прочитать ссылок, README и документации. Если кому понадобится могу написать полную инструкцию, как я делал.