LINUX.ORG.RU
ФорумTalks

Ext4 такая ext4


0

3

Странное событие только что произошло - вырубился внезапно ноутбук (не настроил автовыключение), и все файлы проекта сразу стали пустыми. Благо есть git, и всё было благополучно возвращено.
**** гитовские файлы тоже покорёжило, как и один документ libreoffice.

★★★★

Последнее исправление: aptyp (всего исправлений: 1)

Ответ на: комментарий от Manhunt

PS: В Oracle, можно обойтись без фс, а развернуть базу прямо на разделе диска. Говорят работает быстрее, опять же проблему двойного кеширования решать не надо...

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

За счет чего журнал может оказаться поврежденным?

А вследствие случайного стечения ещё более случайных обстоятельств.

post-factum ★★★★★
()
Ответ на: комментарий от soomrack

Пусть была перезапись (insert тоже сопровождается всякими перезаписями, например, индексов). Тогда у тебя в файле остались старые данные, а СУБД думает, что там новые (отложенная запись), и отрапортавала в журнал, что транзакция завершилась успешно, запись в журнал физически завершилась (другой раздел, сквозная запись...).

Тебе не кажется, что разместить данные БД и журнал этой же БД на разных разделах ... это, мягко говоря, странное решение?

Manhunt ★★★★★
()
Ответ на: комментарий от post-factum

За счет чего журнал может оказаться поврежденным?

А вследствие случайного стечения ещё более случайных обстоятельств.

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

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

Тебе не кажется, что разместить данные БД и журнал этой же БД на разных разделах ... это, мягко говоря, странное решение?

Это решение есть де-факто стандарт. Причин тому много. В частности повышенные требования к надежности журнала и пониженные требования к скорости записи в него. Кроме того это очень хорошо сказывается на производительности — в журнал запись линейная и соотв. она быстро пробивает любой кеш, делая кеширование очень дорогим и глупым в плане расходования памяти (линейная запись!), соотв. вынос меньше нагружает диск — головки почти не дергаются, можно поставить максимальный размер упреждающего чтения и т.п. А вот на диске с данными часто происходит случайное чтение, которое хорошо кешируется и часто дергает головки (был бы тут журнал, головки пришлось бы дергать в два раза чаще)... Короче, оптимизация дисковой системы по скорости и по надежности для журнала и для данных совершенно разная. И совмещение этих двух типов данных на одном диске резко снижает такое узкое место все бд, как скорость работы с диском.

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

Журнал решает проблему блэкаута - и только.

Т.е. ты никогда не встречал сообщений о сильном повреждении ФС после выключения питания, когда даже fsck не помогает?

post-factum ★★★★★
()
Ответ на: комментарий от soomrack

совмещение этих двух типов данных на одном диске резко снижает такое узкое место все бд, как скорость работы с диском

Экстремальная производительность нужна отнюдь не всем.

Это решение есть де-факто стандарт.

А можешь ссылочек накидать про такую настройку СУБД?

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)

казалось бы причем тут ФС?

x0r ★★★★★
()
Ответ на: комментарий от post-factum

Т.е. ты никогда не встречал сообщений о сильном повреждении ФС после выключения питания, когда даже fsck не помогает?

Хочешь сказать, что это не баг и не неисправность аппаратуры, а именно by design?

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

Экстремальная производительность нужна отнюдь не всем.

Это не экстремальная производительность. Это правила хорошего тона, примерно, как не хранить числа в текстовы полях.

У можешь ссылочек накидать про такую настройку СУБД?

Достатчно книги Gregory Smith «PostgreSQL 9.0 High Performance». Там достатончо полно описывается настройка этой СУБД, а поскольку рассказано почему так устроено и какие из этого можно делать выводы, то применима к любой СУБД.

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

И да, в этом случае непонятно, как узнать а какие транзакции были на самом деле завершены (вплоть до физической записи на диск).

в этом случае накатывают последние n-транзакций из лога, разве нет? Называется log redo.

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

в этом случае накатывают последние n-транзакций из лога, разве нет? Называется log redo.

ну да, только нет никаких данных про необходимое значение этого n.

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

В Oracle, можно обойтись без фс

и в squid :). И ещё много где.

Речь шла про базы данных.

soomrack ★★★★★
()
Ответ на: комментарий от post-factum

А почему ты исключаешь неисключаемые факторы?

Если это часто проявляющийся баг, то его нужно поймать и починить.

Если это популярная аппаратная проблема, то специально для нее нужно предусмотреть какой-то воркэраунд в алгоритмах.

А оправдывать собственное кривое поведение тем, что всё равно нас всех съедят неведомые трудности — неспортивно. Если уж всерьёз думать о всевозможных сбоях неизвестного происхождения, то это к таненбуаму надо с его микроядром..

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

никто. вообще никогда не имел проблем с файловой системой. почитаю на досуге мануалы.

aptyp ★★★★
() автор топика
Ответ на: комментарий от soomrack

только нет никаких данных про необходимое значение этого n.

А сколько есть в логе столько и накатывается, например.

