Загрузка десктопа, ч.2

Шаманю дальше, убрал nvidia видеокарту, настроил встроенную в процессор (Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller, Kernel driver in use: i915), получилось вот так:

Система грузится уже за 10,8 секунды, что ИМХО очень и очень неплохо. Да и DRM — вещь: теперь мало того что в консольке (ctrl+alt+f1) разрешение экрана 1920х1080 (против VESAFB, безальтернативно используемого с nvidia-driver, где 1280х800 самое больше широкоформатное разрешение), так ещё и переключение между режимами происходит за доли секунды (вместо единиц секунд с nvidia-driver). Ляпота!

P.S. xorg.conf

Section "Device"
        Identifier      "SandyBridge"
        Driver          "intel"
EndSection

Section "Monitor"
        Identifier      "Monitor0"
        VendorName      "Unknown"
        ModelName       "LG Electronics E2360"
        HorizSync       30.0 - 83.0
        VertRefresh     56.0 - 75.0
        Option          "DPMS"  "1"
EndSection

Section "Screen"
    Identifier     "Default Screen"
    Device         "Intel SB IGC"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes       "1920x1080"     "1280x800"
    EndSubSection
EndSection

загрузка десктопа

Система грузится за 18,0 секунд, из которых 11 «читых» (груб и далее). Из этих 11-ти драйвер nvidia тупит ещё секунды 2-3, может попробовать nouveau, что думаете?

Конфиг:
CPU – Intel Core i5-2500k (100×33@1,20v OC to 100×46@1,36v)
MB – AsRock Z68 Pro3 (Realtek ALC892, Realtek RTL8111E)
RAM – Kingston KHX1600C9D3K2/4GX (2×2 Gb DDR3-1600 9-9-9-27 1T 1.65v @ DDR3-1600 8-9-8-24 1T 1.60v)
GPU – GeForce GTX 260 (55nm) 216 SP 896 MB (448-bit GDDR III), 625/1350/2200@1,12v OC&UV 675/1350/2200@1,05v (зашил в биос)
SSD – 128Gb Crucial C300
HDD – 1000Gb Samsung HD103UJ
HDD – 750Gb WDC WD7500AAKS (умер не предупредив SMART)
ODD – none (ненужен)
PSU – ATX 600W Xilence SPS-XP600
Chassis – Deluxe DLC-SH496
CPU cooler – Cooler Master Hyper 212 Plus
Display – LG 2360V
Webcam – Logitech HD Webcam C310
ОС – Gentoo Linux + Windows 7 Home Premium 64-bit SP1

Корень на ext4, native-ACHI и проприетарный nvidia-driver. KDE SC 4.7.90 (4.8 Beta2)

твердотельный ssd-накопитель: немного шаманства, пару слов о TRIM и почему btrfs «не тру»

Приветствую (^_^)

Пожалуй как всякий гик, прикупив новый девайс (Crucial C300 на Marvell 88SS9174), я вплотную занялся изучением того, что, собственно, эта недешёвая железяка может. Перенеся систему на ssd и восхитившись шустрой загрузкой (17 секунд против 41-й на 7200rmp терабайтнике от самсунг) пришло время разобраться с такой мудрёной штукой как TRIM. Так вот, вопреки распространённому мнению «Да это ж Линукс! Там всё изаропки и как нада» не всё так радужно. Ядрышко то наше собстенно TRIM то и не поддерживает. Это, оказывается, задача файловой системы! (о как, сюрприз-сорприз). Причём по дефолту оно выключено везде. Ну не разгильдяйство ли? Не верите? А вот вам тру-статья для проверки своих ssd.

Проверка, а не включён ли trim уже сейчас

Пусть /dev/sdX – наш SSD диск

1. Меняем пользователя на root:
   sudo -i
2. Пишем файл 50Мб со случайными данными:
   dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct
3. Ищем стартовый LBA адрес у файла
   hdparm --fibmap tempfile
4. Читаем данные со стартового LBA адреса файла, замените [ADDRESS] на свой Starting LBA address из вывода предыдущей команды:
   hdparm --read-sector [ADDRESS] /dev/sdX
5. Теперь удалим временный файл и синхронизируем ФС:
   rm tempfile
sync
6. Повторяем пункт 4:
   hdparm --read-sector [ADDRESS] /dev/sdX

Если TRIM включен, то в результате вывода должны быть одни нули, если же их нет TRIM выключен.

Вот так вот, подумал я и засел читать доки. Оказывается, опция монтирования discard (включающая TRIM для файловой системы) поддерживается далеко не всеми файловыми системами. К примеру ext4 и brtfs умеют, а вот reiserfs v3 грязно ругается в логи о том что такой опции знать не знает и не работает.

А теперь плавно переходим к тому, почему brtfs не тру. Дело в том, что пару лет назад я довольно плотно исследовал вопрос «как бы это разбить диск (hdd) так, чтобы всё работало пошустрее». Ну /boot и /home отдельным разделом это классика. А дальше? Если отформатировать корень в reiserfs это положительно скажется на скорости работы портажа, тот-же eix-sync уж очень любит reiserfs, оно и понятно: работа с тувой хучей мелкий файлов это конёк reiserfs. Однако посмотрев на скорость работы с файлами среднего размера (1-10 МБ) выясняется что ext4 торт. Да и плюшки типа экстентов это тру. В результате сих, впрочем не особо сложных размышлений, было принято решение: корень в ext4; /usr/portage/ ,как отдельный раздел, в reiserfs размером 512 МиБ (это важно, дальше всплывёт), и из /usr/portage симлинком вынести distfiles на другой раздел (файлопомойку). В результате получилось просто и элегантно: система на ext4 шустро крутится, portage работает с разделом на 512 МиБ (заполненным на 400 МиБ) в reiserfs и делает это реально быстро, да и distfiles на файлопомойке никому не мешают.

