Вопросы Теги

Я могу узнать, находится ли данный ext4 блок в inode таблице, и если так, я могу выбрать его из журнала без заголовка вручную?

Для профилирования mysql управляют, чтобы Вы могли использовать SHOW PROFILE

mysql> SET profiling = 1;
mysql> [type your query here]
mysql> SHOW PROFILE;

и получить больше информации о том, что сделал бы mysql для получения желаемого результата, Вы могли использовать EXPLAIN.

mysql> EXPLAIN [type your query here]

Хорошие начальные точки для оптимизации являются использованием индексов и увеличением использования памяти в my.cnf (параметры по умолчанию могли быть очень низкими). Если Вы удаляете много данных в таблице OPTIMIZE TABLE могло также быть полезным.

OPTIMIZE TABLE table;

В любом случае необходимо использовать вывод ВЫСТАВОЧНОГО ПРОФИЛЯ для определения, какие части требуются большое количество времени и стоят быть оптимизированными.

Знайте к переключателю кэша запроса при оптимизации. Вы обманули бы себя иначе.

6
02.01.2015, 03:33
1 ответ

Во-первых, отличный вопрос!

Коммутатор -E показывает только среду в момент запуска процесса, поэтому любые изменения будут невидимы для этого метода. Таким образом, если данные загружаются в среду после запуска процесса, то он не будет обнаружен через этот метод. Однако это, скорее всего, не выполнимая стратегия, ИМХО, по причинам, обсуждаемыми ниже.

Я согласен с Двенадцатом фактором, что уловка вариабельной среды - это путь. Тем не менее, существуют некоторые важные предостережения, которые не были четкими в руководстве в двенадцати факторе, а также в некоторых практических соображениях и техниках, чтобы добраться туда.

Во-первых, переменные среды являются волатильными (непостоянными). Все данные теряются при перезагрузке. Это означает, что если конфигурация нет где-то сохраняется , она будет невосстановлена ​​в случае перезагрузки сервера, если только он не находится в памяти в / dev / main0 sys-admin (не азартная игра я бы сделал с 128-битными ключами). Если это частный ключ сервера, у вас есть лучший главный и в худшую катастрофическую проблему на ваших руках (ваш CA может потребоваться повторно выдать ключи). Это делает хороший случай, когда конфиг должен быть записан где-то, и я не думаю, что многие будут оспаривать это. Где / как его хранить, это то, что важно.

Приложение Twelve Factor обращается к этому, хотя и прямо вперед. «Испытание Litmus для того, будет ли приложение всем правильно обоснованным конфигурациями из кода, является ли кодовая база с открытым исходным кодом в любой момент, без ущерба для любых учетных данных». Таким образом, мы знаем, что мы должны записать его где-то , и что мы не можем поставить конфиг в кодовую базу. «Другой подход к конфигурации - это использование файлов конфигурации, которые не проверяются в управлении пересмотром». Это то, что я бы сделал.

Приложение Twelve Factor говорит: «Легко ошибочно проверить в файле конфигурации в REPO». Чтобы противостоять этому, конфигурацию производства (например, закрытые ключи) должно отличаться от разработки и тестирования конфигурации. Они также должны быть строго контролируются. Некоторые системы контроля версий, такие как Git , имеют черные списки (например, файл .gitignore ), который предотвращает проверку в определенных файлах. Они также должны быть использованы. «Существует тенденция для разбросанных файлов конфигурации в разных местах и ​​различных форматах, что делает его трудно увидеть и управлять всей конфигурацией в одном месте. Далее эти форматы имеют тенденцию быть языковыми или рамками. Это противодействует, просто определяя «переменные среды» в файле конфигурации. Это может быть загружено в окружающую среду при запуске сервером.

Что я бы сделал:

  1. Хранить информацию о конфигурации сервера производства (например, закрытый ключ сервера) в отдельном репо, который отличается и отличается от основного репо
  2. Защитить файл конфигурации производства (S ) очень хорошо. Только несколько человек должны получить доступ к ней, а не каждый разработчик в команде. QA / DEVOPS / SYS-ADMINS / ETC Например. Обратите внимание на этот файл, как клавиши на сервер, потому что они, вероятно, в нем. Разработка и тестовые среды должны иметь разные учетные данные и ключи, чем производство. Затем они могут быть сохранены более слабо
  3. , имеют текущую инструкцию INITINE SERVER нагрузку на информацию о файле конфигурации в переменные среды в прямом эфире
  4. , приложение загружают информацию об использовании конфигурации, в результате переменных среды во время выполнения
--121 -93181-

