Блог:Виталий Филиппов

Материал из YourcmcWiki
Перейти к: навигация, поиск

Технические вопросы и вменяемые заметки от меня, Виталика.

У меня, конечно, уже есть блог Ljuser.gifsimply_a_man.

2019-02-06 Ночью через лес

Про доклад «Ночью через лес»… https://youtu.be/oMQLR-BhnJU

…по болоту на тандемном велосипеде с крыльями.

Ко мне тут (4.02.2019) однокурсник обратился с вопросом — типа он там щас работает в этой конторе. У них хранилище ФАЙЛОВ (30-50 тб, правда, в основном мелких) в Кассандре. Было то ли на 4 то ли на 8 серверах, диски в RAID-ах и поверх bcache.

Щас они этот кластер — внимание! — переместили в один сервер в докеры, оставив 16 дисков и 16 узлов (но убрав bcache), то есть теперь 16 кассандр в одном сервере (зачем? потому что так дешевле).

И вот короче встал вопрос: извне всего ~137 rps, объекты по <= 64 кб. 64кб*137 = всего где-то ~9 мбайт/с. Но при этом 16 дисков (HDD) загружены по самое не балуйся, на каждом чтение >= 100 мбайт/с. Вопрос: какогохуя?)))

Я его спросил — а на#уя в кассандре? — а он мне скинул ссылку на этот доклад — я открыл, начал смотреть и думаю — б#я! я же помню этого мужика!

И точно — он в 2012 году на highload рассказывал, как пи#дато файлы в postgres-е хранить: Highload-2012: Отчёт Виталия Филиппова#Спасение 6 млн файлов в условиях полного Хецнера / Даниил Подольский, Дмитрий Симонов (Setup.ru)

То есть типа сначала у них всё типа было просто в локальных ФС на двух серверах и синхронизировалось rsync-ом. Потом у них кончилось место на серверах, обход дерева директорий стал занимать очень много времени (8 часов), и они засунули файлы в postgresql с мастер-мастер репликацией.

Потом оказалось, что крупные файлы неудобно хранить просто в поле и они их засунули в блобы. А потом обнаружили, что блобы не попадают в репликацию! Ну и в целом, что всё это грузит постгрю. Тогда они вынули из postgresql всё, что было больше 64к и сунули в LeoFS. LeoFS — это такая попытка сделать Ceph, но очень хреновая.

Потом в leofs кончилось место, они попробовали добавить пару серверов… и leofs развалился на хрен. Они позвонили японцам-авторам, те их час послушали и сказали «простите, у нас кончилось время, до свидания».

Они с помощью видимо такой-то матери убрали добавленные сервера обратно — и оно опять работало, пока в leofs не кончилось место окончательно.

И тут… им пришла свежая мысль — засунуть это всё в aerospike. Засунули, на 8 серверов. И оно вроде опять заработало, да ещё и кластеризация автоматическая появилась. Про это был доклад уже в 2015 году.

Продолжение я знаю уже из вопроса однокурсника: Aerospike их, видимо, тоже не устроил и сейчас у них всё это уже в кассандре!

И вот этот дядя на Highload нам рассказывает, что Ceph, который под это идеален, они пробовали и им было медленно (да ещё и «ребаланс по каждому чиху, при котором кластер вообще нельзя эксплуатировать»)… Жопой чую — у них там и сеть была 1G, конечно, какой уж тут ребаланс…

И это всё на продакшне. Эпично. Там ещё гениальный вопрос в конце доклада есть — типа, а вот когда у вас кончилось место в 2 серверах — почему вы… просто не добавили ещё 2?))))))) — «а чо, так можно было?…»

Просто плотно проработав последние несколько лет с Ceph-ом слушать это мегаржачно! Это вот Ceph значит медленный, а кассандра, которая грузит все диски на 100 % — быстрая? И это у них ещё записи нет. Была бы запись, было бы примерно как с KVStore-ом, когда 80 % i/o занимал compaction (KVStore — это промежуточная попытка апгрейда хранилки в ceph между filestore и bluestore).

Бэкапы он тоже не делает — ну, типа, реплика же есть, да и откуда ещё 30 тб взять.

Третья серия — это второй доклад 2015 года — https://youtu.be/bOqSexPzSIE?t=1702 - в нём он уже не такой весёлый и просто рассказывает, как всё сложно с этими вашими файловыми хранилищами.

2018-06-27 Тестирование различных способов подключения SSD для Ceph

Задача: проверить гипотезу, что дешёвые SSD без конденсаторов можно подключать к системе через RAID контроллер с батарейкой для получения приличных IOPS-ов в Ceph (хотя это и извращение).

TL;DR: похоже, можно. IOPS-ы растут, а данные потерять не удалось. Но, конечно, это всё равно в некоторой мере стрельба в ногу, поэтому лучше просто купить недорогие Enterprise SSD с «advanced power loss protection» типа Micron 5100/5200.

UPD: Предложенную идею официально считать дичью, делать так не надо.

→ продолжить чтение…

2018-06-26 Пенсионная математика

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

Можно заюзать вот такую математику.

Если предположить, что:

  • пенсии субсидируются исключительно налогом с зарплат
  • средняя зарплата в стране 36000 руб
  • средняя пенсия в стране 14000 руб
  • количество пенсионеров 30 %
  • количество работающих 54 %

(все цифры взяты из интернетов, предположим что близки к реальности)

Тогда налог будет 14/36*30/54 = 21,6 %

Что характерно, весьма близко к реальности — реальность 22 %.

С одной стороны, правда, в среднем в реальности меньше, так как всякие льготы и «регрессивная» шкала налога. С другой стороны, вроде и ПФР субсидируется не только налогом с зп. Ну и сам очевидно жрёт — но поисследовать сколько он жрёт вопрос к исследователям типа ФБК ну и не знаю,… ФСБ там.

В общем, если так смотреть — то вроде:

  • по мне как-то не видно явной необходимости повышать возраст.
  • реальная проблема России в низких зарплатах. из-за низких зарплат и пенсии низкие.

А, да, и ещё соответственно накопительная система была в принципе тоже логичным решением проблемы — тогда типа убралось бы «усреднение» — у кого зп большая, была бы и пенсия большая (в теории), а у кого маленькая — была бы и пенсия маленькая. Но «получилось как всегда», так как у будущих бабушек в усть-задрищенске зарплата мизерная, а содержать их надо (ну в принципе логично что надо — вроде там это… помощь незащищённым слоям населения и всё такое). Вот и закопали её видимо.

Но по сути правильное решение — постараться обеспечить рост средней з/п по стране + оптимизировать нецелевые расходы ПФР (в России же живём, наверняка там их можно найти) + продолжать сколько-то субсидировать, наверное.

И ещё на самом деле сам этот налог — для мелкого бизнеса идиотский совершенно. Вот допустим ты ИП и работаешь на себя — платишь только фиксированный взнос 28000 в год в ПФР и 6 % налога с выручки.

А потом вдруг хочешь нанять ОДНОГО сотрудника и хренак!!! Сразу 43 % налога!!! Из которых 22 % это ПФР, 8 % прочее и 13 % НДФЛ. И ещё твои 6 % тоже ведь никуда не деваются.

Как-то это тупо, разрыв слишком огромный. Выходит либо никого не оформляй и работай в чёрную, либо оформляй на 10000 руб оклад и снижай ту самую среднюю з/п по стране, либо ищи где-то лишних 43 % бабла, что для мелкого бизнеса весьма проблематично.

Какой-то более мягкий переход должен быть, тогда мелочь повылезает из чёрных/серых окладов и небось и средняя з/п тоже повысится и фактические отчисления в ПФР…

2018-01-01 Всё-таки Redux - отстой

Всё-таки Redux кривоват.

Ну просто вот пример — есть там, не знаю, в приложении таблица «города», и надо сделать компонент подсказки городов — автокомплит.

Есть библиотечный автокомплит, поверх к нему, соответственно, надо дописать функцию, которая подгружает сами данные, чтобы дальше использовать в ДВУХ и более местах приложения БЕЗ копипастинга. Например просто два поля подряд даже вставить — ну типа город1, город2, или город юзера / город компании, или ещё что-нибудь.

Состояние у автокомплита — это:

  1. введённый текст (не обязательно совпадающий с выбранным значением)
  2. текущие подгруженные опции
  3. выбранное значение (но оно, по идее — не его личное состояние, а кусок тех данных, которые собственно редактируются в этом поле)

И действия:

  1. обработать изменение введённого текста (подождать 200мс, отправить запрос на подгрузку опций)
  2. обработать ответ на запрос подгрузки — залить опции в состояние
  3. обработать событие выбора опции — залить выбранное значение в состояние

Вопрос: КУДА всё это пихать?

Если Redux, то Redux говорит, что вроде как ВСЁ пихать в Store. Но Store глобальный => получается, что когда ты вставляешь в ДВА или более места свой компонент, ты должен:

  1. заставить его брать данные из РАЗНЫХ мест из стора
  2. заставить его отправлять Reducer’у какие-то ДРУГИЕ действия (по-другому именованные видимо — типа «field1_load_autocomplete», «field2_load_autocomplete»)
  3. потом ещё и заставить Reducer(ы) их обрабатывать

Получается, что по идее ради 1 и 2 ты, как минимум, занимаешься копипастингом mapStateToProps/mapDispatchToProps/connect(), а ради 3 ты ещё и копипастишь обработчик action’а, или подключение обработчика, возможно через combineReducers(), но всё равно тебе как минимум один action в нём придётся как-то переопределить — чтобы значение-то итоговое сохранять туда, куда нужно.

Вопрос: НА#УЯ всё это надо?

Если с голым React’ом ты просто все эти обработчики ляпнешь прямо в компоненте, и стейт будет там же, а значение наружу будет передаваться колбэком.

И в этом случае чтобы повторно использовать компонент ты как бы да, просто напишешь <CityAutocomplete value=... onChange=... />.

Не, я понимаю, что ВРОДЕ типа кажется круто полностью отделить работу с данными от рендера, ВРОДЕ типа круто при серверсайд рендеринге (подгрузил состояние и продолжил с того же момента), при извращениях типа живой отладки с сохранением состояния при изменении кода…

Но если при этом теряется переиспользуемость компонентов — это какое-то фуфло.

Короче, резюме: React, похоже, надо юзать голый, БЕЗ Redux’а.

2017-12-14 История одного просветления, произошедшего пару лет назад

Надо запротоколировать — прикольная история.

Когда я на это напоролся, у меня было, собственно, открытие — я полностью прочувствовал, что PHP по дефолту не умеет обрабатывать 2 параллельных запроса от одного юзера.)))

Суть такая: в PHP сделано тупое, но надёжное решение для исключения параллельной записи данных одной сессии двумя процессами — сессия тупо блокируется на весь период от её открытия до закрытия. А открывается она обычно в начале запроса — а закрывается в конце.))

Следовательно, если никто ничего специально не предпринимал — 2 параллельных запроса от одного и того же юзера пхп выполнять не умеет :) ну то есть, например, невозможно параллельно открыть нескольких вкладок с одного сайта — они последовательно открываться будут.

Оно понятно, зачем сделано — если не блокировать, то что окажется в итоге в сессии — неизвестно — два процесса могут писать в сессию параллельно и один может перезаписать данные другого. И оно обычно как бы не страшно, так как да, действительно сайтики редко кто так насилует, а если и насилует, то типа нефиг же — типа, тоже мне кулхацкер, у нас тут и так 100500 юзеров параллельно, а ты ещё и свои запросы хочешь в параллель пускать, падла?!

И видимо, когда народ в PHP переключает сессию на redis и говорит, что всё стало «летать» — летать оно начинает именно потому, что redis хранилище сессий в пхп не делает блокировку — не то что это его фича — просто не умеет оно в блокировки :)

А вот теперь история, как я на это напоролся:

Ставил я VisualEditor (визуальный редактор для MediaWiki) и хотел его подружить с нашими правами (IntraACL). Для справки — в VisualEditor википеды же тоже прилично извратились — конфигурация там такая — сама вики на PHP, но рядом, чисто для VisualEditor’а, на сервер ставится node.js.

В котором выполняется parsoid, служащий бэкендом к VisualEditor’у. Parsoid — это частично переписанный на js парсер медиавики — полностью не осилили и не осилят никогда, уж больно там говнокода много на него завязано.

И запросы идут через такую жопу: браузер -> PHP -> node.js -> (а дальше нода же хочет получить текст страницы, которую правишь) -> обратно запрос в PHP.

И по дефолту на втором запросе к PHP они его сессионную Cookie ему обратно не передавали. Соответственно, у нас из-за прав доступа отредактировать страницу не удавалось — но зато эта конструкция вообще работала! :)

А когда я включил передачу куки юзера на этом запросе, чтобы нода читала текст страницы с учётом прав — вся эта конструкция стала радостно повисать. Я чуть башку не сломал, а оказывается, это была как раз блокировка сессии. Второй запрос же «вложен» в первый и запускается в той же сессии => 2 ждёт, пока кончится 1, а 1 ждёт, когда закончится 2. Дедлок.

Вот тогда у меня и случилось просветление.))

А после внедрения в медиавики неблокирующей работы с сессией, естественно, попёрли гонки и стала иногда отваливаться авторизация. Причём, почему-то, в том числе при вызове из скрипта репликации, который вообще однопоточный — там до сих пор гонка бывает, я так и не понял пока, откуда она там — для обычных-то юзеров поправили, конечно.

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

Короче: какая-то, с*ка, светлая голова в SemanticMediaWiki впилила для пересчёта какой-то очередной внутренней хрени обработчик очереди. Стандартной медиавиковской очереди — есть у неё в ядре очередь задач, и можно туда свои задачи пихать.

Но так как стандартная обработка заданий идёт в том числе потихоньку в конце каждого запроса, после отдачи страницы юзеру (ну, типа, чтобы работало даже там, где демона не запустишь) — эта, с*ка, светлая голова решила, что это же будет тормозить! И реализовала обработку самого задания через дополнительный запрос с сервера на самого себя, к URLу который фактически обрабатывает задание.

И оно как-то большей частью даже прокатывало… пока пользователь не открывал 2 вкладки одновременно — после чего висло нафиг 2 процесса сервера, а после N повторов висли все доступные процессы сервера и вики переставала отзываться. Причём все такие спокойные — загрузки CPU нет, никто ничем не занят, а вики висит — все в дедлоках.

Сами википеды на свои сессии тоже вроде потом напоролись, но уже после меня (после 1.26) — и то ли в 1.27, то ли в 1.28, вроде, переосмыслили своё поведение.

2016-09-23 Thin RAID5

Блин. А есть в Linux’е что-нибудь такое, чтобы сделать RAID5, но без необходимости полного resync’а? То есть что-то типа thin provision, чтобы блоки под RAID выделялись по запросу. В идеале — чтобы оно при этом поддерживало извращённые схемы расположения, то есть например 3-дисковый (2 данные, 1 чётность) рейд на 4-х дисках 3+3+2+2 тб.

Это кстати очень даже возможно — 3+3+2+2 нарезать на 6.66 тб RAID5! Схема такая: сначала кладём по 2тб на первые 3 диска, остаётся свободных 2*1тб и 1*2тб, кладём на них ещё по 1тб, остаётся 1тб свободный. Дальше забираем 0.33тб из первой группы с 1-го диска и 0.33тб из второй группы со второго диска и перекладываем на свободный 1тб, и на освободившееся место дописываем новую группу 3*0.33тб.

То есть вот так схема выглядит:

111422333
114222333
111222
333214

Вот. ceph так умеет, но он сетевой и распределённый, локально не поюзаешь. ZFS… «thin raid» умеет, но не умеет его расширять — то есть ещё диск не добавишь.

А с LVM, например, нельзя так извратиться?

2016-09-08 Тестирование скорости дешёвого SSD Silicon Power Slim S55 120Гб

Спойлер: Чтение приличное, а вот скорость записи — не очень (устоявшаяся 95 Мб/с).

Отчёт о реальных скоростях данного SSD. Тестировал утилитой fio, под Linux. Глубина очереди везде 128, планировщик noop, слияние запросов в очереди для теста отключено. При снижении глубины очереди производительность сильно проседает; ну, так и не надо её снижать.

  1. Последовательное чтение в идеальном случае (блоками >= 256кб) — 550 Мб/с
  2. Последовательное чтение блоками по 4к — в среднем 190 Мб/с, но прилично колеблется в пределах 170—280 Мб/с
  3. Последовательное чтение блоками по 8к — 370 Мб/с; по 16к — 450 Мб/с; по 32к — 500 Мб/с; по 64к — 530 Мб/с; по 128к — 540 Мб/с. Тут уже все цифры абсолютно стабильны, не колеблются.
  4. Случайное чтение блоками по 4к — 170 Мб/с (~41000 iops), тоже колеблется в пределах 120—220 Мб/с.
  5. Случайное чтение блоками по 8к — 305 Мб/с. По 16к — 340 Мб/с. По 32к — 380 Мб/с. По 64к — 440 Мб/с. По 128к — 510 Мб/с. По 256к — 535 Мб/с (это уже фактически последовательное чтение, а не случайное). Тут скорость опять стабильна, практически без колебаний.
  6. Есть «псевдо-SLC кэш». Последовательная запись первых 2.4 Гб блоками по 4к — 244 Мб/с. Крупными блоками (>= 256к) — 490 Мб/с.
  7. После 2.4 гб запись устаканивается на уровне 95 Мб/с, независимо от размера блока (SLC кэш кончается).
  8. Скорость случайной записи абсолютно идентична скорости последовательной записи.
  9. Скорость записи сохраняется постоянно, в том числе после полной перезаписи всего диска без TRIM.
  10. 30 секунд простоя достаточно, чтобы SLC кэш сбросился и запись вернулась к 490 Мб/с.

Наибольший «физический смысл» имеют случайные чтение/запись блоками 4к (стандартный размер блока ФС как в винде, так и в линуксе), а также последовательное чтение/запись блоками по 16к (так будет, если программа читает по 4к, а драйвер будет объединять соседние запросы), ну либо уже максимальными блоками (если программа копирует данные крупными блоками).

В общем, с чтением всё ок, но огорчает устоявшаяся скорость записи, 95 Мб/с — для SSD мало. Хотя, наверное, за эти деньги ожидать чего-то сильно лучшего и не приходится.

2016-09-07 ФС для флешек

Давно уже люблю на всяких мелких/тестовых серверках / с флешек монтировать. Удобно — места под rootfs много не надо, а скорость чтения — что случайного, что последовательного — вполне адекватная.

Другое дело, что случайная запись с обычными ФС типа ext4 очень медленная, флешки — это не SSD, гигагерцовых контроллеров и гигабайтов оперативки у них внутри нет — потому и Translation Layer внутри тупой, всё, что он обычно умеет — это «открыть» (стереть) и держать «открытыми» 2-3-4 блока стирания (обычно по 2 мб) и поддерживать в них последовательную запись. То есть, случайную запись мелкими блоками флешки не переваривают вовсе — iops на запись при этом обычно ограничивается 3-4 запросами в секунду.

Стандартно это решается лог-структурированными ФС, которые никогда не перезаписывают файлы «на месте», а всегда дописывают новую версию «в конец», одновременно постепенно освобождая место от старых блоков «в начале». То есть такие ФС чем-то похожи на кольцевой буфер :). И такие ФС под linux есть, я их ещё раньше уже тестировал: ubifs, jffs2, yaffs, logfs, nilfs2… фиг кстати знает почему, но в прошлый раз я почему-то остановился на ubifs, хотя она (как и jffs2, и yaffs) предназначена для MTD (голой флеш-памяти, не блочных устройств) и монтировать её одно извращение, и после краша она ещё не восстанавливается потом.

На самом деле из этих лучше брать nilfs2 — вроде самая живая и для блочных устройств подходит. Правда есть у неё как минимум один «нюанс» — на пустой ФС можно получить ошибку «нет свободного места», потому что она защищает (отказывается удалять) часть недавно созданных снапшотов. Время защиты вроде бы задаётся параметром `-o pp` при монтировании, но что-то я даже с pp=1 эту ошибку всё равно время от времени (при интенсивной записи) получал. Да и в общем в стабильность её работы у меня, честно говоря, особой веры нет. Экзотика, в общем.

Ещё отдельный юмор — это самсунговская F2FS (Flash-Friendly FS). Фиг знает, в каком она месте friendly и зачем она вообще создана — случайную запись она не ускоряет вообще.

Вот… некуда казалось бы податься любителю флешек. Но вчера возникла у меня идея — есть же btrfs! А в нём cow по дефолту для всех данных! Это ж как раз то, что нужно! И популярная, и по стабильности — не ext4, конечно, но я думаю уж точно получше экзотических nilfs’ов.

И таки точно! Берём обычную флешку (5 мб/с скорость последовательной записи), бенчмаркаем случайное чтение+запись блоками по 4-16кб (с помощью fio, в 8 потоков). Получаем суммарно (чтение+запись):

  • ext4=7.15 iops
  • f2fs=7.38 iops
  • nilfs2=160.8 iops (лог-структурированная ФС)
  • btrfs=128 iops (круто, почти не хуже чем nilfs2)

Короче всё, я на флешках буду btrfs теперь юзать.

2016-08-27 Математическое наблюдение на тему MTBF и AFR

Есть такой параметр, заявляемый производителями жёстких дисков — MTBF (Mean Time Before Failure), среднее время наработки на отказ. Ясно, что он чисто маркетинговый, так как очевидно, что невозможно честно определить его для новой модели. И фигурируют там обычно миллионы часов, самое меньшее 800000 — аж 91 год с гаком.

И вот непонятно — а какого чёрта харды вообще мрут при такой оценке надёжности? :-) ну как же, он 91 год в среднем прожить должен?

Ответ кроется в математике. Есть более осмысленный параметр — AFR (Annualized Failure Rate), вероятность выхода из строя в течение года. По статистике Backblaze (кроме них никто её по ходу не публикует) реальный AFR у дисков Seagate и WD как минимум процентов 5-10, у некоторых «особо надёжных» моделей аж 25-28 %, и даже у дисков HGST не ниже 0,8 % (а в основном 1-1.5 %).

А давайте попробуем по AFR посчитать MTBF? Если предположить, что AFR диска не меняется со временем, то MTBF в годах = 1*(1-AFR) + 2*(1-AFR)² + 3*(1-AFR)³ + … (матожидание числа лет). Разворачиваем формулу дважды в сумму геометрической прогрессии (так как это по сути сумма геометрических прогрессий, начинающихся с 1… 2… 3… и т. п. членов), и получаем MTBF в годах = (1-AFR)/AFR². Можно записать это и наоборот, решив квадратное уравнение, и получить AFR = (-1 + sqrt(1+4*MTBF)) / (2*MTBF).

По этой формуле MTBF 800000 часов = 9,93 % AFR, MTBF 1400000 часов = 7,6 % AFR, MTBF 2000000 часов = 6,4 % AFR. А 1 % AFR соответствует MTBF аж 86724000 часов! То есть, в принципе, MTBF 800000 часов не так уж и много, так как на самом деле он означает, что 10 % дисков выйдет из строя в первый же год :-).

Упс. В вычисления закралась досадная ошибка — правильная формула MTBF в годах = AFR + 1*AFR*(1-AFR) + 2*AFR*(1-AFR)² + 3*AFR*(1-AFR)³ + … = AFR + (1-AFR)/AFR. Соответственно AFR = (MTBF+1 — sqrt((MTBF+1)²-4)) / 2.

И, соответственно, никаких впечатляющих % там не будет — 800000 MTBF = 1.08% AFR, 1400000 MTBF = 0.62% AFR, 2000000 MTBF = 0.44% AFR. Ну ладно, тогда да, MTBF — просто ничего не значащая маркетинговая цифра :). Даже 1.08% — абсолютно нереально реально, современные HGST так и живут. Но когда я это писал, было таки нереально.

UPD: Вторая версия формулы, по-моему, тоже была неправильной, но, что удивительно, численные результаты получились верными. Правильно так:

MTBF = 1*AFR*(1-AFR) + 2*AFR*(1-AFR)^2 + ... = Sum_{i=0..+inf}((1-AFR) * (1-AFR)^i) = (1-AFR) / AFR
1 - AFR = MTBF * AFR  <=>  AFR = 1/(1+MTBF)

По этой формуле MTBF 800000 часов = 1.08% AFR, MTBF 1400000 часов = 0.62% AFR, MTBF 2000000 часов = 0.44% AFR.

А, и ещё картина по идее может зависеть от распределения отказов — интуиция подсказывает, что вряд ли оно равномерное. Но сильно, наверное, это вряд ли повлияет, так как вот тут http://www.cs.cmu.edu/~bianca/fast/ есть статья, из которой видно, что, по-видимому, лет где-то до 5 каждый год вероятность отказа неуклонно возрастает, а потом даже немного снижается.


2016-08-21 Паттерн бэд блоков в ddrescueview

Короче прогнал ddrescue на своём сдохшем Seagate Constellation ES.3 3 тб (ST3000NM0033). Вот такая картина (ddrescueview):

Ddrescue1.png

Если поближе, то вот:

Ddrescue2.png

О чём нам говорит такой паттерн? Судя по всему, об одной полностью сдохшей головке. Если посмотреть на цифры, то становится чётко видно, что картина по всему диску следующая — в начале диска идёт 50мб читаемых, 50мб нечитаемых, потом 600мб читаемых, потом примерно 50мб нечитаемых, 100мб читаемых, 50мб нечитаемых и дальше так и повторяется — 600-50-100-50… 600мб ближе к концу диска (к центру пластин), на самом деле, превращается в ~265мб, но соотношение всё время сохраняется чётко — 12:1:2:1 (где-то 11.8, где-то 12.2, но суть одна).

Блина у этой модели 4, головок 8. Потеряна как раз 1/8 данных. Логично, что это как раз и должно означать мёртвую головку. Единственным непонятным для меня моментом был паттерн — я думал, раз головок 8, хард с них должен читать по порядку — 12345678 12345678 и т. п. Но тогда картина читаемых-нечитаемых областей выглядела бы как 7-1-7-1-7-1…, а не 12-1-2-1-12-1-2-1…, как у меня.

Ответ, оказывается, простой — вместо традиционной схемы диски сейчас применяют также схемы «Cylinder Serpentine», «Surface serpentine» и их комбинации. В моём случае это как раз «Cylinder serpentine»: 12345678 87654321 12345678 87654321…, и плохая тут, видимо, как раз 2-я головка: 1(2)345678876543(2)11(2)345678876543(2)1…

Такой вот получился «RAID 0» из одного диска — сдохла одна головка, а потеряется почти всё, так как все данные дырявые, максимальный размер неповреждённой области — 614 мб.

Интересные ссылки по теме:

2016-07-30 Корпус Aerocool - наедалово

Твою мать! Козлы! https://market.yandex.ru/product/9275336, https://market.yandex.ru/product/9275333 - написано, что безвинтовое крепление HDD, в отзывах кто-то подтверждает — да, безвинтовое крепление, да, удобно.

А там оно не то что безвинтовое! Там и винтового-то не очень! Схема крепления через дикую жопу. Какие салазки, вы о чём! Крепления хардов просто какой-то суперизвращенец придумывал:

  • два 3.5" в самом низу на винтах, вставляются со стороны материнки.
  • один 2.5" плашмя на отведённом месте + с ОДНОЙ стороны крепится винтами.
  • один 2.5" аж вертикально, крепится к панели внутри корпуса 4 винтами.
  • один 3.5" плашмя на отведённом месте под 5.25" отсеками и крепится винтами.
  • и один 3.5" прикручивается к специальной 5.25" панельке-переходнику, к ней же по желанию под хард лепится доп.вентилятор (если докупишь) и этот страшный бутерброд ставится в 5.25" отсек.

И ещё остаётся пара свободных 5.25" отсеков (нафиг они вообще нужны в 21 веке). ЖЕСТЬ.

Повёлся блин на описание товара. Заказал, теперь возвращать буду.

2016-07-21 Опа! В связи с законом о перс данных Seagate гарантии больше нет

За#бцааааа…

Гарантия производителя на диски Seagate Constellation ES.3 — 5 лет, но похоже, что теперь в связи с законом о персональных данных ей невозможно воспользоваться: http://www.seagate.com/ru/ru/support/russia-law/

Типа мы же иностранная компания, гарантийные запросы обрабатываем за рубежом. А они включают персональные данные.)). запретили обрабатывать персональные данные — вот и идите со своей гарантией в жопу в магазин, где покупали. :-))

Это у меня такой хард дуба дал. производство 2013, купил либо в 2013, либо в 2014, гарантия в магазинах обычно года 2-3, но главное чек не могу найти и не помню где брал…

2016-07-21 Helvetica Neue Condensed

Всегда считал, что Helvetica — это тот же Arial, а так как Arial не люблю, считал, что и Helvetica — отстой. Потом, правда, понял, что в мелких размерах Arial выглядит неплохо, но уже было не важно).

А недавно открыл для себя, что Helvetica Neue ещё бывает Condensed и вот это классный шрифт. Правда, в теории платный, но кого ж это волнует на самом деле, он настолько похож на свободный Roboto Condensed, что фактически можно юзать его (хотя субъективно гельветика чуть поаккуратней). Ещё один похожий шрифт — PT Sans Narrow (но он-то точно покривей). Вот все три:

Condensed.png


Посередине Helvetica, сверху Roboto, внизу PT Sans.

2016-06-27 Минутка юмора nodejs

Задача: вытащить часть пути до первой части, содержащей glob-паттерн (glob — это стандартные шаблоны имён файлов: * ? [] {}).

Решение: один регэксп, да? Нееееет!

Для node.js есть целая библиотека glob-parent. Очень содержательная:

var path = require('path');
var isglob = require('is-glob');
 
module.exports = function globParent(str) {
	str += 'a'; // preserves full path in case of trailing path separator
	do {str = path.dirname(str)} while (isglob(str));
	return str;
};

Не, ну наверно там парсинг сложный, да? Давайте посмотрим, как написан is-glob:

var isExtglob = require('is-extglob');
 
module.exports = function isGlob(str) {
  return typeof str === 'string'
    && (/[*!?{}(|)[\]]/.test(str)
     || isExtglob(str));
};

Гм. Ну что ж, может вся хитрость в is-extglob?

module.exports = function isExtglob(str) {
  return typeof str === 'string'
    && /[@?!+*]\(/.test(str);
};

Это весь код этих 3-х библиотек, ну за исключением всяких README и package.json, конечно… которые там в 5 раз больше.

Alice-facepalm.jpg

2016-06-16 ClickHouse

ВАУ! ЖИР!

Яндекс сделал опенсорсную столбцовую СУБД! ClickHouse.

https://github.com/yandex/ClickHouse

https://habrahabr.ru/company/yandex/blog/303282/

2016-03-04 А между прочим, в 5-м Android'е (в ART) запилили именно то, о чём я говорил

А между прочим, в 5-м Android’е, в новом рантайме ART, запилили именно то, о чём я говорил!

А именно — «разделяемые assembly». То есть чтобы можно было писать dalvik-библиотеки, которые не нужно, как jar’ники, загружать заново в каждый java-процесс.

Именно это и сделано в ART (ART — прозрачная замена Dalvik): вместо JIT-компиляции они теперь перешли к AOT, dex’ы теперь компилятся в нативный код, складываются в файлик на диске, а потом из него mmap()ятся — и, соответственно, ведут себя приблизительно как обычные .so’шки, не сжирая память отдельно в каждом процессе. Точно так же это сделано и в .NET — чтобы assembly превратить в разделяемый код, нужно её прекомпилировать.

Зиготу (zygote), правда, всё равно оставили, чтобы держать в общей памяти ещё и преинициализированные данные, и таким образом всё-таки экономить ещё чуть-чуть памяти. Но всё равно молодцы. По сути, это теперь получается, что ART чуть ли не круче самой явы :) вот бы его на десктопе попробовать с java кодом… :)

2016-03-01 Тупняк, но реально Quadro и FirePro - нае..надувательство

Обалдеть, вот дурь-то. Производимые и Nvidia, и AMD «профессиональные» видеокарты (Quadro, FirePro) — тупое искусственное разводилово. Просто в «непрофессиональных» на уровне firmware обрезают часть функционала и производительности в числах двойной точности, а аппаратно они ИДЕНТИЧНЫЕ.

В качестве пруфа можно привести тему на форуме, в которой чувак путём перепайки пары SMD-резисторов смог поменять PCI ID своей GTX690 и она ВНЕЗАПНО превратилась в Quadro K5000: http://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-their-professional-counterparts/

Жёсткое нае..дувательство, я бы такое запретил законодательно… запретил бы физически один и тот же продукт продавать по разной цене и под разными названиями. Вполне, по-моему, на мошенничество тянет)

2016-02-19 Уроды на службе FCC

Вашу ж мать. TP-LINK уже внедряет запрет обновления прошивки в соответствии с уродством FCC... http://www.opennet.ru/opennews/art.shtml?num=43907

2015-12-30 Итоги 2015 года

В общем, по итогам 2015 года стало чётко ясно, что всё это не временный маразм и кризис, а вполне осознанно установленный курс:

  • внешнеполитический — на конфронтацию с Западом
  • внутриполитический — на защиту жуликов и подавление оппозиции
  • в интернете — цензурно-запретительный
  • в рубле-баксе — 50р за $ уже видимо не будет никогда, не говоря уже о 35. дай бог на 80-90 не улететь.
  • народного протеста не будет — половина ЗА, половина просто делает вид, что ничего не происходит

Всё это было и в 2014 году, но тогда надежда на скорое выравнивание ситуации ещё была, а теперь, по-видимому, понятно, что это было лишь начало тренда, а ближайшие лет 3-5-10 будет продолжение.

Так что чем НГ ближе, тем что-то мне грустнее…

Вот кстати хорошая статья по теме: http://www.gazeta.ru/column/vladislav_inozemcev/7996685.shtml

...И подчеркну еще раз: ничто из отмеченного не привлекает особого внимания.

Это означает только одно: в отличие от 1998, 2008 или 2014 годов, кризис стал восприниматься в России как нечто обыденное.

Это огромный успех российской власти: народ окончательно превратился в безмолвную массу. Даже многократно обсуждавшийся протест дальнобойщиков не привлек к себе широкого внимания и не породил волны поддержки не потому, что их требования показались кому-то несправедливыми, а скорее, потому, что все хорошо понимают: против пожеланий власти народ бессилен, и ничего не изменится, сколько ни протестуй.

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

2015-08-01 Юхуууу тесселяцияяя!!!

Юхууу! В последней мезе запилили тесселяцию и сразу OpenGL 4.1! Кроме гит-версии мезы, всего-то надо LLVM 3.7 поставить, а к осени это уже будет релиз. «Я джва года ждал» (ц) :-)

Снизу — тесселяция включена, сверху — выключена.

Youhooo GL4.1.jpg