Сравнительное тестирование криптоконтейнеров и шифрованных файловых систем
Основные задачи:
— Возможность бекапирования данных в любом виде для аварийного восстановления.
— Исключение доступа к этим данным неавторизованных лиц.
— Невозможность доступа к файлам при аварийном выключении сервера и загрузке с внешнего носителя.
— Прозрачная работа пользователей с файлами и любым содержимым находящемся на сервере.
— OS FreeBSD 7.2 и максимальный простор для фантазии в выборе вариантов реализации.
После энного количества времени сложилась следующая тестовая конфигурация:
GELI — GEOM_ELI (встроенная во FreeBSD подсистема шифрования использующая crypto(9) framework(аппаратное и программное шифрование))
GBDE — GEOM_BDE [Geom Based Disk Encryption] (встроенная во FreeBSD подсистема шифрования)
TrueCrypt — Портированная версия TrueCrypt 6.1a (использует fuse)
cryptofs — cryptofs использующая fuse
encfs — encfs использующая fuse
UPD: Таблица сравнения скоростей чистой и шифрованной файловых систем.
Начнем с классификации используемых систем шифрования.
Первые две системы используют любое устройство определяемое через GEOM.
Это может быть физический накопитель(da0), партиция(da0s1),
слайс(da0s1a), а также любое другое синтетическое устройство созданное
скажем через mdconfig или ggatel.
mdconfig
— утилита использующая geom_md и формирующая виртуальное устройство из
имеющейся у Вас оперативной памяти или файла на диске или любом другом
носителе.
ggatel — это утилита которая позволяет перевести любое устройство или файл, которое не может быть отнесено к классу GEOM в этот класс.
TrueCrypt — автономная кроссплатформенная система шифрования криптоконтейнеров.
fuse_cryptofs
— подсистема парольного шифрования данных на диске шифрующая имена
файлов и их содержимое при помощи алгоритмов заданных в
конфигурационном файле.
fuse_encfs — подсистема
парольно-ключевого шифрования данных на диске шифрующая имена файлов и
их содержимое с контролем изменений в файлах.
Все тесты проводились на системе имеющей следующие характеристики P4 2.8HT/1GB RAM/40GB IDE/.
Для оценки скорости работы использовались dd и bonnie.
Временные файлы криптоконтейнеров и директории с файлами были размещены на разделе /var.
# dmesg | grep ad0
ad0: 38166MB <Seagate ST340014A 3.06> at ata0-master UDMA100
# mount | grep var
/dev/ad0s1g on /var (ufs, local, soft-updates)
Первым делом нужно было оценить какую скорость линейной записи на жёсткий диск мы можем получить в пике.
testcrypt# /usr/bin/time dd if=/dev/random of=testfile.dump bs=1m count=4096
4096+records in
4096+records out
4294967296 bytes transferred in 151.801076 secs (28293392 bytes/sec)
151.82 real .00 user 132.96 sys
Т.е. максимально мы можем рассчитывать примерно на 27 мегабайт/с при потоковой записи.
Для анализа скорости работы GEOM провайдеров был создан файл размером 4GB, который по очереди подключался к mdconfig и ggatel(размер
сектора был определен в 4Кб). Далее по тексту я постараюсь максимально
исключить лишнюю служебную информацию из вставок кода.
Мы проверили линейную скорость записи через GEOM провайдеров.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0
testcrypt# /usr/bin/time dd if=/dev/random of=/dev/md0 bs=1m
4294967296 bytes transferred in 306.514082 secs (14012300 bytes/sec)
306.55 real .02 user 120.03 sys
testcrypt# mdconfig -d -u 0
testcrypt# ggatel create -s 4096 -u 0 /var/test/testfile.dump
testcrypt# /usr/bin/time dd if=/dev/random of=/dev/ggate0 bs=1m
4294967296 bytes transferred in 319.859650 secs (13427662 bytes/sec)
319.91 real .02 user 133.34 sys
testcrypt# ggatel destroy -u 0
Как видно из тестов скорость записи упала почти в 2 раза и ggate провайдер оказался немного медленнее чем md, но в принципе это не особо критично, хотя ggate немного больше грузит систему чем md.
Следующий шаг это проверка нагрузочной способности для файловых систем работающих через GEOM провайдеров. Первым тестировался md.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0
testcrypt# newfs /dev/md0
/dev/md0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096
using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.
super-block backups (for fsck -b #) at:
160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312,
6211456, 6901600, 7591744, 8281888
testcrypt# mount /dev/md0 /mnt
testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m
4220518400 bytes transferred in 235.262614 secs (17939605 bytes/sec)
235.28 real .03 user 136.49 sys
testcrypt# umount /mnt
testcrypt# mdconfig -d -u 0
Как мы видим скорость работы с файлами возросла и составила 17.1 мегабайт/сек.
Вторым тестировали ggate.
testcrypt# ggatel create -s 4096 -u 0 /var/test/testfile.dump
testcrypt# newfs /dev/ggate0
/dev/ggate0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096
using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.
super-block backups (for fsck -b #) at:
160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888
testcrypt# mount /dev/ggate0 /mnt
testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m
4220518400 bytes transferred in 228.256445 secs (18490249 bytes/sec)
228.29 real .00 user 137.80 sys
testcrypt# umount /mnt
testcrypt# ggatel destroy -u 0
При прочих равных условиях ggate показал увеличение скорости по сравнению с md — 17.6 мегабайт/сек.
Настало время потестировать связку crypto и geom провайдеров. Для этого
создали случайный ключ, который будет использоваться в дальнейших
тестах.
testcrypt# dd if=/dev/random of=/var/test/my.key bs=4k count=1
Инициализируем криптоконтейнер geli
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0
testcrypt# /usr/bin/time geli init -s 4096 -K my.key /dev/md0
Enter new passphrase:
Reenter new passphrase:
13.34 real 9.61 user .00 sys
Как видно из вывода time, geli init довольно долго просчитывает связку ключа шифрования с паролем и записывает его на диск.
testcrypt# geli list
Geom name: md0.eli
EncryptionAlgorithm: AES-CBC
KeyLength: 128
Crypto: software
UsedKey:
Flags: NONE
Providers:
1. Name: md0.eli
Mediasize: 4294963200 (4.0G)
Sectorsize: 4096
Mode: r0w0e0
Consumers:
1. Name: md0
Mediasize: 4294967296 (4.0G)
Sectorsize: 4096
Mode: r1w1e1
Криптоконтейнер создан и сформировано новое устройство с суффиксом .eli, которое можно использовать как обычное блочное устройство. Размечать его, создавать партиции и файловые системы.
Создаём новую файловую систему на криптоконтейнере и тестируем скорость.
testcrypt# newfs /dev/md0.eli
/dev/md0.eli: 4096.0MB (8388600 sectors) block size 16384, fragment size 4096
using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.
super-block backups (for fsck -b #) at:
160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888
testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m
4220518400 bytes transferred in 277.940331 secs (15184980 bytes/sec)
277.96 real .03 user 145.50 sys
Как мы видим, скорость упала до 14.5 мегабайт/сек. Я пропущу блок разметки и тестирования скорости связки ggate+geli, так как он идентичен блоку geli+md. Так как мы не можем оценивать скорость работы только по циклу записи, мы запускаем bonnie для дополнительного анализа.
Сводные результаты работы bonnie на всех связках будут приведены в конце статьи.
testcrypt# bonnie -s 1024
File './Bonnie.1145', size: 1073741824
| |
Sequential Output |
Sequential Input |
Random |
| |
Per Char |
Block |
Rewrite |
Per Char |
Block |
Seeks |
| Machine |
MB |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
/sec |
%CPU |
| geli+md |
1024 |
17178 |
25.7 |
18324 |
8.4 |
5684 |
2.2 |
14492 |
15.1 |
15185 |
2.3 |
139.8 |
0.7 |
| geli+ggate |
1024 |
13855 |
20.6 |
12018 |
5.2 |
6388 |
2.7 |
19021 |
21.8 |
22473 |
4.2 |
136.5 |
0.7 |
Как мы видим ggate медленнее
работает на циклах записи, но намного быстрее работает на циклах
чтения. Возможно это связано с буферизацией записи и различных методах
сброса буферов в md и ggate. Если попробовать ввести неверный файл ключа или пароль, то geli не создаёт устройство для доступа к файловой системе, а так как файл контейнера внутри напоминает содержимое /dev/random, то расшифровать его просто нереально. Ни пофайлово, ни целиком. Одним из преимуществ geli является возможность использования нескольких ключей шифрования, скажем мастер ключа и ключа пользователей.
Инициализируем контейнер GBDE.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0
testcrypt# gbde init /dev/md0 -i -K my.key -L /var/tmp/md0.lock -P testcrypt
testcrypt# ll /var/tmp/md*
md0.lock
testcrypt# gbde attach /dev/md0 -l /var/tmp/md0.lock -k my.key -p testcrypt
testcrypt# ll /dev/md*
crw-r----- 1 root operator , 98 Apr 21 13:25 /dev/md0
crw-r----- 1 root operator , 100 Apr 21 10:15 /dev/md0.bde
crw------- 1 root wheel , 78 Apr 21 10:15 /dev/mdctl
gbde при создании устройства использует файл блокировки в
котором находятся текущие ключи для инициализации криптоконтейнера.
Система инициализации криптоконтейнера не имеет реверсивной процедуры
восстановления данных, поэтому если вы забыли пароль или потеряли файл
блокировки, то вы потеряли все данные которые находились в
криптоконтейнере. После инициализации криптоконтейнера gbde создаёт устройство с суффиксом .bde с которым можно обращаться так же как и c .eli.
Подробное руководство по использованию обоих систем можно найти тут. Запускаем bonnie для тестирования связки gbde+md и gbde+ggate.
testcrypt# bonnie -s 1024
File './Bonnie.1145', size: 1073741824
| |
Sequential Output |
Sequential Input |
Random |
| |
Per Char |
Block |
Rewrite |
Per Char |
Block |
Seeks |
| Machine |
MB |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
/sec |
%CPU |
| gbde+md |
1024 |
4436 |
5.3 |
4349 |
1.7 |
2695 |
1.2 |
12920 |
13.7 |
17078 |
2.9 |
130.1 |
0.7 |
| gbde+ggate |
1024 |
1971 |
2.2 |
1970 |
0.8 |
1480 |
0.6 |
13812 |
15.2 |
17206 |
3.0 |
120.3 |
0.6 |
Подсистема gbde показала
довольно скудные значения быстродействия, хотя как видно из таблицы
процессорное время практически не использовалось в отличии от geli. С чем это связано я так до конца и не выяснил.
Найдя в сети неофициальный порт TrueCrypt 6.1a на FreeBSD, было решено испытать его в работе.
TrueCrypt должен работать на FreeBSD через fuse, но на деле всё оказалось не совсем так.
Попытка скомпилить данный порт привела к тому, что в систему были
затащены xorg, glib, gtk, gnome, wxWidgets и куча другого барахла.
Детальный анализ выявил, что виной всему GUI интерфейс сделанный на
wxWidgets. Нам GUI был ненужен и поэтому путём проб и ошибок были
найдены магические последовательности для gmake которые таки собрали TrueCrypt на нашей тестовой системе.
gmake NOGUI=1 WX_ROOT=/usr/local/tmp/wx wxbuild
gmake NOGUI=1 WXSTATIC=1 PKCS11_INC=/usr/local/include/pkcs11/
TrueCrypt запустился весело сообщив:
testcrypt# truecrypt
13:35:34: Error: Cannot convert from the charset 'US-ASCII'!
Ругань относилась к тому, что TrueCrypt не смог конвертнуть help из LANG=C в en_US.UTF-8, который жестко зашит в исходниках.
testcrypt# /usr/bin/time truecrypt -c --filesystem=ufs -k /var/test/my.key --random-source=/dev/random /var/test/truecrypt.dump /mnt
Volume type:
1) Normal
2) Hidden
Select [1]:
Enter volume size (sizeK/size[M]/sizeG): 4G
Encryption algorithm:
1) AES
2) Serpent
3) Twofish
4) AES-Twofish
5) AES-Twofish-Serpent
6) Serpent-AES
7) Serpent-Twofish-AES
8) Twofish-Serpent
Select [1]:
Hash algorithm:
1) RIPEMD-160
2) SHA-512
3) Whirlpool
Select [1]:
Filesystem:
1) FAT
2) None
Select [1]:
Enter password:
WARNING: Short passwords are easy to crack using brute force techniques!
We recommend choosing a password consisting of more than 20 characters. Are you sure you want to use a short password? (y=Yes/n=No) [No]: y
Re-enter password:
Done: 100,000% Speed: 31 MB/s Left: s
The TrueCrypt volume has been successfully created.
139,42 real 204,75 user 13,80 sys
Созданный раздел без проблем смонтировался.
testcrypt# truecrypt -k /var/test/my.key --mount /var/test/truecrypt.dump /mnt
Enter password for /var/test/truecrypt.dump:
Protect hidden volume? (y=Yes/n=No) [No]:
testcrypt# mount
...
/dev/fuse0 on /var/tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous)
/dev/md0 on /mnt (msdosfs, local)
testcrypt# mdconfig -l -v
md0 vnode 4.0G /var/tmp/.truecrypt_aux_mnt1/volume
testcrypt# ll /var/tmp/.truecrypt_aux_mnt1/
total
-rw------- 1 root wheel 1522 21 апр 15:51 control
-rw------- 1 root wheel 4294705152 21 апр 15:51 volume
Но нас постигло жестокое разочарование. Вопреки ожидаемому
использованию fusefs, TrueCrypt стал использовать трансляцию своего
endpoint файла через md.
Таким образом мы получили еще один лишний стык в преобразовании
криптоконтейнера. Разочарование стало еще большим когда при попытке
записи данных на примонтированный TrueCrypt Volume мы получили deadlock
после того как исчерпались буфера записи для vfs. Танцы с бубном вокруг
TrueCrypt, настроек vfs и многого другого ни к чему не привели и мы
забросили идею нормального тестирования TrueCrypt. К сожалению текущая
сборка TrueCrypt может создавать только две файловые системы независимо
от OS, FAT и NTFS, это жестко запрограммировано в исходных кодах.
Создание файловой системы на отмонтированном Volume вполне решает
проблему использования msdosfs, но не решает проблему deadlock.
Так как тестируемые криптоконтейнеры у нас закончились, мы попытались
реализовать какуюнибудь схему резервного копирования этих контейнеров.
В общем тут нас ожидало не менее грустное обстоятельство, чем проблемы
с TrueCrypt. Мы попытались сделать snapshot на файловой системе на
которой находится подмонтированный криптоконтейнер и выцепив оттуда
файл контейнера посмотреть на его содержимое. Но тут же поймали
проблему. При активных файловых операциях с криптоконтейнером попытка
сделать snapshot приводит к deadlock. Система вроде бы живая, но в тоже
время обратиться к примонтированному контейнеру нельзя, а впоследствии
умирает доступ ко всем системным разделам :(
При отсутствии операций с криптоконтейнером snapshot происходит
нормально, но вероятность последующего deadlock тоже не исключена.
Причем с md устройствами проблема проявляется раньше чем с ggate.
После deadlock и последующей принудительной dirty(reboot -qn)
перезагрузки, криптоконтейнер необходимо сначала проверить через fsck,
иначе он не примонтируется. Выдернутый же криптоконтейнер из snapshot
на поверку оказывается битым, с отсутствующей файловой системой и без
наших данных. Что очень и очень грустно. Ну да ладно, нельзя
использовать online бекап, значит 100% можно использовать offline
бекап. На этом с криптоконтейнерами и остановимся.
Вторая часть тестирования связана с использованием fusefs.
Для тестирования были выбраны cryptofs и encfs. Разница между системами
небольшая и основное отличие заключается в том, что encfs поддерживает
параноидальный режим безопасности проверяющий целостность файлов.
testcrypt# cryptofs -r /var/crypto/
Enter password:
testcrypt# mount_fusefs /dev/fuse0 /mnt
testcrypt# df -h | grep mnt
Filesystem Size Used Avail Capacity Mounted on
/dev/fuse0 18G 5.1G 12G 30% /mnt
cryptofs создаёт шлюз который шифрует проходящие через него
данные при помощи пароля заданного пользователем, используя обычную
файловую систему на машине. Для работы системы требуется поместить в
директорию, которая будет домашней, файл с настройками .cryptofs
# See README for details on each parameter
[CryptoFS]
cipher=AES256
md=MD5
blocksize=2048
salts=256
Настройки — это список алгоритмов шифрования, которые будут
использоваться в работе. К сожалению месторасположение файла изменить
нельзя :(
testcrypt# cp /etc/defaults/* /mnt
testcrypt# ls /mnt/
bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf
testcrypt# ls /var/crypto/
.cryptofs JuSxlpX8BzEtClI= MuKkkZS2WycuAUc= IO2ylZK9GjApQUWQR697gAD3Valf MOLpk4m8Ew== MuS1mYm2HCdvDE6bVw==
Система очень легка в использовании, но имеет один недостаток. Если Вы
случайно ошиблись буквой или цифрой при вводе пароля — система
зашифрует данные именно тем паролем который Вы набрали. Велика
вероятность того, что Вы заметите это не сразу, а пользователи уже
нальют файлов которые будут зашифрованы новым паролем. Файловая система
после ввода неверного пароля выглядит примерно вот так.
testcrypt# cryptofs -r /var/crypto
Enter password:
testcrypt# mount_fusefs /dev/fuse0 /mnt
testcrypt# ls /mnt/
i+???F9&??tg? i-???F~&T?} k-???L6 {"???M?1SA?l?????y??? }+????"0W?h
encfs данной проблемы лишён, но имеет уже намного более широкие
настройки по шифрованию, а также в конфигурационном файле создаёт
уникальный ключ. При помощи этого ключа encfs определяет
корректность ввода пароля, правильность шифрования файлов, а также
определяет какие файлы показывать или не показывать(имеется ввиду —
шифрованные именно этим ключом). Если Вы забыли пароль, то можете смело
удалять все данные, восстановлению они не подлежат. Процесс работы
выглядит следующим образом.
testcrypt# encfs /var/crypto /mnt
Creating new encrypted volume.
Please choose from one of the following options:
enter "x" for expert configuration mode,
enter "p" for pre-configured paranoia mode,
anything else, or an empty line will select standard mode.
?>
Standard configuration selected.
Configuration finished. The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/aes", version 2:1:1
Filename encoding: "nameio/block", version 3::1
Key Size: 192 bits
Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism. However, the password can be changed
later using encfsctl.
New Encfs Password:
Verify Encfs Password:
testcrypt# mount | grep mnt
/dev/fuse0 on /mnt (fusefs, local, synchronous)
testcrypt# cp /etc/defaults/* /mnt
testcrypt# ls /mnt
bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf
testcrypt# ls /var/crypto/
.cryptofs Nq2IBppvuCpNNHuYS1k5dn-q wiNUtxqXvJqCLs3s-u1qwJrA
.encfs6.xml gNsHASsB,5N2H1TZlWTJjldR
B7rx58O9WjTGrjeTaiFXjREamAQzW7u3oK3NOK1KuN4Rp- sTZaWdYP4B-oXrW1d1COMMNV
Бекапирование данных можно осуществлять методом обычного снятия
снепшотов с раздела, а также прямым копированием файлов в требуемое
место, главное сохранить ключи для возможности обратной расшифровки ;)
Выводы: Все исследуемые в данной статье методы шифрования данных на
дисках имеют право на использование в повседневной жизни. В зависимости
от используемых систем шифрования, Вы можете получить нужный Вам
функционал за короткий промежуток времени. Из тестируемых мною систем я
бы всё таки остановил свой выбор на geli и encfs.
Первая система очень привлекательна с точки зрения использования
аппаратных модулей шифрования, при использовании которых не будет
затрачиваться процессорное время на шифрование данных, а также
возможностью шифрования разделов целиком. Вторая система интересна
режимами контроля целостности шифруемых файлов и возможностями
изменения множества параметров. При всём уважении к encfs хочется отметить зависимость системы от нескольких внешних библиотек которые придётся таскать с собой. Опять же с geli
Сравнительная таблица тестов bonnie по всем системам.
могут возникнуть проблемы с резервным копированием массивов большого
объёма. Ну вот в общем-то и всё. Спасибо за уделённое время на
прочтение данного материала.
| |
Sequential Output |
Sequential Input |
Random |
| |
Per Char |
Block |
Rewrite |
Per Char |
Block |
Seeks |
| Machine |
MB |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
/sec |
%CPU |
| geli+md |
1024 |
17178 |
25.7 |
18324 |
8.4 |
5684 |
2.2 |
14492 |
15.1 |
15185 |
2.3 |
139.8 |
0.7 |
| geli+ggate |
1024 |
13855 |
20.6 |
12018 |
5.2 |
6388 |
2.7 |
19021 |
21.8 |
22473 |
4.2 |
136.5 |
0.7 |
| gbde+md |
1024 |
4436 |
5.3 |
4349 |
1.7 |
2695 |
1.2 |
12920 |
13.7 |
17078 |
2.9 |
130.1 |
0.7 |
| gbde+ggate |
1024 |
1971 |
2.2 |
1970 |
0.8 |
1480 |
0.6 |
13812 |
15.2 |
17206 |
3.0 |
120.3 |
0.6 |
| fusefs+cryptofs |
1024 |
17207 |
23.8 |
21015 |
10.7 |
6494 |
3.5 |
16202 |
17.1 |
16829 |
3.2 |
70.1 |
1.2 |
| fusefs+encfs |
1024 |
19073 |
25.3 |
23250 |
11.4 |
7676 |
3.9 |
16402 |
18.4 |
19187 |
3.5 |
70.3 |
1.2 |
UPD: Таблица сравнения скоростей чистой файловой системы и шифрованной. С включенными и выключенными softupdates.
| |
Sequential Output |
Sequential Input |
Random |
| |
Per Char |
Block |
Rewrite |
Per Char |
Block |
Seeks |
| Machine |
MB |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
K/sec |
%CPU |
/sec |
%CPU |
| fusefs+cryptofs |
1024 |
17207 |
23.8 |
21015 |
10.7 |
6494 |
3.5 |
16202 |
17.1 |
16829 |
3.2 |
70.1 |
1.2 |
| fusefs+encfs |
1024 |
19073 |
25.3 |
23250 |
11.4 |
7676 |
3.9 |
16402 |
18.4 |
19187 |
3.5 |
70.3 |
1.2 |
| cleanfs+su_on |
4096 |
33745 |
33.5 |
32517 |
12.8 |
10681 |
4.4 |
34911 |
35.9 |
39035 |
7.7 |
80.1 |
0.5 |
| cleanfs+su_off |
4096 |
34918 |
33.4 |
35108 |
12.9 |
11188 |
4.5 |
37268 |
38.3 |
39513 |
7.6 |
84.6 |
0.5 |
|
| Категория: Общие Статьи | Добавил: aka_kludge (30.04.2009)
|
| Просмотров: 3002
| Рейтинг: 5.0/2 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ] |
