Сабж. Пока только консольный, но вполне себе рабочий. При написании использовались православные инструменты- QtCreator, KDevelop и gdb.
Полная новость на швабре: Сами найдете, неохота эту мерзость сюда тащить.
Эдуард Шишкин объявил о выходе патчсета Reiser4 для Linux 3.10, в котором, кроме адаптации кода для новой версии ядра, была исправлена ошибка, приводящая к краху при хранении данных в сжатом виде.
>>> Подробности
Есть процессор с corei5 430m на борту.
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 37
Model name: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz
Stepping: 2
CPU MHz: 1733.000
BogoMIPS: 4522.44
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 3072K
Проблема в том, что разные версии компилятора (4.6.4 и 4.8.1) советуют ставить разные флаги,
4.6.4 l2-cache-size=3072, l1-cache-size=32, l1-cache-line-size=64
4.8.1 --param l2-cache-size=256, но l1-cache-size=0, l1-cache-line-size=0
Какие лучше значение установить?
Собрал себе 3.11-rc3 c UKSM, потребление памяти упало в разы.
Покрутил infinality и вроде стало меньше мыла.
Думаю ещё chromium пересобрать для полного счастья.
Если ibiru ответит на мыло думаю на его сервере это не займёт много времени.
А ещё купил себе бумажную книгу, которая тоже попала в кадр.
png для ценителей
http://ec2-54-229-117-209.eu-west-1.compute.amazonaws.com/party.html
Кому скучно, может попробовать открыть. ))
Под 22-м фоксом вешает напрочь как фокс, так и иксы, после чего оба падают, в линукс. Под виндой повесило систему на некоторое время, тоже фоксом. Но без фатальных последствий. Под мак сам фокс предложил снять сценарий.
Надеюсь, меня не забанят )
Вышел первый публичный релиз утилиты резервного копирования с глобальной дедупликацией zbackup. Программа находит области, содержащие одни и те же данные во всех сохраняемых в неё образах, и сохраняет их только один раз. Данные затем сжимаются и, по желанию, шифруются. Оптимально подавать на вход один большой .tar файл, содержащий полный бэкап системы, или же непосредственно сырой образ диска, подлежащий резервному копированию - программа не пытается интерпретировать формат файла, а просто дедуплицирует любой полученный от пользователя. Дедупликация глобальна - данные, полученные в разное время из разных образов, сохраняются только один раз. За счет этого достигается высокая инкрементальность и низкие затраты дискового пространства.
Для достижения данной функциональности программа использует кольцевую хэш-функцию со скользящим окном для побайтной проверки на совпадение с уже существующими блоками данных, наподобие того, как это реализовано в программе rsync.
( читать дальше... )
Домашняя страница программы: http://zbackup.org/
Страница разработки на github: https://github.com/zbackup/zbackup/
После 8 часов работы компьютера все tcp запросы идут жэсточайшэ долго на любой хост. провайдер - byfly
curl -v http://www.google.by
netstat -np | grep -i curl
> tcp 0 1 192.168.0.3:59216 173.194.40.87:80 SYN_SENT 13244/curl
sudo grep -i "173.194.40.87" /proc/net/ip_conntrack
> 104 SYN_SENT src=192.168.0.3 dst=173.194.40.87 sport=59216 dport=80 [UNREPLIED] src=173.194.40.87 dst=192.168.0.3 sport=80 dport=59216 secctx=null use=2
конфигурация генты дома такая же, как и на работе. но на работе другой провайдер и комп работает месяцами без проблем.
есть достаточно знаменитый тред. читал и кивал головой. вродебы они пришли к тому что «Ephemeral Port Range» нужно изменить
sudo cat /proc/sys/net/ipv4/ip_local_port_range
>32768 61000
описанными в треде портами 3127-3198 тут не пахнет. и как этот промежуток изменить, чтобы syn_sent не бесил?
ну или может какой-то другой костыль вставить?
пытаюсь заставить grep показать строку, в которой есть Y, но перед ним нет X
grep [^X]Y не показывает строки, в которых есть Y. не могу понять
Появился новый планировщик задач, основанный на коде BFS (Brain Fuck Scheduler), но с возможностью использования нескольких очередей выполнения.
BFS сам по себе использует только одну очередь выполнения для всех CPU. Это позволяет избежать накладных расходов на балансировку нагрузки, но не очень хорошо масштабируется.
Какие преимущества у нового планировщика по сравнению с другими планировщиками?
Какие у него недостатки по сравнению с другими планировщиками?
>>> Подробности
Не спрашивайте - зачем. Просто так, потому что можно. Ну и к тому же можно ссылаться на этот топик в ответ на вбросы бздунов насчёт «а этот ваш Линукс умеет ZFS?». Умеет, как видите.
Краткий мануал по красноглазию:
1) Создаём раздел для ZFS. После этого потребуется создать пул. Пул - это что-то вроде виртуального устройства.
zpool create zero /dev/sda2«zero» - это моё название пула. У вас оно может быть любым другим. Просто создать пул как-то неинтересно, поэтому повключаем всякие разные плюшки ZFS. Включаем дедупликацию:
zfs set dedup=on zeroи сжатие:
zfs set compress=lzjb zeroи отключаем обновление временных меток:
zfs set atime=off zeroну и отключаем монтирование средствами самой ZFS дабы избежать неудобств на стадии сборки системы в chroot:
zfs set mountpoint=legacy zero2) Теперь у нас есть чистый пул, но пул - это ещё не ФС. Чтобы установить туда систему, нужно создать файловые системы на этом пуле. Прелесть ZFS в том, что на одном пуле можно создать кучу ФС, каждой из которых можно задать свои опции. Например, я создал ФС для корня (и уже при создании говорим zfs, что монтировать создаваемые ФС мы будем вручную через mount):
zfs create -o mountpoint=legacy zfs/systemЭта ФС унаследовала все опции (дедупликация, сжатие) от пула, потому что для корня такие опции, в общем-то, неплохи. Далее я создал ФС специально для дерева portage, оверлеев и каталога с исходниками ядра:
zfs create -o mountpoint=legacy zfs/srcТак как на этой ФС будет куча текстовых файлов, обращаться к которым придётся сравнительно редко, здесь имеет смысл задействовать несколько иные опции. Например, усилить сжатие (после дефиса указана степень сжатия, диапазон - от 1 до 9, по умолчанию 6):
zfs set compress=gzip-9 zero/srcи отключить дедупликацию (мне подумалось, что дедупликация на ФС с тоннами мелких файлов будет сильно отжирать ресурсы, да и сильное сжатие вполне экономит место):
zfs set dedup=off zfs/srcОтдельная ФС для /home:
zfs create -o mountpoint=legacy zero/homeОпции пусть будут унаследованы от пула. Далее я перестраховался и создал отдельную ФС для /var, потому что в какой-то там рассылке видел упоминание каких-то багов при дедупликации на /var. Посты были датированы ещё прошлым годом, с тех пор утекло много воды, но бережёного случай бережёт:
zfs create -o mountpoint=legacy zero/var
zfs set dedup=off zero/var3) Далее у нас стандартная сборка Gentoo. Монтируем будущий корень:
mount -t zfs zero/system /mnt/systemи остальные ФС:
mount -t zfs zero/src /mnt/system/src
mount -t zfs zero/home /mnt/system/home
mount -t zfs zero/var /mnt/system/var
mount /dev/sda1 /mnt/system/bootПосле чего монтируем нужные виртуальные ФС (proc, dev, sys), монтируем хранилище архивов с исходниками пакетов, в общем, всё по хэнбуку, поэтому не стану заострять на этом внимания. Внимание требуется на этапе установки и сборки ядра. Устанавливать нужно это милое ядрышко (перед этим нужно будет включить флаг zfs, я думаю, разберётесь сами):
layman -a init6
emerge geek-sourcesНа этапе сборки ядра нужно учесть некоторые детали. Например, в мануалах написано, что нужно включить опцию CONFIG_KALLSYMS и отключить CONFIG_PREEMPT (т.е. установить её в значение «Server») Первую-то я включил, а отключать вторую меня жаба задавила (эта опция влияет на отзывчивость ядра), тем более что на Гитхабе я читал, что в последних версиях zfsonlinux проблемы с этой опцией ядра устранены. После этого, конечно, включаем SPL и ZFS. Первая опция находится прямо в корне конфигуратора, а вторая - в секции «File systems». А вот далее важно не пойти на поводу мануалов Гитхаба, ибо это чревато феерическим ментальным трахом. В мануалах тех написано, что нужно добавить указанный там оверлей и установить оттуда особые версии dracut и genkernel для сборки initramfs с поддержкой ZFS, ибо даже жёсткое включение ZFS в ядро не позволяет загрузить систему с корня ZFS (нужны утилиты для работы с ZFS, которые должны находиться в initramfs). Собственно, я так и сделал. После чего на протяжении дня сношался с кривоглючным dracut, упорно не желавшим включать утилиты ZFS в initramfs. Я даже вытягивал какие-то древние версии dracut и устанавливал их через make install, потом уже добавлял нужные файлы в initramfs вручную - чего я только ни делал! А оказалось, что нужно было тупо забить на эти горе-мануалы и установить самый стандартный genkernel из официального дерева. И всё правильно собирается следующей командой:
genkernel all --no-clean --makeopts=-j16 --zfs --bootloader=grub2вот и вся недолга. Если перед этим вы успели собрать и установить Grub2, то genkernel сам добавит в grub.cfg нужные опции (укажет ФС, с которой грузить систему, в моём случае это zero/system).
На стадии формирования списка загружаемых демонов нужно сделать следующее:
rc-update add zfs boot
rc-update add zfs-shutdown shutdown4) Монтирование файловых систем ZFS. Вообще, монтировать их можно двумя способами: посредством утилиты zfs через задание точки монтирования:
zfs set mountpoint=$DIR $FSили через fstab с предварительным отключением автомонтирования:
zfs set mountpoint=legacy $FSЗапись в fstab для, например, корня, не содержит ничего сверхъестественного:
zero/system / zfs noatime 0 0Способ монтирования выбирать вам. Следует лишь иметь в виду, что при монтировании через fstab zfs-shutdown будет ругаться при выключении.
5) Вообще это нужно делать раньше, но, в принципе, пофиг:
hostid > /etc/hostid (это в chroot)
cp /etc/zfs/zpool.cache /mnt/system/etc/zfs6) Если у вас меньше 2 Гб оперативки, то ZFS своим кэшем может сожрать всю раму и завесить систему. Поэтому имеет смысл ограничить её аппетиты:
echo "options zfs zfs_arc_max=512M" > /etc/modprobe.d/zfs.confЯ выставил 1 Гб.
7) Отмонтируем все ФС, делаем
zpool export zeroи перезагружаемся в свежую систему. Не знаю, как получится у вас, а лично у меня initramfs не может импортировать пул и потому вываливается в busybox. Не проблема, входим в его шелл и импортируем пул вручную:
zpool import zero
exitи система далее нормально загружается.
Какие профиты? Ну, она явно быстрее ранее используемой мной Btrfs. Опять же, на Btrfs нет дедупликации, и сжатие можно применить/отключить только на весь раздел. Сжатие lzjb не так заметно экономит место (это просто быстрый алгоритм), а вот gzip-9 сжал дерево portage с 350 Мб до 256 Мб, а каталог исходников ядра - так вообще в 2 раза, с 800 с лишним Мб до 400 с лишним. Причём на скорости сборки ядра это практически не отразилось (замерял через time). А ещё в ZFS есть контрольные суммы, так что о целостности системы можно вообще не беспокоиться. Но самое главное, конечно - это снапшоты. Я, попробовав раз снапшоты ещё в Btrfs, так и не смог от них отказаться.
Маленькое дополнение: почитав преисполненные страха комментарии про снижение скорости из-за дедупликации я её таки отключил на всех ФС. И ещё: возможно, я что-то не так делал, но монтирование ZFS посредством утилиты zfs я так и не осилил нормально. В итоге я просто выставил legacy на все ФС, внёс их в fstab и выкинул zfs-shutdown из скриптов выключения.
Нетбук Asus N10J, gentoo. Компоненты: LXDE, compiz, emerald, gtk2. Готовлю себе stage4 к Новому году. Размер полностью укомплектованной рабочей системы будет около 1 Гб. Специальная оптимизация для процессоров atom. Аппаратная поддержка HD видео без синюшный лиц, ну очень удобное управление окнами приложений без использования строки заголовка и прочие четко выверенные плюхи.
Получается быстрая система, даже по моим меркам.
P.S.
Почему infinity? - совершенствоваться можно бесконечно
Сегодня по интернетам гуляет переделка старой софтины для генерации лабиринтов. Однако, она использует юникодные символы и, потому, подходит не для всех терминалов. Решил написать свою версию, генерирующую другой вариант лабиринтов, который прекрасно отображается на всех типах терминалов, и который я прекрасно помню по Dungeon Crawl Stone Soup в консоли:
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
int main(){
srand(time(0));
for(;;)putchar(((int)(2.0*rand()/(RAND_MAX+1.0))) ? '#' : ' ');
}
Debian Sid + LXDE на USB-флешке. Настроено по возможности минималистично, но не в ущерб удобству. Со старта забивается всего лишь 65мб озу.
Добрый день,
Вторые сутки бьюсь над проблемой ограничения ресурсов, и пока не уверен что достиг того что надо. Буду рад, если направите в правильное русло.
Суть задачи. N пользователей заходят на машину под CentOS 6.4 x64 и запускают любую из 3 программ (prog1,prog2,prog3). Я очень хочу чтобы каждому юзеру под нужды этой программы выделялось 256M RAM (+256M swap при необходимости), ну и процессорной мощности чуть меньше (но тут вообще сферически-эмпирический подход)
Итак, в /etc/cgconfig.conf пишу
group prog_rules {
cpuacct {
cpuacct.usage="0";
}
cpu {
cpu.rt_period_us=5000000;
cpu.rt_runtime_us=90000;
cpu.shares=80;
}
memory {
memory.limit_in_bytes="256M";
memory.memsw.limit_in_bytes="512M";
memory.swappiness="20";
memory.use_hierarchy="1";
}
}в /etc/cgrules.conf первое что пришло в голову это
*:prog1 cpu,memory,cpuacct prog_rules/
*:prog2 cpu,memory,cpuacct prog_rules/
*:prog3 cpu,memory,cpuacct prog_rules/
но сильно показалось, что 256M на программу стали делиться между всеми пользователями. Т.е. user1 запустил prog1 - получил 256М, user2 запустил prog1 - теперь на каждого по 128М, user3 запустил prog1 - теперь 256 делим уже на трех.. Это категорически не подходит.
Решил описать каждого юзера (думаю, это вообще ошибочный путь, ибо пользователей не мало. Идея опичать группы @usergroup:progN cpu,memory.. кажется логичной, но боюсь что лимит будут делиться опять на всех юзеров пропорционально..)
user1:prog1 cpu,memory,cpuacct prog_rules/
user1:prog2 cpu,memory,cpuacct prog_rules/
user1:prog3 cpu,memory,cpuacct prog_rules/
user2:prog1 cpu,memory,cpuacct prog_rules/
user2:prog2 cpu,memory,cpuacct prog_rules/
user2:prog3 cpu,memory,cpuacct prog_rules/
user3:prog1 cpu,memory,cpuacct prog_rules/
user3:prog2 cpu,memory,cpuacct prog_rules/
user3:prog3 cpu,memory,cpuacct prog_rules/
вроде работает, но тупые пользователи умудряются заставить программы работать на пределе всех лимитов, что приводит к адскому свопингу и крайней нестабильности системы..
Может я чтото делаю не так?
Одиннадцатого октября сего года Линус Торвальдс ответил на вопросы аудитории сайта slashdot.org.
( читать дальше... )
>>> Подробности
Зачесалось мне, тут, пощупать в деле btrfs, а именно - её фичу прозрачной компрессии. Что ж, дурное дело - нехитрое.
[$] sudo dd if=/dev/zero bs=1M count=1024 of=btrfs.img
1024+0 записей получено
1024+0 записей отправлено
скопировано 1073741824 байта (1,1 GB), 11,4495 c, 93,8 MB/c
[$] sudo mkfs.btrfs ./btrfs.img
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label (null) on ./btrfs.img
nodesize 4096 leafsize 4096 sectorsize 4096 size 1.00GB
Btrfs Btrfs v0.19
[$] sudo mount -t btrfs -o compress=lzo ./btrfs.img /mnt[$] df -h /mnt
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/loop0 1,0G 56K 894M 1% /mnt
[$] du -h Барселона
24M Барселона/Конфа
93M Барселона/Монсеррат
540M Барселона
[$] sudo rsync -av Барселона /mnt
sending incremental file list
Барселона/
Барселона/P1020344.JPG
...
...
...
Барселона/P1020541.JPG
Барселона/P1020541.MOV
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/mnt/Барселона/P1020541.MOV": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (2388 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]
[$] du -h /mnt
0 /mnt/Барселона/Конфа
0 /mnt/Барселона/Монсеррат
206M /mnt/Барселона
206M /mnt
[$] df -h /mnt
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/loop0 1,0G 206M 76M 74% /mnthttp://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
Для !Ъ:
Баг появился в 3.6.2, позже бэкпортирован в 3.5 и 3.4. Суть в том, что можно потерять кучу данных, произведя несколько перезагрузок подряд с минимальным перерывом.
Ted Ts'o:
I think I've found the problem. I believe the commit at fault is commit 14b4ed22a6 (upstream commit eeecef0af5e):
jbd2: don't write superblock when if its empty
which first appeared in v3.6.2.
The reason why the problem happens rarely is that the effect of the buggy commit is that if the journal's starting block is zero, we fail to truncate the journal when we unmount the file system. This can happen if we mount and then unmount the file system fairly quickly, before the log has a chance to wrap. After the first time this has happened, it's not a disaster, since when we replay the journal, we'll just replay some extra transactions. But if this happens twice, the oldest valid transaction will still not have gotten updated, but some of the newer transactions from the last mount session will have gotten written by the very latest transacitons, and when we then try to do the extra transaction replays, the metadata blocks can end up getting very scrambled indeed.
*Sigh*. My apologies for not catching this when I reviewed this patch. I believe the following patch should fix the bug; once it's reviewed by other ext4 developers, I'll push this to Linus ASAP.
- Ted
Тут же, Ted:
Well, the problem won't show up if the journal has wrapped. So it will only show up if the system has been rebooted twice in fairly quick succession. A full conventional distro install probably wouldn't have triggered a bug... although someone who habitually reboots their laptop instead of using suspend/resume or hiberbate, or someone who is trying to bisect the kernel looking for some other bug could easily trip over this --- which I guess is how you got hit by it.
Есть такие ФС, у которых удаление папки по времени не зависит от количества файлов внутри? Тоесть алгоритм удаления амортизирован будущей работой ФС или просто структуры данных это поддерживают.
$_=<<'';y;\r\n;;d;$_=pack'b*',$_;$_=eval;$@&&die$@;$_Это НЕ однострочник знаменитый, но это что-то делает. Вопрос - что? :)
Добрый день.
Есть домашний сервер на Asus EeePC 900.
На корне у меня стоит ext2 (без журнала и в режиме read_only), а вот на /home и /var подумываю поставить либо LogFS, либо новую самсунговскую f2fs, вот только ко второй фиг утилиты есть и поддержка в ядре (Debian Testing).
Что посоветуете из ФС, пригодных для SSD? И пригодна ли LogFS для подобного?
| ← назад |