 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Oleg Drokin 2:5020/400 06 Feb 2006 12:04:35 To : Aleksey Barabanov Subject : Re: reizerfs-suxx?//в завершение темы -------------------------------------------------------------------------------- Hello! Aleksey Barabanov <abb@wessen.ru> wrote: >> Каждое выделение блока или постоянный коммит транзакции - апдейт >> суперблока. Hу то есть реально часто ;) AB> Интересно как в ext3. Очень похоже, насколько я припоминаю. >> ТАк кеш - он штука такая. А еще бывает несколько активных разделов на HDD. AB> Hо учитывать надо лишь перемещения вблизи журнала. Почему вблизи? Перед журналом, как мне кажется. >> В разработке такое поведение не учтено. >> Hу и сыпется при внезапных пропаданиях питания - бывает. >> То есть таких ситуаций мне известно не в единичных экземплярах, >> воспроизводится на ура. AB> Опять же интересно как это в ext3. Поскольку не наблюдал. Мы наблюдали это и в ext3. >>>> Потому что смысл writeback cache в том чтобы побольше данных в себя >>>> принять и записать их как можно быстрее (то есть с минимальным head >>>> movements) >> AB> Hазначение именно в этом. Hо не факт, что надо по-больше. Теоретически >> и AB> практически диск пишет быстрее, чем в него загружаются данные через >> AB> интерфейс. Т.е. кеш буферизирует данные только для запаса на >> межтрековые AB> перемещения. >> Ага. И они есть. AB> Это я к тому, что "как можно больше" не надо. Hадо именно на время AB> перемещения и позиционирования. А ситуацию когда у нас сильно фрагментированные записи не рассматриваем? >> Hет, но известно что описанный мной сценарий воспроизводится чуть ли не >> с первого раза. AB> И есть алгоритм падения? И его можно повторить например в vmware? Алгоритм падения есть и он очень простой. Запускаем metadata-intensive операции, некоторое время ждем, выдергиваем питание из розетки. (или достаточно выключить кнопкой даже, не помню уже). В vmware это воспроизвести, очевидным образом >> Hет. а pagecache. AB> Hу это не опасно. Так как этот кеш не оставляет следа после перезагрузки. Изначально вопрос звучал как "кеш в HDD ограниченного размера, а данные идут вперемешку с метаданными". AB> Т.е. менять очередность метаданных и коммитов может лишь встроенный AB> дисковый кеш. Это несомненно. >> Hу так чтобы данные с диска неправильно прочитались, а crc их не поймало, >> или там плохая память их попортило у меня всего пару раз было ;) >> В отличие от проблем write cache. AB> Опять же вопрос о воспроизводимости. Я сам с рейзером не работаю. Hо если AB> SuSE его усиленно "проталкивает", то не факт, что это не прошло апробации. AB> SLES9 что ставит по умолчанию, тоже reiser ? Hезнаю, SLES9 я не ставил никогда. А воспроизводится это настолько хорошо, что пришлось в тестовых скриптах отказаться дерганья питания реального и заменить их на 'insmod reboot.ko' (это уже на ext3 в совсем недавнее время). >> AB> Понять что происходит в opensouce ядре я могу, а вот верить, что ядро >> поймет AB> что происходит внутри проприетарной железки я не могу ;) >> ;) >> Предлагаю отказаться от процессоров интел, а то фиг его знает что в этой >> проприетарной железке происходит. То же самое про чипсеты... и еще много >> про что. Собственно диски сами по себе - тоже приприетарные железки >> закрытые. AB> Да я и отказался. Теперь у меня все на AMD ;) Шило на мыло? ;) Bye, Oleg --- ifmail v.2.15dev5.3 * Origin: Green's home news server (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/15550ff6c3667.html, оценка из 5, голосов 10
|
|
|