>>> Покривляетесь ещё или хоть немножко стыдно стало?
>> Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов
> Каких-каких аргументов?! В сообщении, на которое я отвечал, их просто нет. То есть Вам за счет человека надо было посамоутверждаться, а не "правду искать", как оно может быть на самом-то деле с аргументами. Бывает, понимаю. Правда, со словами о поиске истины расходится, увы...
> А за _полный_ анализ вопроса применимости dump/restore во FreeBSD и Linux (если
> Вы его имели в виду) могу при необходимости выставить Вам счёт
> -- поскольку придётся привлекать наших ядерщиков и системщиков как минимум.
...И всё равно не даст ответа, потому что такая постановка вопроса рассматривает лишь конкретную имплементацию, а вовсе не идею, и вопрос вовлеченного кругозора для полного научного исследования тоже неясен - Вы, как оказалось, про zfs send/receive не знаете, например.
>> будете еще что-то заявлять о гордыне?
> Вадим, мне бы за то, что спорол некто откомментированный, действительно было стыдно.
> Чтоб Вам было понятно -- _естественно_, я _не_ свободен от
> гордыни. За себя стыдно в части резкости, но предпочитаю сказать
> в лоб, что человек дурь сказал, чем поморгать глазками, поулыбаться и
> показать кукиш в кармане.
Кхе-кхе. Ну да про ad hominem я уже выше сказал, не буду повторяться.
>> Эти самые "средства другого уровня" весьма долго не умели полностью сохранять
>> структуру FS
> 1) или у Вас оригинальное определение структуры ФС, или это не так;
В сопоставлении с теми очень ранними tar и др. - вполне себе некоторое знание о структуре было, хардлинках и прочем. Надо ж не забывать, в какие он годы появился-то.
> 2) зачем? (если мне нужен образ блокдевайса с отмонтированной или ro-ФС, его
> сделает dd; образ блокдевайса с rw ФС мне до сих пор
> нужен не бывал IIRC)
Ранее всегда это делалось чаще всего для того, чтобы вместо dd переливать только ту часть FS, которая действительно занята данными. Полный dd не только долог, но и не позволяет воссоздать FS на диске другого размера. Кроме того, формат записи дампа таков, что в начале идут все каталоги. Соответственно, restore имеет функциональность чтения сначала заголовка и позволяет выбрать только часть файлов для восстановления. Я этим неоднократно пользовался. Очень удобно, когда многогигабайтный образ сжат - с tar пришлось бы для чтения оглавления читать _весь_ архив. А уж на магнитной ленте - так и подавно.
>> (скажем, тех же файлов с дырками)
> Я уже забыл, когда --sparse сделали в rsync (хотя багфиксы corner case'ов
> были и не так давно, e.g. в 3.0.8); в GNU tar
> поддержка sparse files была, когда я с ним столкнулся.
Ну, вот видите, даже для такой элементарной штуки corner case'ы были еще вон сколько. А уж специфические вещи типа флагов файлов кроме dump вообще долгое время никто сохранять не умел. Неудивительно, что он эволюционировал в средство для бэкапов, при наиболее полной поддержке фич конкретной fs. В наше время, конечно, альтернативные средства уже доросли, но это ж не отменяет громадную историческую практику, и не означает, что надо сразу же выкинуть.
>> а заявлять о костылях
> Давайте уточним: я сказал, что согласен с тем, что dump и restore,
> которые ходят к блокдевайсу мимо драйвера ФС -- костыли (и против
> unix way, btw).
Э, не, так не получится. Во-первых, здесь два варианта смешаны в кучу: идея знания о некотором устройстве конкретной fs и её реализация прямым чтением с диска - могли быть недокументированные хуки в драйвере.
Во-вторых, надо не забывать, в какое время утилиты родились, и что были они как раз юниксвейны - общие утилиты типа tar умели только какое-то общее подмножество возможностей, а fs на разных системах были разные - логично, что для неё была создана отдельная утилита, чтобы не пихать всё в одну.
В-третьих, все остальные программы комплекта - fsck, newfs, fsdb - уже работали с диском напрямую, в силу своей природы. Логично было использовать общий код из них и не встраивать хуки в драйвер (а в ядерном коде цена усложнения больше) для еще всего лишь одной программы.
>> при необходимости тех же инкрементальных обвязок
> Если это было о надстройках над тем же rsync -- то лукавите:
> это как раз unix way.
Про это я уже выше писал. Использование маленькой специализированной утилиты для конкретной задачи - вполне подходит. Никто не обязывал набор утилит быть строго ортогональным (одни и те же задачи можно бывает решать разными). Про полную поддержку возможностей только в одной конкретной утилите - тоже.
> Если нет -- то задача распределённого бэкапа (которая востребована) обычно решается с
> применением реализации инкрементального или инкрементально-дифференциального бэкапа
> для обеспечения разумного баланса периода, оперативности и стоимости резервных копий.
> И не решается разумно в пределах локальной ФС. Это
> так удивляет?
Общие слова какие-то. Что конкретно сказать-то хотели?
>> и умалчивании об уже давно реализованном доступе к снапшотам вместо живой FS -
>> по меньшей мере, демагогично.
> Позвольте поинтересоваться, используете ли Вы эту реализацию в своей практике в сколь-нибудь
> существенной мере или же именно что демагогию разводите? У меня
> давным-давно были под рукой снапшоты в XFS и LVM, но я
> ими попросту не пользовался (в отличие от иных коллег) -- не
> требовалось. И соответственно не носился с ними, как дурак с
> торбой.
Использовал несколько лет. На UFS, конечно, для ограниченных целей, ибо их возможности там ограничены, в основном для дампов как раз. А на ZFS ныне их используют все подряд, ибо это попросту удобно.
> RAID, снапшоты, бэкап, rsync, bacula, диски, ленты, охрана периметра -- друг друга
> не заменяют, а дополняют. У них разные плюсы, минусы и
> зоны применимости. Местами перекрывающиеся.
Спасибо, кэп.
>> Как и игнорирование того факта, что развитием идеи dump/restore в
>> "правильном ключе" является zfs send/receive
> С этим незнаком, потому обсуждать не могу.
На чем сей спор можно и завершить, в таком случае.
>> а не отказ от подобного способа решения целиком в пользу
>> изначально предназначенных для слегка других целей утилит.
> По смыслу их предназначение такое же -- копирование информации; по реализации --
> да, другое, только IMHO не "слегка", а существенно. Вы о
> чём?
> Dump was a stupid program in the first place. Leave it behind.
> -- Linus Torvalds (http://lwn.net/2001/0503/a/lt-dump.php3)
Ну да, абстрагируемся до небес с полной потерей смысла, и приправим мнением Торвальдса от мохнатого года, будто бы оно истина в последней инстанции (а вот ребята из Sun c ним не согласились и сделали элегантный zfs send/receive, и чо?). Демагогично, при подобной глухоте к альтернативным вариантам желания продолжать не имею.
