November 17th, 2008

ext3, data=journal, прояснение

Обчитавшись ужасов про XFS ест маленьких детей портит данные, решил почитать про ext3. По крайней мере один момент не ясен, это data=journal. Вырезка из http://www.ibm.com/developerworks/linux/library/l-fs8.html#4 :
Theoretically, data=journal mode is the slowest journaling mode of all, since data gets written to disk twice rather than once. However, it turns out that in certain situations, data=journal mode can be blazingly fast. Andrew Morton, after hearing reports on LKML that ext3 data=journal filesystems were giving people unbelievably great interactive filesystem performance

В какой момент наступает "giving people unbelievably great interactive filesystem performance" ? Отчего он собственно наступает? Фразы типа "Somehow, ext3's data=journal mode is incredibly well-suited to situations where data needs to be read from and written to disk at the same time" ясности не вносят совершенно.

Кто знает, проясните пожалуйста.
  • Current Music
    ikondakov "new wave 007"
  • Tags
так и живём
  • mar1ner

Ещё раз о блэклистах

По советам сообщества порылся по ссылкам, утянул базу, показал начальству. Начальство естественно ткнуло пальцев в самую большую и сказало "прикручивай". Не всю, конечно, но большее количество разделов. А они очень не маленькие.
Вот тут то я и впал в глубокую задумчивость. Если чёрный лист закинуть в SQL, то получалось что то около пары - тройки миллионов записей и проверка одного URL занимала от 4.5 до 5 минут. сиё явно неприемлемо. Прикручивание базы к SquidGuard, даже не всей, а только раздела adult (800000+ записей) просто укладывало проксик, что для работы, естественно, не канает.
Пытался объяснить, что применение всей базы для комфортной работы не приемлимо и надо пользоваться, допустим банерорезкой и собственной базой нежелательных сайтов, но получил в ответ железный аргумент в духе "ну база то не просто так, ей же пользуются. думай!"
что посоветуете?