LINUX.ORG.RU
ФорумAdmin

ReiserFS suxx


0

0

Ну что могу сказать. Мне таки удалось решить задачу, которую я здесь ( http://www.linux.org.ru/forum/admin/4464429 ) описывал. По мудрому совету попробовал приспособить под это дело ReiserFS. Результат – я в шоке.

Делалось следующее: поскольку скопировать все данные в разумное время не представлялось возможным никак, на source компьютере был создан loop-файл, отформатирован в ext3 и копирование производилось на него в два этапа – сначала ‘cp –a’ по живому, т.е. без остановки служб, потом остановка служб и rsync для переноса «остатков», т.е. всего того, что успело измениться за время, пока работал cp. После чего этот loop-файл одним куском был скопирован на target-компьютер, там смонтирован и запущены соответствующие службы. Но оставлять это в файле, конечно, не планировалось, поэтому был создан раздел, в который я попробовал по той же схеме (cp по живому, a потом rsync) скопировать данные и избавиться от loop-файла. И вот этот раздел я сделал в ReiserFS, думал будет быстрее. Агащазблин. Итог: полное копирование (cp) на исходном компьютере из ext3 в ext3 заняло примерно 1 сутки и 18 часов. Последующий rsync – где-то 5 часов. На target компьютере копирование из ext3 в ReiserFS заняло около недели. Специально не обламывал, чтобы посмотреть, когда же это закончится, на этом этапе время ограничено не было. Последующий rsync проработал часов 12, после чего был кильнут, поскольку сервис пора было уже запускать. Естественно, потом target раздел был отформатирован в ext3 и на него все скопировалось примерно за то же время, что и на исходном компьютере. Вот такая ерунда с этим ReiserFS, вот вам и высокопроизводительная файловая система.

Говорят, правда, что несколько ускоряет работу монтирование с опцией notail, но я не пробовал, а по тестам из интернета – да, ускоряет, но не на порядки все же, то есть из недели два дня не получилось бы по-любому. Во время копирования target разделы (и ext3 иReiserFS) всегда монтировались с опциями noatime и async, то есть быстрее уже просто некуда IMHO.

Вы чё, охренели что ли столько времени возиться с 200ГБ?

Я неодноклатно копировал ~290ГБ (музыка, фильмы, исходники, архивы) с раздела с ZFS на UFS2 и обратно — время копирования не превышало 3 часов без всякого «пиления» SWAP.

Какого размера файлы у вас преобладали?

iZEN ★★★★★
()
Ответ на: комментарий от isden

Это ещё не написали, сколько такой раздел монтируется... Я как-то тоже умников послушал, долго потом плевался.

Divius ★★
()
Ответ на: комментарий от isden

Не всё же

Итог: полное копирование (cp) на исходном компьютере из ext3 в ext3 заняло примерно 1 сутки и 18 часов. Последующий rsync – где-то 5 часов. На target компьютере копирование из ext3 в ReiserFS заняло около недели.

iZEN ★★★★★
()
Ответ на: Не всё же от iZEN

Структура такая. ~5 миллионов «уникальных» файлов, то есть занятых инод. А записей в каталогах ~40 миллионов (т.е. на каждый файл в среднем указывают 8 hard-линков). И общий объем (реальный, разумеется) ~200гиг.

shamus24
() автор топика

гониво какое-то. я гонял tar-ом через ssh с рейзера на рейзер 2-3 терабайта мелькога файла (хостинг) за ночь...

r0mik
()

Да не переживай ты так. Наверное, Линус со товарищи решили приколоться над Гансом и устроили ему регрессию.
Версия ядра какая? Почти уверен, что при откате на пару версий назад reiserfs начнет летать.

nnz ★★★★
()
Ответ на: комментарий от shamus24

А, тогда все ровно наоборот :) Видимо, редхатовцы так и не сбэкпортили нормальную бестормозную поддержку рейзера.
Я его юзаю сейчас в основном на 2.6.26, и скорость вполне устраивает. Хотя, конечно, файлы миллионами не копирую.

nnz ★★★★
()
Ответ на: комментарий от shamus24

>Структура такая. ~5 миллионов «уникальных» файлов, то есть занятых инод. А записей в каталогах ~40 миллионов
man базы данных?

power
()
Ответ на: комментарий от shamus24

О_О
присоединяюсь к выше написанному - ещё древнее не пробовал? )))

megabaks ★★★★
()
Ответ на: комментарий от shamus24

Чувак, здешняя машина времени в прошлое не работает.

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

Хорошо, что ты отписался в этом году, а то ещё через год кирдык - разница уже в пять лет, я не справился бы :(

anonymous
()

Слушай, а железо у вас какое?

Интересует дисковая подсистема. Какой-то старый десктопный хлам 10-ти летней давности?

anonymous
()

Садо-мазо какое-то :( TAR.EXE уже отменили? :)

Attila ★★
()
Ответ на: комментарий от power

Наотвечаю тут сразу всем.

man базы данных?

И чего мне с этим маном делать, если это всё — maildir?

И потом — когда оно лежало в типа базе данных (Microsoft Exchange store), оно вообще временами еле шевелилось. А так — обычные ежедневные операции выполняются весьма шустро, все довольны.

присоединяюсь к выше написанному - ещё древнее не пробовал? )))

Это насчет версии ядра? Так это...

# yum install kernel

Loaded plugins: fastestmirror

Loading mirror speeds from cached hostfile

* addons: ftp.tlk-l.net

* base: ftp.tlk-l.net

* extras: ftp.tlk-l.net

* updates: ftp.tlk-l.net

Setting up Install Process

Package kernel-2.6.18-164.11.1.el5.x86_64 already installed and latest version

Nothing to do

А гоняться по интернету за новыми ядрами я не собираюсь.

Интересует дисковая подсистема.

Чего-то сейчас подумалось - может действительно драйвер с Адаптека поставить, вместо стандартного.

kernel: scsi0 : aacraid

kernel: Vendor: Adaptec Model: ROOT Rev: V1.0

kernel: Type: Direct-Access ANSI SCSI revision: 02

kernel: SCSI device sda: 266311680 512-byte hdwr sectors (136352 MB)

kernel: SCSI device sda: drive cache: write back w/ FUA

kernel: sda: sda1 sda2

kernel: sdb : very big device. try to use READ CAPACITY(16).

kernel: SCSI device sdb: 7052687360 512-byte hdwr sectors (3610976 MB)

kernel: SCSI device sdb: drive cache: write back w/ FUA

kernel: Vendor: WDC Model: WD7500AYYS-0 Rev: 4G30

kernel: Vendor: WDC Model: WD7500AYYS-0 Rev: 4G30

kernel: Vendor: WDC Model: WD7500AYYS-0 Rev: 4G30

kernel: Vendor: WDC Model: WD7500AYYS-0 Rev: 4G30

kernel: Vendor: WDC Model: WD7500AYYS-0 Rev: 4G30

kernel: Vendor: WDC Model: WD7500AYYS-0 Rev: 4G30

kernel: Vendor: WDC Model: WD7500AYYS-0 Rev: 4G30

TAR.EXE уже отменили? :)

tar.exe не отменили, но им не быстрее - пробовал.

shamus24
() автор топика

Извините, но я это не верю.

В рейзере деревья поиска типа b+ Tree, а значит длительность одной файловой транзакции всяко не может быть в разы выше ext3.

Подозреваю, что проблемы не файловых системах, а в методике копирования, наличии избыточной синхронизации и т.д. Про старые ядра - не обращайте внимания.

shahid ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.