предыдущий вариант новости мне нравился больше

из предыдущего варианта складывалось впечатление что его послали со своим star подальше. star вроде хорошая вещь..

а что это за бодяга-то? какое оно касательство имеет например к гну тар?

а касательно gnu tar афтар жжот примерно так: "The nice side effect is that you may have a program that behaves 98% like gnu tar but is not based on the GPL."

а что такое star? его кто-нить юзает?

pkgsrc/archivers/star - и пользуйте на здоровье, если так хочется. зачем в базу то заносить.. imho Hubert Feyrer is right.

// wbr

> а что такое star? его кто-нить юзает?

его много кто юзает.

> а что это за бодяга-то?

вроде там хорошая поддержка всевозможных extattrs и инкрементального архивирования.. Опять же star 23 года вылизывался, а тот pax который сейчас в NetBSD гораздо меньше.

да, 98% совместимости по фичам (и багам?)) это круто. если бы передо мной стояла задача по использованию не гнутого софта, то наверное, наверное...

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

GNU tar работает отлично, cpio еще лучше (девайсы сохраняет как нефиг делать - вот утилита для бекапа!). И то и другое прекрасно работает с busybox'ом.

Жизнь хороша.

(BSD неймется - ну это их личные сложности. Их бы энтузиазм, да в мирных целях...)

> но те кто регулярно с ним бекап и прочие чудеса творят что говорят про стабильность? мне кажется ничего плохого (в сети особо криков не слышал, да и все знакомые молчат)

я лично пока дампом пользуюсь (не в продакшен целях:). Но мне не нравится то что иногда приходится делать инкрементальные дампы на активных файловых системах. А с поддержкой снэпшотов (fss) в НетБСД свои заморочки.. Инкрементальный тар должен быть стабильнее дампа на активной системе. Ну и -- формат стандартный, в отличие от дампа.

tar девайсы тоже прекрасно сохраняет

Конечно много кто. star умеет XFS ACL сохранять.

Интересно, я бы на месте SUN написал HOWTO move your opensource project from GPL to CDDL. :) Вопрос вот в чем -насколько правомерно это будет с юридической точки зрения?

> Инкрементальный тар должен быть стабильнее дампа на активной системе. Ну и -- формат стандартный, в отличие от дампа.

Что не так с форматом dump-a? Я дампы, сделанные ufsdump-ом на Solaris/SPARC и сделанные dump-ом на NetBSD/Alpha спокойно открываю restore на Linux/x86.

> Что не так с форматом dump-a? Я дампы, сделанные ufsdump-ом на Solaris/SPARC и сделанные dump-ом на NetBSD/Alpha спокойно открываю restore на Linux/x86.

не знал. я думал формат дампа внутреннее дело каждой ОС и файловой системы..

мне кажется более логичным, если в netbsd пропихнут bsdtar из freebsd. действительно, хороная штука. =))

Данный чел ( ака афтор сдрекорд ) известный смутьян. Он уже не первый раз замечен в подобных махинациях. Где-то год назад он уже пытался замутить какую-то аферу с сдрекорд-ом

У кого-нибуть есть описание формата dump(овского) файла?

открой в фаре, там XML

> Интересно, я бы на месте SUN написал HOWTO move your opensource project from GPL to CDDL. :) Вопрос вот в чем -насколько правомерно это будет с юридической точки зрения?

Абсолютно правомерно. Если все держатели копирайта на код (в смысле, все авторы) - согласны, никто не может запретить.

Вот если там линкуются какие-то GPL-библиотеки, начинаются сложности. Насчет LGPL не скажу - с ними в норме проще.

Фигня какая-то, не долбал бы людям мозги, а сразу бы перевёл на БСД лицензию, и пропихнуть было легче бы.

А так - "не себе, не людям".

> а что такое star?

Schilly TAR ;-)

У него еще есть schilly make (smake), и много другого барахла. Кстати, он не только netbsd'шникам сделал это заманчивое предложение, в OpenBSD оно тоже поступило ;-)

> А с поддержкой снэпшотов (fss) в НетБСД свои заморочки..

позвольте поинтересоваться а они вообще имееются ?

зы: вроде fsck (NetBSD) не поддерживает background checks, которые напрямую базируются на snapshot возможностях UFS2.

fss имеется в -current ветке. Он нестабилен. fss позволяет сделать read only raw device который соответствует состоянию файловой системы в какой-то момент времени.

по (не только моему) мнению fss не имеет никакого отношения к background fsck. А вот для дампа он годится.

fss не имеет никакого отношения к background fsck потому что потому. Вот у тебя есть ФС с возможными дефектами. В чем смысл делания с нее снэпшота? Дать возможность примонтировать этот снэпшот read only? Во первых, в большинстве случаев read only мало. Во вторых, ФС то с дефектами -- монтирование дефектной ФС это undefined behaviour.

