LINUX.ORG.RU
Форум — Admin  

Убил бэкап? gzip может не удалить исходный файл по окончании работы?


0

1

1) gzip -7 source; shutdown -h now

2) Вытаскиваем live-флешку с убунтой, идём домой.

3) Есть два файла: source и source.gz. Полон ли второй?

Если заменить первую строку на dd что-то там, то по окончании работы шелл не появится, скорее всего, - курсор будет висеть, запустить что-либо ещё не получится (даже таб в консоли). Полагаю что из-за сброса дискового кэша.

В оригинальном случае сжатие должно было бы занять около полутора часов. Запись по прикидкам могла бы завершиться за час, в худшем случае - три часа (опять же, прикидки, и те на скорость записи в 3МБ/с на ntfs). Всего прошло 4 часа, т.е. всё должно было завершиться.

Почему файлов два? Есть вероятность того, что файл не цел (по объёму примерно подходит под полный архив).

☆

Ответ на: комментарий от anonymous

Исходный файл удалён. Доступа к архиву нет.

daris ☆
() автор топика
Ответ на: комментарий от daris

как всё сумбурно, сплошной винегрет из мыслей...
Это что?:
3) Есть два файла: source и source.gz. Полон ли второй?
Так есть или нет?
Если нет, то нах эти теоретические рассуждения о том, что было в файле, если проверить это невозможно да и не нужно?
Я так понимаю там что-то важное было, что вы так переволновались.
Вы водки или валерианки (на выбор) бахните, соберитесь с мыслями и переформулируйте вопрос нормально

zolden ★★★★★
()
Ответ на: комментарий от zolden

Ок.

Есть файл source размером 70ГБ, находящийся на сильно фрагментированном ntfs-разделе (скорость записи dd if=/dev/sda1 of=source равна 8 метров/с). Натравливаю на него «gzip -7 source».

Вынимаю носитель с корнем (/). Оставляю на 4 часа работать. Процесс должен завершиться за 3 часа максимум и вот почему: скорость сжатия на той тачке превышает минимальную скорость записи (выше указал что это 8 МБ/с), потому максимальное время работы gzip'а выходит меньше трёх часов (легко пересчитать).

По истечении 4-х часов даже в худшем варианте файл должен был быть сжат. Затем питание было выключено до того, как команда «gzip -7 source; shutdown -h now» вернула управление шеллу.

В итоге на диске стало два файла: source (70ГБ) и source.gz (35 ГБ; примерно такое же сжатие я получил на схожих тестах). После чего source было удалён.

Проблемы и вопросы:

1) gzip -7 <file> обычно (должен) после создания архива удалять исходник. Мы же имеем два файла.

2) gzip должен был успеть (по худшим прогнозам - проседании производительности от dd, простое чтение и запись в пределах одного раздела должны быть с большой вероятностью быстрее, да и что это за скорость - 8 мегов для 500 гигового винта?) отработать.

3) Отсюда вижу два варианта развития событий: а) gzip не успел отработать (но размер файла и время работы говорят против), б) из-за отсутствия корневой ФС gzip не смог вызвать системную функцию удаления файла или же обратиться к шеллу, так как тот отсутствовал в дисковом кэше.

4) Какова вероятность того, что архив не битый? Какова вероятность каждого варианта а и б из пункта 3?

daris ☆
() автор топика
Ответ на: комментарий от daris

Тут большой простор для догадок и теорий. Я склоняюсь к варианту, что пришельцы из Альфы Центавра сфокусированным реликтовым излучением предотвратили удаление оригинала по религиозным соображениям.

Максимум, что можно сейчас сделать - проверить целостность (integrity) архива.
Если же нет ни оригинала ни архива - забитьсмириться и жить дальше.

zolden ★★★★★
()
Ответ на: комментарий от daris

>из-за отсутствия корневой ФС

А, ну гланды удалять через жопу я тоже умею. На будущее - желаешь подобного, не поленись запихнуть /(в минимальной комплектации хотя бы /bin, /sbin, /lib) в RAM. Я подобным образом тоже себе яйца отстрелил, благо бэкапы - наше всё

Pinkbyte ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin