После катастрофического отказа e2fsck перестал работать с удачливыми высокими числами/размерами блока
Вероятно, потому что его родительский процесс завершается, и сигнал завершения распространяет его детям, которые не блокируют его (и в случае SIGKILL они даже не могут).
У меня был быстрый взгляд через e2fsck источник, и это кажется мне существуют места, где "Выделение памяти, отказавшее" ошибка, может произойти по причинам, которые не могли бы действительно быть ошибками распределения памяти.
Строка ошибки определяется в [src]/lib/ext2fs/ext2_err.et.in относительно константы EXT2_ET_NO_MEMORY. Это может быть возвращено из различных мест в коде в [src]/e2fsck/. Вот пример от ea_refcount.c:
errcode_t ea_refcount_increment(ext2_refcount_t refcount, blk_t blk, int *ret)
{
struct ea_refcount_el *el;
el = get_refcount_el(refcount, blk, 1);
if (!el)
return EXT2_ET_NO_MEMORY;
get_refcount_el() находится в том же файле:
static struct ea_refcount_el *get_refcount_el(ext2_refcount_t refcount,
blk_t blk, int create)
{
int low, high, mid;
if (!refcount || !refcount->list)
return 0;
Это не единственная причина, она возвратит пустой указатель, ни единственная причина, которая похожа на нее, непосредственно не связана с неудавшимся выделением.
Действительно доказать, что я должен был бы сделать больше рытья, но оно действительно соответствует Вашему утверждению, что оно действительно не исчерпало системную память.
При этом возможно, проблема связана с неясным и непредсказуемым потенциалом, нарушил/повредил контроллеры SD-карты, но она все еще составляет ошибку в e2fsck, поскольку своего рода проверка исправности или что-то должны быть сделаны для ловли этого, даже если она должна только сказать, "Извините, устройство завинчено" (вероятно, верный) по сравнению с "Из памяти" (вероятно, не верный). Можно хотеть сообщить об этом ("В случае ошибок в этих программах, свяжитесь с Ted Ts'o по tytso@mit.edu или tytso@alum.mit.edu" - я полагаю, что T.T. является ядром Linux dev), и можно сослаться на это Вопросы и ответы.
Кроме того, IMO, Вы могли бы также забыть то, что находится на той карте и делает разрушительный тест чтения-записи на ней:
badblocks -v -w -b 1048576 -c 16 /dev/sdx
Помните, это - РАЗРУШАЮЩИЙ КОНТРОЛЬ - Вы будете освобождать все свои данные. Badblocks не полезен для создания фактического списка badblocks для SD-карты (они не сообщают о фактических физических адресах из-за износа, выравнивающегося), но если карта будет borked, то он, вероятно, сообщит. При тестировании карты на 16 ГБ этот путь занимает меньше чем час.
При выполнении e2fsck - финансовый год, действительно необходимо сохранить целую e2fsck расшифровку стенограммы и не только показать последние сообщения об ошибках. Может случиться так, что файловая система была очень плохо повреждена, и-y опция означает продолжать идти несмотря ни на что.
Похоже, что дескрипторы группы блока были плохо повреждены, так, чтобы местоположения inode таблицы были безумны. E2fsck, вероятно, пытался восстановить его, но по некоторым причинам это не смогло зафиксировать его, и "-y" означает, что это продолжит идти несмотря на это. Таким образом, когда люди отправляют отчеты об ошибках, я всегда предлагаю, чтобы они отправили полную e2fsck расшифровку стенограммы и не только последние ошибки.
-
1В первую очередь, спасибо за то, что привлекли к этому вопросу Ваше внимание! Относительно расшифровки стенограммы - конечно, полный отчет об ошибках будет включать полную версию, я только использовал отрывок здесь для выделения проблемы удачливых больших номеров блока. – mikołak 20.11.2013, 08:31
top). Странная вещь единственной вещи относительно использования ресурсов состоит в том, что оно не израсходовало пространство для рабочего файла. Я отредактировал вопрос разъяснить это. – mikołak 11.11.2013, 21:21Pass completed, 0 bad blocks found. (0/0/0 errors). Похож на Вашу интерпретацию ошибки, может быть корректным (который является позором в контексте восстановления FS). Я оставлю вопрос открытым в течение следующих нескольких дней на всякий случай. – mikołak 12.11.2013, 00:54