Серия статей «первый взгляд» продолжается. От миниатюрных дистрибутивов переходим к операционным системам «особого назначения». Сегодня речь пойдёт о Kali Linux.
Вполне возможно, что ранее Вы ничего не слышали о Kali Linux. Надеюсь, я сумел заинтриговать Вас опубликованной выше фразой «особого назначения». Теперь пришло время расставить все точки над «i».
Облачные хранилища данных стали очень популярны. Конечно, особую роль здесь играет возрастание скорости интернета, а также целый зоопарк мобильных гаджетов. Уж очень удобно иметь актуальные версии своих документов как на десктопе, так и на ноутбуке, смартфоне, планшете.
Но главный минус — это лимитированное бесплатное пространство. Поэтому для загрузки в облако большого объёма данных приходится либо покупать дополнительное место, либо использовать одновременно несколько сервисов.
Эта статья посвящена второму подходу, а точнее его реализации на Android.
Есть и отечественный аккаунт от ЯндексДиск‘а с 6 бесплатными гигабайтами. Своеобразная файлопомойка. А точнее бекапы бекапов.
В наличии и GoogleDrive с 15 бесплатными гигабайтами. Это уже более серьёзное место. Храню исходный код программ, который может пригодиться в будущем.
А после покупки нового ноутбука и перехода на Windows 8.1 появился SkyDrive с 7 бесплатными гигабайтами. Складываю туда документы и фотографии.
Таким образом, есть 4 поставщика с суммарным объемом в 56,75 гигабайт.
Каждый поставщик имеет своё фирменное приложение для Android. А каждое новое приложение — это лишний мусор в памяти смартфона, которой не так уж и много. К тому же постоянные синхронизации просто съедят весь трафик. Поэтому удобнее использовать одну программу.
Можно искать альтернативы долго. но решение уже давно лежит в must-have чемоданчике. Вот оно:
Установите его себе, если не сделали этого раньше. Запустите. Затем необходимо произвести свайп влево, чтобы переместиться в раздел «Облачное хранилище».
<
a href="http://2.bp.blogspot.com/-SmfSO4piC9c/UsnrnlfTiKI/AAAAAAAAB7Y/9BoKTz3j5e4/s1600/cloud-android-06_vlsu.blogspot.com.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;">
Автор: Vladimir Surkov a.k.a. Vlsu
Kubuntu — операционная система, которая является сборкой Ubuntu со средой KDE. Часто критикуется за «прожорливость», но по в любом случае среди всех оболочек наиболее схожа с рабочим столом Windows, а также имеет много графических средств для настройки. Таким образом, имея опыт работы в Windows, разобраться и настроить KDE не составит труда.
Выберите созданную машину и нажмите на кнопку «Настроить».
Далее найдите на диске образ Kubuntu.
Итак, загрузилось меню LiveCD:
Нажмите клавишу F2 и стрелками выберите русский язык из списка.
Пункт «Запустить Kubuntu» уже активен. Просто нажмите Enter.
Очередной обзор SSD на нашем основном сайте: http://www.truesystem.ru/review/360953/
По просьбе трудящихся — дополнительные графики. Два последних пункта в легенде: блоки с 50% содержанием сжимаемых данных (по умолчанию — просто нули, SandForce SF-2581 умеет сжимать данные, больше IO помещается в кэш, и как следствие растёт производительность). Ешё добавлен результат с O_DSYNC (direct=1 вместе sync=1 в fio, фиолетовый график).
Обновление от 29.12.2014: дополнительный тест Host Idle Recovery из SNIA PTS Enterprise 1.1. Наглядно показывает способность SSD использовать свободное время для сборки мусора и очистки кэша. Перед основным тестом идут две подготовительных ступени: последовательная запись 128КиБ до достижения 2-кратной ёмкости и случайная запись блоками 4КиБ в течение 120 минут (25 минут, предложенных в официальной спецификации явно не хватает для выхода на установившееся состояние) — это соответствует предыдущему тесту Write Saturation Test, производительность с 14000 IOPS падает до 2000:
Каждый из цветных участков на следующем графике (State 1 AB, State 2 AB и т.д.) соответствует 360-ти раундам, состоящим из 5 секунд нагрузки (всё та же случайная запись 4КиБ) и простоя длительностью 5, 10, 15, 25, 50 секунд соответственно. Чёрные участки (State x C) — 360 5-секундных раундов с нагрузкой, но без пауз:
Заметно, что уже на первом участке (State 1, 5+5 секунд) Kingston E50 успевает выйти из насыщения и восстановиться с 2000 IOPS до 15-20 тысяч. Чем больше время паузы, тем более стабильным становится значение IOPS — SSD за это время успевает подготовить определённое количество чистых блоков и частично освободить кэш. На графиках средней и максимальной задержки видна аналогичная ситуация:
Автор: Dmitry Nosachev
SSD корпоративного класса Toshiba HK3R предназначены для использования в серверах с высокими требованиями к производительности дисковой подсистемы с преимущественной нагрузкой на чтение.
В настоящее время Toshiba выпускает четыре линейки корпоративных SSD:
Участвующий в обзоре диск принадлежит к младшей линейке на базе 19нм MLC NAND, имеет ёмкость 480ГБ (существуют варианты на 120ГБ и 240ГБ) и ресурс в 880ТБ записи. Полное обозначение SSD серии HK3R — THNSNJxxxPCS3, где xxx соответствует объему в ГБ.
Многие заказчики интересуются, зачем вообще нужно использовать SSD корпоративного класса с обычными MLC ячейками. Действительно, в отличие от eMLC, мы не получаем ни высокой производительности на запись, ни ресурса, позволяющего без опасений долгое время использовать такие SSD под высокой нагрузкой на запись. Почему бы не использовать обычные бытовые SSD?
Причина номер один — защита по питанию. Контроллер SSD использует обычную DRAM как для кэширования записываемых хостом данных (или перемещаемых при сборке мусора), так и для хранения таблицы трансляции (в зависимости от производителя — management table или translation table. В таблице хранится соответствие между логической нумерацией блоков, которая показывается хосту, и реальным размещением данных. Аварийное выключение питания приводит к тому, что часть данных, ещё не записанных в энергонезависимую NAND-память, будет потеряна. Ситуация аналогична использованию кэша на запись (режим write-back) в RAID-контроллере без обеспечения его защиты. Естественно, для серверного применения SSD без защиты кэша не подходят.
Помимо традиционного способа обеспечения резервного питания (массив обычных электролитических конденсаторов или суперконденсаторов) в SSD Toshiba применяются дополнительные алгоритмы для защиты пользовательских данных и таблицы трансляции.
Технология Toshiba Power Loss Protection (PLP) — обычная схема, которая отвечает за обнаружение проблем с питанием, при необходимости переключает SSD на суперконденсаторы, отдавая контроллеру команду на сброс содержимого кэша на NAND.
Технология Toshiba Power Failure Management (PFM) реализована на уровне микрокода контроллера и реализует ряд дополнительных мер защиты от потери данных:
Методы, используемые в PFM, помогают снизить риск потери данных, но полная защита осуществляется только при наличии схемы резервного питания (PLP). Все SSD корпоративного класса Toshiba имеют поддержку и PLP и PFM в отличие от обычных бытовых SSD HG5d и HG6.
Причина номер два — предсказуемые ресурс и производительность. Корпоративные SSD на базе MLC имеют ресурс на 1-2 порядка меньше старших собратьев с eMLC, но в отличие от бытовых SSD он указывается в характеристиках, так что вы можете оценить применимость SSD для конкретной нагрузки. В производительности на запись MLC тоже уступает eMLC/SLC, но благо
В описанных ниже методиках тестирования производительности SSD нет ничего нового. Это первые четыре теста в соответствии со спецификацией SNIA Solid State Storage Performance Test Specification Enterprise v1.1: IOPS, Throughtput, Latency, Write Saturation. Описание и условия есть в статье на основном сайте True System: Обзор SSD OCZ Intrepid 3800.
Сам по себе обзор Kingston E100 и сравнение результатов синтетических тестов производительности с Intel S3700 тоже не представляют особой ценности. Соответствующие обзоры были опубликованы 1,5 года назад на StorageReview с примерно аналогичными результатами. Цель проста: показать, какие методики тестирования производительности SSD мы используем сейчас и намерены использовать в дальнейшем при тестировании новинок, продемонстрировать серьезность подхода в сочетании с возможностью представления результатов на красивых графиках (за что, в частности, любят тот же StorageReview). Особенно интересны будут пока еще не доехавшие до нас NVMe SSD от Intel и других производителей.
Как упоминалось выше, описание тестов, конфигурацию стенда и другие подробности можно найти в обзоре новых eMLC SSD от возрожденной OCZ (OCZ Storage Solutions) — Intrepid 3800. Остается добавить, что для самих тестов используется fio, для построения графиков (кроме 3D) — gnuplot. Для проверки выхода на установившееся состояние используется способ, описанный в спецификации SNIA PTS — проверка на выход линейной аппроксимации графика в выбранном окне за пределы +-10% от среднего значения. Пример:
В нашем распоряжении находится Kingston E100 (SE100S3200G) объемом 200ГБ, с последней прошивкой 515ABBF0.
График IOPS при различных значения размера блока и соотношениях чтение/запись:
Обычно для SSD указывают значение IOPS для блока 4КиБ на чтение и запись (значение задержки при этом не контролируется): 57147 IOPS на чтение и 22262 IOPS на запись. Производитель указывает 59000/76000 IOPS без указания методики тестирования (т.е. это пиковые значения для «свежезануленного» SSD), но и реальные результаты неплохи. Де-факто эталонный на сегодняшний день среди eMLC SSD с интерфейсом SATA, Intel S3700 продемонстрировал 30425/40524 IOPS на чтение и запись соответственно. На блоках 8К отрыв S3700 на запись увеличивается: 24125/30730 (Intel S3700) и 35514/8932 IOPS (Kingston E100).
На графике дополнительно представлен вышеупомянутый OCZ Intrepid 3800:
Ситуация со случайным доступом повторяется. На последовательном доступе аналогичная картина: чуть лучше на чтение, хуже на запись.
Проверяется задержка (средняя и максимальная) при одном потоке с глубиной очереди = 1.
Средняя задержка:
Максимальная задержка:
Сравнение с Intel S3700 для блока 4K:
Сами по себе результаты неплохи для eMLC 2012 года, но в сравнении с Intel S3700 выглядят не очень хорошо.
Непрерывная нагрузка на случайную запись (8 потоков с QD=16) блоками 4K в течение 10 часов. Такая нагрузка приводит к исчерпанию пула свободных блоков и показывает способность SSD эффективно справляться со сборкой мусора. На графиках IOPS и задержек у любых можно увидеть резкое снижение производительности после того, как заканчиваются свободные для записи блоки в основном и резервном пространстве. После этого контроллер SSD вынужден заниматься своего рода дефрагментацией ячеек с мусорными данными, размещая незавершенные IO в кэше. От эффективности алгоритма сборки мусора и аппаратных возможностей контроллера будет зависеть степень деградации производительности заполненного SSD.
График 1: IOPS.
Начинают оба SSD одинаково. Производительность в состоянии «из коробки» — порядка 43 тыс. IOPS на запись, но после заполнения Kingston проседает до 8000 против 32000 у Intel S3700. Разумеется, Write Saturation Test — это экстремальный синтетический тест и в реальности непрерывная нагрузка со 100% записью практически не встречается, у SSD практически всегда есть достаточно времени на сборку мусора для пополнения запаса чистых блоков.
Графики 2 и 3. Средняя задержка, максимальная задержка.
Среднее значение задержки в тесте WSAT вычисляется в пределах 1-минутного раунда (всего их 600), максимальное значение задержки в пределах раунда тоже записывается и по нему строится отдельный график.
Ситуация со средней задержкой опять не в пользу Kingston: после заполнения контроллер SSD начинает тратить много времени на подготовку чистых блоков и задержка вырастает в 6 раз.
Несмотря на существенно более низкий уровень средней задержки Intel S3700 демонстрирует периодические пики, превышающие среднее значение более чем на два порядка, что может не лучшим образом сказаться на реальной производительности приложений. Kingston E100 демонстрирует более стабильное поведение.
Остается реализовать остальные, более сложные тесты SNIA PTS. Особенно важным будет Demand Intensity / Response Time Histogram, показывающий зависимость соотношения IOPS/задержка от нагрузки (количества потоков и глубины очереди) и распределение значения минимальной/средней/максимальной задержки.
Автор: Dmitry Nosachev