Сия идиллия продолжалась до появления ssd: раз reiserfs не умеет монтироваться с опцией discard было принято стратегическое решение «ну и фиг с тобой, сделаю раздел на гиг в ext4, делов то». Не тут то было — знаете сколько инодов на разделе такого размера? Нет? А я знаю: явно меньше чем файлов в /usr/portage xD Он туда просто не влез. Не хватило inodes. И это несмотря на то, что размер был увеличен в 2 раза по сравнению с reiserfs где всё каком-то чудом умещалось. Почесав тыковку, вспомнил что была ещё какая-то fs без инодов (точнее с бесконечным количеством оных), уж не btrfs ли? en.wikipedia.org — она самая! уря-уря. Сношу гиговый ext4, форматирую в btrfs (зараза, пришлось ядро пересобирать), и вот оно счастье? Как бы не так. На ядре 3.0.1 оно к сожалению сыпет call stack-ами в логи тупо при чтении содержимого раздела. Ну да, experemental в ядре, но не при чтении только что созданного раздела же!!! Поимейте совесть, записав 600Мб я смог назад отчитать только 300. И получил 1,2 Гб (!!) мусора в dmesg. Ну её, такую бяку. К тому же размер тома штатно менять нельзя.

В конце концов просто перенёс /usr/portage/ на «родину», в корневой раздел, и на этом всё. Надеюсь шустрый ssd нивелирует не шуструю ext4 при чтении туевой кучи мелких файлов. Спасибо за внимание :)

P.S. Не делайте для ext2/3/4 tune2fs -o journal_data_writeback /dev/sdaX , это хоть и выключит журнал для метаданных, но с ним выключится и TRIM.

P.P.S Чтобы прикинуть сколько данных и кто пишет на диск можно использовать что-то типа iotop -a (оставьте в фоне на пару часов), там будут строки вида [jbd2/sda2-8] — это метаданные. Так-же можно посмотреть объём записанного на ext командой tune2fs -l /dev/sda4 | grep eti

(заметка) тюнинг параметров gcc, особенности

Возился я тут с одной штукой, которая на ровном месте вела себя странно, очень странно, и вот что обнаружил (хотя баян конечно, просто об этом часто забывают):

• Некоторые Athlon 64 X2 умеют -mssse3
• а вот Phenom II не умеет -mssse3
• Phenom II умеет -msse4a
• -msse4a это очень даже не -msse4.1 или -msse4.2 от Intel (ни 4.1 ни 4.2 феномы не умеют, а интел соответственно не умеет -msse4a)

Более подробно в выводе gcc:

gcc -Q --help=target

или что-то типа

gcc -Q -march=core2 -mfpmath=sse -mmmx -mssse3 --help=target

(заметка) шрифты для иксов

По-моему media-fonts/droid пожалуй один из наиболее красивых, приятных глазу шрифтов. Причём как непосредственно сам DroidSans, так и его моноширный собрат DroidSansMono, вот к примеру:

Вот так выглядит Smplayer (полоски прокрутки от kde-4.7 rc1) с шрифтом DroidSans:

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

Владельцам плеера iRirver E100 на заметку

Доброго времени суток. Признавайтесь, господа, тоже храните музыку на ББ/NAS во FLAC-е (или других lossless форматах), а на плеер копируете её хитрым скриптом, который режет образ на треки и перегоняет в тот-же ogg vorbis (ведь sdd на плеере совсем небольшой)? Знаю-знаю, сам такой. Так вот: не используйте oggenc -q с параметром больше семи, ибо в некоторых треках хиленький DSP плеера захлёбывается и слышно классическое «дёрг-дёрг», что неприятно. Очень неприятно. Жутко неприятно. Особенно когда доступа к компьютеру уже нет, и приходится это «дёрг-дёрг» слушать несколько дней подряд.

P.S. Конструкция вида find -name ‘*.flac’ -print0 | xargs -0I ‘{}’ -P4 oggenc -q7 ‘{}’ позволяет гораздо быстрее (чем oggenc -q7 *.flac) перегнать директорию в ворбис.

P.P.S. О том как порезать image+cue на треки я уже рассказывал.

SSL и поиск от google, или паранойя спешит на помощь

Всякие разные нехорошие товарищи нюхают ваш траффик, интересуются тем, что вы ищете с помощью гугла, или вас просто одолела паранойя? Нет проблем, с новым поиском от гугла с использованием защищённого SSL канала связи вы сможете спать спокойно :) Теперь за Вами следит только сам гугл xD

Для интеграции с браузером создайте новую поисковую службу а-ля:

https://encrypted.google.com/search?hl=ru&source=hp&q=%s&aq=f&aqi=&aql=&oq=

Этот пример для Opera и Chromium, для других — по аналогии.

P.S. А ещё это помогает обходить контент-фильтры в местах общественного пользования интернетом.
P.P.S. Что б уж совсем от всех спрятаться можно воспользоваться к примеру связкой Tor+Privoxy, которая, кстати, в генту поднимается с полпинка :)