В общем fss этой проблемы не решает. Может какие-то другие снэпшоты имеешь в виду..

> А вот для дампа он годится.

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

http://mail-index.NetBSD.org/current-users/2005/02/08/0016.html

Надо заметить, это проблемы NetBSD. В той же FreeBSD и со snapshop, и с background fsck, и с dump все в полном порядке.

> fss не имеет никакого отношения к background fsck.

Имеет. Чекается snap, а изменения "проваливаются" до fs.

> Во вторых, ФС то с дефектами -- монтирование дефектной ФС это undefined behaviour.

Если fs так убита, что её нельзя монтировать, то о каком вообще _background_ check может идти речь? Сначала, перед монтированием, идет проверка (очень быстрая): "а есть ли там ошибки, несовместимые с жизнью?", и только потом монтируется, или чекается в foreground.

Поэтому и для `fsck_ffs -B`, и для mksnap_ffs необходима поддержка softupdates.

softupdates _гарантирует_ непротиворечивость fs. В случае сбоя возможны всего две проблемы: а) какие-то блоки отсутствуют во free map, т.е. fs сообщает меньший размер свободного места, б) если сбой произошел в середине mv, на файл будет два линка: новый успел создаться, а старый не успели удалить.

Логично, что первую исправил `fsck_ffs -B`, а вторую только человек.

> http://mail-index.NetBSD.org/current-users/2005/02/08/0016.html

Во FreeBSD этой проблемы нет. Просто у dump есть опция -L, которая говорит, что дампим "живую" fs: `dump -L -3uf /dev/sa0 /usr`. Благодаря этому '-L', dump сначала сделает snapshop /usr, а затем будет работать только с ним. При этом в /etc/dumpdates будет /dev/da0s1f в моем случае. И никаких проблем.

То есть ФС запоминает опции с которой ее монтировали последний раз, и если там был async, то background fsck не происходит?

> Имеет. Чекается snap, а изменения "проваливаются" до fs.

imho верхом изящества это решение назвать трудно..

> softupdates _гарантирует_ непротиворечивость fs

падения вовсе не всегда вызваны питанием. После kernel panic никто никому ничего не гарантирует.

> То есть ФС запоминает опции с которой ее монтировали последний раз, и если там был async, то background fsck не происходит?

FS всегда сохраняет, куда её последний раз монтировали, был ли umount. softupdates -- это флаг fs, если он стоит, то хоть замонтируйся async, толку не будет. Чтобы снять флаг, fs должна быть clean, то есть размонтированной. Но как только ты снимешь softupdates, background fsck и snapshots перестают работать.

> imho верхом изящества это решение назвать трудно..

Почему? Мы знаем, что все произошедшие после монтирования изменения корректны, соответственно, надо проверить только прошлое состояние fs, до mount. Для этого достаточно прочекать snapshot, созданный в момент монтирования.

> падения вовсе не всегда вызваны питанием. После kernel panic никто никому ничего не гарантирует.

Гарантирует. При использовании softupdates fs _всегда_ непротиворечива. Да и если подумать, kernel panic _ничем_ не отличается от пропадания mains в произвольный момент времени.

> по (не только моему) мнению fss не имеет никакого отношения к background fsck. А вот для дампа он годится.

Может быть Вам (и не только Вам) следует прочитать работы Кирка МакКусика на этот счет ?! Hint: README на этот счет можно найти в сырцах FreeBSD

> imho верхом изящества это решение назвать трудно..

начнем с того, что это не нам решать. Во-вторых, детали реализации в полной мере можно узнать только заглянув в сырцы, насколько я понимаю, из нас этого никто не делал. А по поводу самой идеи, мне свойственно доверять МакКусику, потому что в вопросах FS он имеет богатый опыт и за многие его теоретические наработки и практические реализации - почет ему и низкий поклон. Ну и, на последок, NetBSD и этим похвастаться не может.

>Конечно много кто. star умеет XFS ACL сохранять.

А чем cpio плох?

А он умеет? Когда научился?

Просто я смотрел давненько. Вот например из федориной доки:

What if you want to archive/backup files or directories with ACLs? Besides cp, what is there? Unfortunately, tar, cpio, pax, and dump will not save and restore ACL information. You can use the setfacl --restore mechanism in conjunction with a standard archiving/ backup system, but that is far from ideal. The answer is star, a TAR-like utility that is included in the Fedora Core 2 distribution.

Ну и дальше описание как хорошо пользоваться star

star

>>Конечно много кто. star умеет XFS ACL сохранять.
> А чем cpio плох?
да ничем. star лишь немного лучше в реальной жизни по скорости - визуально процентов на 30. ну плюс xattr/acl умеет сохранять.
но их можно и через getfacl/setfacl поставить после tar.