Хорошо, поэтому для первого вопроса получается статистика SEBUGFS команда , что позволяет тому, что являются запускными блоками для каждого участка группы. Кроме того, я догадался, что не пришлось бы быть последовательным и увеличением, поэтому базовое добавление смещения в таблицу INODE и команду дала мне первые неисправности; Это также подтвердило мое подозрение в последнем плохом секторе, где мои расчеты группы блоков указали, что он был в неправильной группе. 

byte address  block      group  what                   first inumber
0x8B00020000  145752096  4448   inode table block 0    36438017
0x8B00027000  145752103  4448   inode table block 7    36438129
0x8B0002C000  145752108  4448   inode table block 12   36438209
0x8B00209000  145752585  4448   inode table block 489  36445841
0x8B0029A000  145752730  4449   inode table block 122  36448161

Поскольку блок составляет 4096 байт, и каждая запись таблицы INODE составляет 256 байтов, есть 16 inodes на блок. Таким образом, у меня теперь все 80 потерянных индексных записей индийского стола.

Теперь давайте обратимся к журналу. Я писал небольшой инструмент , который сбрасывает информацию в каждом блоке журнала. Поскольку журнал SuperBlock отсутствовал, были два предмета информации, которые мне нужны для этого, которые были потеряны:

  • , будь то журнал проводил 64-битные номера блоков
  • , будь то журнал использовал контрольные суммы версии 3

, если Я заставлял один (или оба) из этих коммутаторов, некоторые из блоков дескриптора в журнале переполнены его блок, доказывая, что эти флаги не были установлены.

Один скрипт awk ( fulllog.awk ) позже у меня есть журнал форма 

0x0002A000 - descriptors
        0x0002B000 -> block 159383670
        0x0002C000 -> block 159383671
        0x0002D000 -> block 0
        0x0002E000 -> block 155189280
        0x0002F000 -> block 195559440
        0x00030000 -> block 47
        0x00031000 -> block 195559643
        0x00032000 -> block 195568036
        0x00033000 -> block 159383672
0x0002B000 - invalid/data block
0x0002C000 - invalid/data block
0x0002D000 - invalid/data block
0x0002E000 - invalid/data block
0x0002F000 - invalid/data block
0x00030000 - invalid/data block
0x00031000 - invalid/data block
0x00032000 - invalid/data block
0x00033000 - invalid/data block
0x00034000 - commit record
        commit time: 2014-12-25 16:53:13.703902604 -0500 EST

с этим, еще один скрипт awk ( dumpallfor.awk ) сбрасывает все блоки : 

byte address  block      number of journaled blocks
0x8B00020000  145752096  6
0x8B00027000  145752103  10
0x8B0002C000  145752108  206
0x8B00209000  145752585  1
0x8B0029A000  145752730  0

