восстановите частично перезаписанную ленту с tar-c

Я, кажется, не забываю иметь подобную проблему при установке Ганглий много лун назад. Это не может быть той же проблемой, но для меня случалось так, что моему полю/сети не нравилась многоадресная передача Ганглий. После того как я настроил его для использования одноадресной передачи, все было хорошо.

Из документов Ганглий:

Если только хост и порт будут указаны затем gmond, то отправит, одноадресно передает сообщения UDP к указанным хостам.

Возможно, попытайтесь заменить mcast_join = 127.0.0.1 с host = 127.0.0.1.

2
30.09.2013, 17:08
2 ответа

Этим вопросом является полностью устройство, конкретное, в зависимости от аппаратных средств диска и его связанного драйвера.

При порче операций ленты (как прерывание записи) можно легко сделать нечитаемый символ или даже нечитаемый фрагмент на ленте. Вы уже показали, что Ваш драйвер не способен к чтению мимо спама Ваша прерванная запись, оставленная с тех пор mt fsf просто выпускает ioctl, который просит, чтобы драйвер просто пропустил к следующей метке EOF. Так как драйвер возвращает EIO, Вы, вероятно, не собираетесь мочь заставить его делать немного лучше.

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

3
27.01.2020, 22:06
  • 1
    Если я перехожу к файлу 23 и создаю маленький tar только для вставки EOF, это могло позволить диску смочь пропустить прошлые 23? В это время, я собирающийся тестировать другое устройство для чтения ленты. Как только я могу, я отправить спецификации первого устройства ради полноты, так как это - конкретное устройство. Таким образом, dd является правильным инструментом для задания, просто не для моего устройства, правильно? –  StackUnder 01.10.2013, 04:30
  • 2
    Nopey. dd не может сделать ничего, что не предоставляет драйвер устройства, и я никогда не видел водителей грузовиков, которые делают то, что Вы надеетесь (запись EOF в определенном местоположении несмотря на предыдущий спам). Поэтому люди, у которых было слишком много опыта с магнитной лентой, так рады, что мы не видим большую часть его больше. С перфолентой (который я никогда не использовал) Вы могли, по крайней мере, видеть дефекты и зафиксировать их с ножом и связующим звеном, если бы только магнитная лента была столь же прощающей. –  msw 01.10.2013, 04:41

Попробуйте выполнить чтение, начиная с другого конца ленты:

#! /bin/sh
set -e
TAPE=/dev/... # change me, you must use a non-rewinding device.
export TAPE

# Wind to the end of the tape.
mt eod

# Rewind to the beginning of the last file and then list it.
# It's possible I misunderstood the way end-of-data is signaled
# on the tape and if so perhaps this command should be mt bsfm 2,
# in which case you can just combine this with the loop below.
# For context here you can look at the entry for MT_ST_TWO_FM
# in "man st".
mt bsfm 1
tar -f "$TAPE" -t

# We just read a file so we're  going to need to rewind over it
# and then rewind more to get to the beginning of the previous file.
# I forget whether tar leaves the tape at EOF or just after it. I'm
# assuming here just after, but if it leaves the tape at the EOF
# mark, the 2 on the next line would need to be a 1.
while mt bsfm 2 
do
  tar -f "$TAPE" -t
done

Это будет список содержимого всех архивов tar, к которым мы можем получить доступ с конца ленты. Конечно, в начале ленты есть и архивы, но их гораздо проще перечислить :

.
while tar -f "$TAPE" -t
do
  true
done

Операция mt eodтребует от драйвера перемотать ленту до конца, пропустив метки файла. Это должно работать нормально, если все, что вы сделали для прерывания записи на ленту, это уничтожили процесс tar с помощью SIGINT (Ctrl -C ). С точки зрения ленточного драйвера SCSI это выглядит так, как будто пользовательская космическая программа -закрыла файловый дескриптор, поэтому в этом месте должна быть метка EOF, но никакого фактического «повреждения».

Однако, если здесь происходит что-то еще и/или описанный выше подход не работает, вы можете получить другой результат, попросив драйвер магнитной ленты добавить пробел до конца -из -. носителя, отправив SCSI-команду на ленточный накопитель с просьбой сделать это. Это не то же самое, что поведение по умолчанию (, которое заключается в том, что ленточный накопитель с помощью прямого интервала между файлами может отслеживать текущий номер файла (для отчета в таких операциях, как mt statusиmt tell). Чтобы настроить это, вы должны использовать MT_ST_FAST_EOMioctl. Я не знаю, как установить это из командной строки, вам может понадобиться создать небольшую программу на C, что-то вроде этой:

#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/mtio.h>

int main(int argc, char *argv[]) {
  (void)argc;
  (void)argv;
  struct mtop mt_cmd;
  mt_cmd.mt_op = MTSETDRVBUFFER;
  mt_cmd.mt_count = MT_ST_BOOLEANS | MT_ST_FAST_MTEOM;
  if (0 != ioctl(1, MTIOCTOP, &mt_cmd)) {
    perror("MTSETDRVBUFFER on stdout");
    return 1;
  }
  return 0;
}

Чтобы сэкономить на котловой -пластине, я предположил, что лентопротяжное устройство уже открыто в стандартном выводе для этой программы (, т.е. вы запускаете ее вот так:./myprog >"$TAPE").

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

0
01.07.2021, 12:03

Теги

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