The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..., opennews (??), 08-Авг-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


31. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +2 +/
Сообщение от Аноним (-), 08-Авг-11, 11:37 
да только у бсд dump/restore из коробки работает, и является нативным решением...а в линуксе еще и покривляться надо
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

61. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от QuAzI (ok), 08-Авг-11, 12:34 
pax же, не?
Ответить | Правка | Наверх | Cообщить модератору

287. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Michael Shigorinemail (ok), 08-Авг-11, 23:41 
> да только у бсд dump/restore из коробки работает, и является нативным решением...
> а в линуксе еще и покривляться надо

"В линуксе" эти сроду кривые костыли давно (ЕМНИП в 2.2.x) объявили неподдерживаемыми.  А кому и при каких обстоятельствах вообще пришло в голову брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей mountpoint -- даже узнавать неохота.

Покривляетесь ещё или хоть немножко стыдно стало?

PS: rsync (и стопка инкрементальных обвязок вокруг) и bacula решают в принципе ту же задачу, но на совсем другом уровне.  Что характерно.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

298. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от myc (?), 09-Авг-11, 00:07 
> "В линуксе" эти сроду кривые костыли давно (ЕМНИП в 2.2.x) объявили неподдерживаемыми.  А кому и при каких обстоятельствах вообще пришло в голову брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей mountpoint -- даже узнавать неохота.

ИМХО, брать данные со снапшота - вполне валидная операция.

Ответить | Правка | Наверх | Cообщить модератору

364. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от nuclightemail (ok), 09-Авг-11, 03:19 
>> да только у бсд dump/restore из коробки работает, и является нативным решением...
>> а в линуксе еще и покривляться надо
> "В линуксе" эти сроду кривые костыли давно (ЕМНИП в 2.2.x) объявили неподдерживаемыми.
>  А кому и при каких обстоятельствах вообще пришло в голову
> брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей
> mountpoint -- даже узнавать неохота.
> Покривляетесь ещё или хоть немножко стыдно стало?
> PS: rsync (и стопка инкрементальных обвязок вокруг) и bacula решают в принципе
> ту же задачу, но на совсем другом уровне.  Что характерно.

Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов будете еще что-то заявлять о гордыне? Ну смешно же, право слово. Эти самые "средства другого уровня" весьма долго не умели полностью сохранять структуру FS (скажем, тех же файлов с дырками), а заявлять о костылях при необходимости тех же инкрементальных обвязок и умалчивании об уже давно реализованном доступе к снапшотам вместо живой FS - по меньшей мере, демагогично. Как и игнорирование того факта, что развитием идеи dump/restore в "правильном ключе" является zfs send/receive, а не отказ от подобного способа решения целиком в пользу изначально предназначенных для слегка других целей утилит.

Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

719. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Michael Shigorinemail (ok), 10-Авг-11, 19:25 
>> Покривляетесь ещё или хоть немножко стыдно стало?
> Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов

Каких-каких аргументов?!  В сообщении, на которое я отвечал, их просто нет.

А за _полный_ анализ вопроса применимости dump/restore во FreeBSD и Linux (если Вы его имели в виду) могу при необходимости выставить Вам счёт -- поскольку придётся привлекать наших ядерщиков и системщиков как минимум.

> будете еще что-то заявлять о гордыне?

Вадим, мне бы за то, что спорол некто откомментированный, действительно было стыдно.  Чтоб Вам было понятно -- _естественно_, я _не_ свободен от гордыни.  За себя стыдно в части резкости, но предпочитаю сказать в лоб, что человек дурь сказал, чем поморгать глазками, поулыбаться и показать кукиш в кармане.

> Эти самые "средства другого уровня" весьма долго не умели полностью сохранять
> структуру FS

1) или у Вас оригинальное определение структуры ФС, или это не так;
2) зачем? (если мне нужен образ блокдевайса с отмонтированной или ro-ФС, его сделает dd; образ блокдевайса с rw ФС мне до сих пор нужен не бывал IIRC)

> (скажем, тех же файлов с дырками)

Я уже забыл, когда --sparse сделали в rsync (хотя багфиксы corner case'ов были и не так давно, e.g. в 3.0.8); в GNU tar поддержка sparse files была, когда я с ним столкнулся.

> а заявлять о костылях

Давайте уточним: я сказал, что согласен с тем, что dump и restore, которые ходят к блокдевайсу мимо драйвера ФС -- костыли (и против unix way, btw).

> при необходимости тех же инкрементальных обвязок

Если это было о надстройках над тем же rsync -- то лукавите: это как раз unix way.

Если нет -- то задача распределённого бэкапа (которая востребована) обычно решается с применением реализации инкрементального или инкрементально-дифференциального бэкапа для обеспечения разумного баланса периода, оперативности и стоимости резервных копий.  И не решается разумно в пределах локальной ФС.  Это так удивляет?

> и умалчивании об уже давно реализованном доступе к снапшотам вместо живой FS -
> по меньшей мере, демагогично.

Позвольте поинтересоваться, используете ли Вы эту реализацию в своей практике в сколь-нибудь существенной мере или же именно что демагогию разводите?  У меня давным-давно были под рукой снапшоты в XFS и LVM, но я ими попросту не пользовался (в отличие от иных коллег) -- не требовалось.  И соответственно не носился с ними, как дурак с торбой.

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)

Ответить | Правка | Наверх | Cообщить модератору

853. "dump/restore"  +/
Сообщение от nuclightemail (ok), 12-Авг-11, 02:15 
>>> Покривляетесь ещё или хоть немножко стыдно стало?
>> Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов
> Каких-каких аргументов?!  В сообщении, на которое я отвечал, их просто нет.

То есть Вам за счет человека надо было посамоутверждаться, а не "правду искать", как оно может быть на самом-то деле с аргументами. Бывает, понимаю. Правда, со словами о поиске истины расходится, увы...

> А за _полный_ анализ вопроса применимости 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, и чо?). Демагогично, при подобной глухоте к альтернативным вариантам желания продолжать не имею.

Ответить | Правка | Наверх | Cообщить модератору

912. "dump/restore"  +/
Сообщение от Аноним (-), 12-Авг-11, 20:15 
> элегантный zfs send/receive, и чо?).

А почему это должно быть прибито гвоздями к одной файловой системе? Возможность реализации каких-то еще файловых систем в будущем вы не рассматриваете даже теоретически?

Ответить | Правка | Наверх | Cообщить модератору

950. "dump/restore"  +/
Сообщение от nuclightemail (ok), 15-Авг-11, 00:42 
>> элегантный zfs send/receive, и чо?).
> А почему это должно быть прибито гвоздями к одной файловой системе? Возможность
> реализации каких-то еще файловых систем в будущем вы не рассматриваете даже
> теоретически?

А кто-то у Вас такую возможность забирает разве? Реализуйте, я не против.

Ответить | Правка | Наверх | Cообщить модератору

415. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 09-Авг-11, 09:23 
>  А кому и при каких обстоятельствах вообще пришло в голову
> брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей
> mountpoint -- даже узнавать неохота.

во freebsd: man dump на предмет ключика -L.

Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру