В очередной (третий-четвёртый за несколько последних лет) раз затерев по неаккуратности файл с кодом (cp не в ту сторону), на который был потрачен предыдущий час или больше, и который ещё не был закоммичен, решил что искать его с помощью dd и grep - занятие утомительное. Слышал тут про binwalk, но, посмотрев описание, то ли не осилил найти способ её для этой цели использовать, то ли она и правда для другого.

Написал свою прогу в итоге: исходник.

Компилировать: gcc -o rawsearch rawsearch.c

Синтаксис: ./rawsearch if=/dev/sda8 str=some_string_from_file

Прога найдёт на диске все текстовые блоки (внимание: если файл фрагментирован то он будет не одним блоком а несколькими, прога их сцеплять не будет), что содержат эту строку и создаст пачку файлов с названиями found-NNN (NNN - байт где начинается) с этими текстами. Границы текстовых блоков определяются так:

static int is_binchar(char c) { return (c==127 || c>=0 && c<=6 || c>=14 && c!=27 && c<=31); }

(это символы которые по мнению проги в текстовых файлах не встречаются).

Возможно кому-то будет полезно.

Исходник максимально простой (всего 300 строк и 12кб), можно легко патчить под какие-то потребности по месту.

Добрый вечер. Скажите, пожалуйста, какие сейчас есть СУБД для OLAP? Нужно быстро крутить ~5ТБ, делать группировки и отдавать в BI. Единственное, что приходит в голову - затюненный под DWH Оракл. Ещё есть Кликхаус, но кажется, это немного локальный продукт. Т.к. важна скорость отклика, экосистема хадупа не подходит.

Господа,

Возникла производственная необходимость организовать примерно 1PB directly attached storage (в терминах usable space, not physical space), более того - с возможностью расширения дальше. Не спрашивайте зачем - нужно, и будет сделано так или иначе. Понятно что оно будет собрано из пары сотен 12TB дисков (или что там нынче доступно из железа в SAS). Есть у кого практический опыт? Готов пообщаться offline.

ПыСы. Первый опыт с 0.5PB на «голом» LVM был скорее неудачен, точнее мне совсем не нравится то что я вижу: stripe unit of ~1MB, т.е. довольно надолго даже при последовательной записи (typical write load) нагружается только пара шпинделей. И чтение (всегда короткое по 8k, random across the board) тоже совсем не на тех скоростях которые я бы хотел видеть.