В общем, в любом случае любая СУБД расчитывает что до какого-то момента времени ничего не терялось. Имхо, это то к чему должны стремиться файлухи. Впрочем, ответ вроде как уже звучал, data=journal.

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

Это не экстремальная производительность.
Gregory Smith «PostgreSQL 9.0 High Performance»

Таки это High Performance. То есть актуально для серверов, где и в самом деле должно быть резервное питание.

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

сделал. насчёт второго почитаю.

aptyp ★★★★
() автор топика
Ответ на: комментарий от true_admin

А сколько есть в логе столько и накатывается, например.

Правильно, по максимуму, но только не факт, что этого хватит.

В общем, в любом случае любая СУБД расчитывает что до какого-то момента времени ничего не терялось. Имхо, это то к чему должны стремиться файлухи.

Да.

Впрочем, ответ вроде как уже звучал, data=journal.

Ну вообще-то этого мало. Все-таки это только защита от потери данных вследствии ошибок фс, но никак не защита от потери данных вследствии БП.

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

/etc/fstab *теперь* выглядит так -

 /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda5 during installation
UUID=2df64c86-d83f-4dba-800d-699a1b3bb259 /               ext4    data=journal,errors=remount-ro 0       1
# /home was on /dev/sda2 during installation
UUID=8cfaad2a-6b68-46b6-99ac-6def5ea87e26 /home           ext4    defaults,data=journal        0       2
# swap was on /dev/sda7 during installation
UUID=c0080c5e-7580-4362-a38c-75b20a107555 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

, добавил data=journal.

aptyp ★★★★
() автор топика
Ответ на: комментарий от red_eyed_peguin

это надо обладать ненастроенным авесомом, ноутбуком с убитой практически батареей и интересной задачей; заряд виден, если только htop запустить:-) ем кактус, да.

aptyp ★★★★
() автор топика
Ответ на: комментарий от Manhunt

Таки это High Performance. То есть актуально для серверов, где и в самом деле должно быть резервное питание.

В книгах по High Performance пишут сразу и только про High Performance? В книгах «%theme% для профессионалов» пишут только для профессионалов (и для профессионалов ли вообще)?

Линейный лог убивает кеш. Все, на диске где лог, кеширования фактически нет. Это не high performance. Это тупо логика, как не стрелять себе в ногу, не ссать в штаны на морозе, не ездить в Бабищево и т.д.

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

добавил data=journal.

мало поможет. Лучше сделай еще

# echo 0 > /proc/sys/vm/dirty_background_ratio

Не очень хорошо скажется на производительности (эффекта скорее всего ты не заметишь), но зато данные будут начинать писаться на диск сразу же как только будет их изменение.

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

Линейный лог убивает кеш. Все, на диске где лог, кеширования фактически нет.

Может быть, это зависит от размеров лога и от доступного объема оперативы?

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

Да ничего интересного что то, в syslog по крайней мере. Не пойму какой временной интервал кидать. На лоре дата показывается московская?

aptyp ★★★★
() автор топика
Ответ на: комментарий от Manhunt

Может быть, это зависит от размеров лога и от доступного объема оперативы?

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

Впрочем посмотри размер своего лога и если такая потеря памяти тебя устроит — as you like. + не забывай про диск, кеш это половина проблемы.

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

Если это часто проявляющийся баг, то его нужно поймать и починить.

И вот тут ты должен много раз выключить питание, поймать баг и починить его!

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

И вот тут ты должен много раз выключить питание, поймать баг и починить его!

Внутри qemu - почему бы и нет?

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

Обычно линейный лог быстро превышает пределы доступной оперативной памяти

Хм. А вот тут http://www.postgresql.org/docs/9.1/static/wal-configuration.html пишут иначе:

There will always be at least one WAL segment file, and will normally not be more than (2 + checkpoint_completion_target) * checkpoint_segments + 1 or checkpoint_segments + wal_keep_segments + 1 files. Each segment file is normally 16 MB (though this size can be altered when building the server). You can use this to estimate space requirements for WAL. Ordinarily, when old log segment files are no longer needed, they are recycled (renamed to become the next segments in the numbered sequence). If, due to a short-term peak of log output rate, there are more than 3 * checkpoint_segments + 1 segment files, the unneeded segment files will be deleted instead of recycled until the system gets back under this limit.

То есть ожидаемый суммарный размер файлов - 160 Mb. Не смертельно для машины с 2+ Гб оперативы.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от soomrack

опять же проблему двойного кеширования решать не надо...

O_DIRECT же

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

То есть ожидаемый суммарный размер файлов - 160 Mb. Не смертельно для машины с 2+ Гб оперативы.

Вообще-то это значение очень неприятно. От 2Гб по дефолту только 20 (vm.dirty_ratio) под кеш фс уодит (и это значение не случайно) это 400Mb, больше трети из этого ты хочешь просто выкинуть? + Опять же под лог стараются выдать побольше (глубина отката, скорость работы,...). На ноуте у меня для сегментов выставлено значение в 32. На серваке в 64.

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

Странно. Вообще-то рекомендованный способ решения - опция nodelalloc, но в 3.2 должны быть патчи, которые уменьшают вероятность самой проблемы.

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

только нет никаких данных про необходимое значение этого n.

(ковырял недавно устройство журнала в reiserfs)
У журнала есть кольцевой буфер и заголовок журнала, отдельным блоком. Все транзакции пронумерованы. Когда нужно что-то писать на диск, формируется транзакция (заголовок, блоки на запись и завершающий блок), в ней прописываются: номер текущей транзакции и блоки, которые надо записать. После того, как данные упали в кольцевой буфер журнала (sync), обновляется номер последней завершённой транзакции в заголовке журнала и её позиция в кольце. После этого данные пишутся на диск в назначенные места.

При монтировании раздела журнал сканируется вперёд, и, если встречаются данные, похожие на транзакцию с порядковым номером больше, чем номер в заголовке журнала, данные транзакции пишутся на диск. И так пока транзакции не кончатся. Так вычисляется это самое n.

Ну и к тому прибавляются разные хитрости вроде склеивания маленьких транзакций в одну.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

При отложенной записи СУБД считает что был sync диска (данные физически записались), в то время как на самом деле его не было.

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

Я писал о том, как делается journal replay, а именно о том, как определяется, сколько записей надо проигрывать.

При отложенной записи СУБД считает что был sync диска (данные физически записались), в то время как на самом деле его не было.

Я теперь знаю, как делается журналирование (раньше как-то не задумывался над этим), и как writeback в контроллере диска может обломать это самое журналирование.

i-rinat ★★★★★
()

Регулярно вырубается системник при скачках в сети, в среднем больше одного раза в неделю. При критических перегревах тоже вырубается. Раньше иногда при загрузке не врубалась видуха, приходилось самому ресетить. Система на ext4, основной пользователь на ext3, дополнительные файлопомойки на ntfs и fat32. Такого страха как у тебя не припомню. Иногда мог повредиться какой файлик или кэш устраивал машину времени: вроде бы файлы от старой компиляции давно удалены а они линкуются. Похоже и у тебя чудят кэши - слишком редко синхронизируют своё содержимое с носителями информации, как при использовании дискеты. Попробуй отключить всякие тормозящие винт непомуки, tracker-extract и проверить содержимое /etc/fstab

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

nepomukи кстати могут быть,т.к. кде тоже поставлено, tracker-extract нет, /etc/fstab да, посмотрю)

aptyp ★★★★
() автор топика
Ответ на: комментарий от soomrack

От 2Гб по дефолту только 20 (vm.dirty_ratio) под кеш фс уодит

под кэш фс (page cache) уходят все доступные страницы памяти. А dirty_*_ratio регулирует поведение грязных страниц.

Кроме того, есть background_ratio. Я бы рекомендовал маленький vm.dirty_background_ratio и высокий vm.dirty_ratio (для борьбы с внезапными нагрузками, расчёт на то что в среднем диск пишет быстрее чем прибывают новые данные и до vm.dirty_ratio не дойдёт). С маленьким dirty_ratio это будет напоминать mount -o sync (имхо).

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

под кэш фс (page cache) уходят все доступные страницы памяти. А dirty_*_ratio регулирует поведение грязных страниц.

Интерес для сохранения данных при БП представляют только грязные страницы. И vm.dirty_ratio это показатель который система не превысит, т.е. больше чем (vm.dirty_ratio)% грязных данных не будет. vm.dirty_background_ratio — это показатель с начиная с которого начинается фоновая запись грязных страниц.

Я бы рекомендовал маленький vm.dirty_background_ratio и высокий vm.dirty_ratio

Обнулять vm.dirty_background_ratio тоже не рекомендуется и вообще, делать его надо сравнимым с размерами блоков в фс, т.е. в некоторых случая и под 1 gb будет хорошо. Высокий vm.dirty_ratio точно делать не нужно — ибо это отнимет ценные мегабайты оперативки у чистого кеша (чтение данных) и у софта. Можно вспомнить нормальное распределение и взять этот показатель равным трем объемам записей за единицу времени при средней скорости, и надеяться, что цпт тут применимо.

С маленьким dirty_ratio это будет напоминать mount -o sync (имхо).

абсолютно верно

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

ибо это отнимет ценные мегабайты оперативки у чистого кеша

а кто сказал что эти страницы не будут читать? Да и не поможет это сохранить кэш, туда в любом случае попадает последнее записанное/считанное. Алгоритмы типа LRU для page cache не захотели внедрять, хотя попытки были.

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

а кто сказал что эти страницы не будут читать? Да и не поможет это сохранить кэш, туда в любом случае попадает последнее записанное/считанное. Алгоритмы типа LRU для page cache не захотели внедрять, хотя попытки были.

Если это запись линейного лога, то читать их будут ой как редко.

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

Если это запись линейного лога, то читать их будут ой как редко.

Что ещё за линейный лог? :) Мы же про БД говорили. Там журнал+данные.

А для лога можно и O_DIRECT, только вот софт что-то не торопится это использовать.

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