Так что последний блок действительно потерян :( С любой удачей я могу узнать, какие файлы были там с DEBUBFS команду NCHECK .

Так что у меня есть Букет из блоков. И все они кажутся отличаются! Теперь что?

I может пройти через записи отзыва, но я не могу определить эту структуру. I Может ли пройти отметки записи Commit Record, но до того, как я попробую это, я хочу видеть, как каждый блок таблицы INODE отличается. Итак, я писал еще одну быструю программу ( diff.go ), чтобы найти это.

По большей части файлы, которые отличаются отличаются только в временных метках, поэтому мы можем просто выбрать файл с последними временными метками. Мы сделаем это позже. Для всех остальных файлов мы получаем это: 

36438023 - size differs
36438139 - OSD1 (file version high dword) differs
36438209 - OSD1 differs

HM, это не хорошо ... Файл с различным размером будет проблемой, и я понятия не имею, что делать с двумя файлами OSD1. Я также попробовал использовать Debugfs NCHECK , чтобы увидеть, какие файлы были, но у нас нет совпадения.

Затем я выяснил, какие блок свалки имеют последние метки времени (то же репо, Neight.go ). Важно отметить, что у меня были блоки, отсканированные в хронологическом порядке. Это не обязательно так же, как численный порядок по номеру блока; Журнал не всегда хранятся в хронологическом растущем порядке.

Как получается, однако, новейший блок (по времени Comply) действительно является тем, что с последними временными метками!

Давайте попробуем эти последние блоки и посмотрим, сможем ли мы восстановить что-нибудь из них. 

sudo dd if=BLOCKFILE of=DDRESCUEIMG bs=1 seek=BYTEOFFSET conv=notrunc

После этого мой домашний каталог вернулся!

Теперь давайте узнаем, что эти три разные файлы были ... 

Inode   Pathname
36438023    /pietro/.cache/gdm/session.log
36438209    /pietro/.config/liferea
36438139    /pietro/.local/share/zeitgeist/fts.index

Единственная важная вещь, что есть каталог конфигурации Liferea, но я не думаю, что это было повреждено; Это один из различных OSD1.

И давайте узнаем об этих 16 inodes в конечном блоке, то тот, который мы не смогли восстановить: 

Inode   Pathname
36448176    /pietro/k2
36448175    /pietro/Downloads/sOMe4P7.jpg
36448174    /pietro/Downloads/picture.png
36448164    /pietro/Downloads/tumblr_nfjvg292T21s4pk45o1_1280.png
36448169    /pietro/Downloads/METROID Super Zeromission v.2.3+HARD_v2.4.zip
36448165    /pietro/Downloads/tumblr_mrfex1kuxa1sbx6kgo1_500.jpg
36448173    /pietro/Downloads/1*-vuzP4JAoPf9S6ZdHNR_Jg.jpeg
36448162    /pietro/.cache/upstart/gnome-settings-daemon.log.6.gz
36448163    /pietro/.cache/upstart/dbus.log.7.gz
36448171    /pietro/.cache/upstart/gnome-settings-daemon.log.3.gz
36448161    /pietro/.local/share/applications/Knytt Underground.desktop
36448166    /pietro/Documents/Screenshots/Screenshot from 2014-12-03 15:47:29.png
36448170    /pietro/Documents/Screenshots/Screenshot from 2014-12-03 16:51:26.png
36448172    /pietro/Documents/Screenshots/Screenshot from 2014-12-03 19:08:54.png
36448168    /pietro/Documents/transactions/premiere to operating transaction 4305747926.pdf
36448167    /pietro/Documents/transactions/transaction 4315883542.pdf

в короткие сроки:

  • текстовый файл с одним или двумя вещами, в котором я мог бы вернуться к Brute Сила, поскольку я знаю, что у него есть штамп дата и что-то, что также в моих журналах чата
  • Некоторые изображения, загруженные из Интернета; Если я не могу вернуть URL-адреса из истории Firefox, я могу использовать Photorec
  • взломать ROM, который я могу легко получить в Интернете = p
  • файлы журнала; Нет потери здесь
  • . Дейсктопский файл для паровой игры
  • скриншоты; Я могу получить их обратно с Photorec, предполагая, что Gnome-скриншот добавил datestamp в качестве метаданных
  • Записи транзакций банковских счетов; Если я не могу получить их из банка, я, вероятно, мог бы использовать их с Photorec

, поэтому не пострадавшим, но не общая потеря, и я узнал больше о EXT4 в процессе. Спасибо, в любом случае!

Обновление

может также поставить это там: 

NOT YET     /pietro/k2
FOUND       /pietro/Downloads/sOMe4P7.jpg
NOT YET     /pietro/Downloads/picture.png
FOUND       /pietro/Downloads/tumblr_nfjvg292T21s4pk45o1_1280.png
GOOGLEIT    /pietro/Downloads/METROID Super Zeromission v.2.3+HARD_v2.4.zip
FOUND       /pietro/Downloads/tumblr_mrfex1kuxa1sbx6kgo1_500.jpg
FOUND       /pietro/Downloads/1*-vuzP4JAoPf9S6ZdHNR_Jg.jpeg
UNNEEDED    /pietro/.cache/upstart/gnome-settings-daemon.log.6.gz
UNNEEDED    /pietro/.cache/upstart/dbus.log.7.gz
UNNEEDED    /pietro/.cache/upstart/gnome-settings-daemon.log.3.gz
UNNEEDED    /pietro/.local/share/applications/Knytt Underground.desktop
NOT YET     /pietro/Documents/Screenshots/Screenshot from 2014-12-03 15:47:29.png
NOT YET     /pietro/Documents/Screenshots/Screenshot from 2014-12-03 16:51:26.png
NOT YET     /pietro/Documents/Screenshots/Screenshot from 2014-12-03 19:08:54.png
NOT YET     /pietro/Documents/transactions/premiere to operating transaction 4305747926.pdf
NOT YET     /pietro/Documents/transactions/transaction 4315883542.pdf

и в случае, если я недостаточно странный, загруженные изображения были:

Это все были разделены друзьями в чатах.

Я думаю, я буду держать это обновлено? (Не так, как это будет иметь значение ...) Я знаю, что могу все восстановить; Единственный вопрос, когда = P

5
27.01.2020, 20:28

Теги

Похожие вопросы