Linux: dump не кошерен
А как во FreeBSD достигается правильная работа dump?
Например:
1. dump прочитал inode и собрался читать соответствующий файл
2. в это время, был создан новый файл, и с помощью rename заменил собой старый
3. блоки, которые занимал файл, освободились, и туда записались данные других файлов
4. dump полез читать файл, но эти блоки уже содержат данные других файлов
Результат - в бекапе мусор.
> но для меня новость
точнее сказать - у тебя плохая память,
так как ты уже как-то удивлялся этому при мне
Например:
1. dump прочитал inode и собрался читать соответствующий файл
2. в это время, был создан новый файл, и с помощью rename заменил собой старый
3. блоки, которые занимал файл, освободились, и туда записались данные других файлов
4. dump полез читать файл, но эти блоки уже содержат данные других файлов
Результат - в бекапе мусор.
> но для меня новость
точнее сказать - у тебя плохая память,
так как ты уже как-то удивлялся этому при мне
А как во FreeBSD достигается правильная работа dump?Не знаю как делалось до появления снапшотов
. Сейчас соответственно со снапшота.> но для меня новостьВозможно ты мне это сказал, когда я смотрел в монитор. Тогда я удивился этому в отдельном треде, который был после этого убит, не оставив никаких записей в постоянной области памяти.
точнее сказать - у тебя плохая память,
так как ты уже как-то удивлялся этому при мне
> Не знаю как делалось до появления снапшотов.
Скорее всего, как и в Linux 2.0, забивали на такую возможность.
В современном Linux просто окно, в течении которого такая фигня возможна,
намного шире.
> Сейчас соответственно со снапшота.
Снапшот на уровне block device? Тогда ведь там сначала нужно fsck прогонять,
как после сбоя питания?
Специальное API для бекапа, конечно же, было бы лучше.
В Windows, я слышал, есть
Скорее всего, как и в Linux 2.0, забивали на такую возможность.
В современном Linux просто окно, в течении которого такая фигня возможна,
намного шире.
> Сейчас соответственно со снапшота.
Снапшот на уровне block device? Тогда ведь там сначала нужно fsck прогонять,
как после сбоя питания?
Специальное API для бекапа, конечно же, было бы лучше.
В Windows, я слышал, есть
Например:Я вот поговорил с fs guru. Он говорит, что файловая активность может только привести к тому, что запишется более старая версия файла или файл в состоянии редактирования (так же фигня в случае tar решения). Информация из других файлов попасть не может, и испортиться весь dumpfile тоже не может.
1. dump прочитал inode и собрался читать соответствующий файл
2. в это время, был создан новый файл, и с помощью rename заменил собой старый
3. блоки, которые занимал файл, освободились, и туда записались данные других файлов
4. dump полез читать файл, но эти блоки уже содержат данные других файлов
Результат - в бекапе мусор.
Вот и интересно, как это сделано?
Говорят, надо смотреть в сорец. Впрочем, как всегда.
Оставить комментарий
sergey_m
Конечно это старье, но для меня новость и я немного шокирован:http://groups.google.com/groups?selm=linux.kernel.Pine.LNX.4.21.0104270953280.2067-100000%40penguin.transmeta.com