[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Надежность LVM (ext3 vs lvm и ext3)



Mikhail A Antonov <bart@solarnet.ru> wrote:
> [-- text/plain, кодировка base64, кодировка: KOI8-R, 26 строк --]

> 29.03.2012 19:01, Andrey Melnikoff пишет:
> > Ну со свопом сейчас уже всё трудно. Его можно и не делать более 2Gb. Если
> > нужно - можно с помощью dphys-swapfile по ходу создавать его.
> > Но как показывает моя практика - для тяжелонагруженой машины с достаочным
> > количеством свопа и памяти - своп иногда вреден. 2.6.32 ядро иногда начинает
> > заниматься sawp-trashing'ом - при достаточном объеме памяти выдавливать всё
> > в своп. Работать в эти моменты просто невозможно.
> Обрати внимание на vm.swappiness. Вероятно может помочь.
Там стоит 90, памяти - 7 гигов. Свопит, пока не забьет весь своп или я
просто с консольки не скажу swapoff -a. Других решений у меня нет.

> > А теперь можно поязснить - зачем такая шинковка диска в капусту? И зачем тут
> > lvm? Если хочется нашинковать диск на кучку мелких обломков - для этого есть
> > GPT (128 записей о разделах должно хватить на любые извращения). Лишний
> > уровень абстракции? Для чего?
> На сколько я помню, GPT умеет не всякий BIOS, да и даст ли мне GPT на
> лету поменять размеры разделов? Снапшоты? Миграцию с диска на диск?
Снапшоты? ext3? на ходу? Да-да, каждый день наблюдаю:
....
ext3_orphan_cleanup: deleting unreferenced inode 4826057
ext3_orphan_cleanup: deleting unreferenced inode 1769475
EXT3-fs: dm-3: 75 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: checktime reached, running e2fsck is recommended
EXT3 FS on dm-3, internal journal

Особливо в этом (это тазик promox'ом и openvz виртуалками) умиляет, что в
одной из виртуалок таким методом бакапиться mysql. Хорошо, что это еще ни
разу не падало и _ЭТИ_ бакапы не пользовались.

> А шинковать удобно за тем, чтобы Вася из отдела "А" замусорив раздел для
> "А" не мешал при этом остальным отделам работать. А уж внутри отдела
> найти виновника и поручить самому отделу разобраться так ли им нужны все
> эти файлы не сложно. Можно квотами сделать, но квоты не дадут снапшотов
> и миграцию. И то и другое временами используется.
Видимо, у меня другой workload. Васей много, но все они забивают общий 2T
md1 рэйд. Как только кончиться место - винты будут выкинуты (почищенный от
мусора, сложены в коробочку и спрятаны в шакп с надписью "внеочередной
бакап на DD/MM/YYYY") и будут воткнуты более толстые винты. В выходные никто
не работает, rsync данные перетянет.


Reply to: