Т.е. linuxhacker.ru есть зеркало linux.org.ru?

Нет, и никогда небыло в чем легко убедиться направив свой браузер по соответствующему адресу. Единственное сходство между ними прямо сейчас в том что они хостятся на одной машине, но эот как бы никого ни к чему не обязывает по очевидным причинам ;)

СорриюЮ, похоже что немного глючу... =)

2Irsi (*) (2003-01-18 15:37:34.362):

Только вот все эти приемущества NTFS сходят на нет засчет того, что она страшно быстро фрагментируется за счет своего убогого строения - http://www.ixbt.com/storage/ntfs.html. Поэтому если сначала скорости NTFS и ReiserFS сопоставимы, то через месяц использования они различаются на порядок. Правда если их не дефрагментировать.

Мне вот только плохо понятно, почему нельзя поменять механизм распределения файлов в NTFS - это ведь ни коем образом не скажется на структуре, а только уберет эту дурацкую необходимость еженедельной дефрагментации. К примеру ext2 живет годами при фрагментации 3-5%.

2Irsi. NTFS это конечно хорошо и фичасто, но у нее на данный момент мину сы перекрывают плюсы. Дефрагментация одна из них другая, это несбалансированная скорость отдачи/записи больших блоков данных. График скоростей похож на шторм когда на других журналируемых FS это море в штиль.

2green

>Приложение пометить не может. Пометить может файловая система. Тогда >когда это нужно файловов системе для обеспечения целостности метаданных.

Говорим про фряху

Файловая система работает в терминах vnode.

Синхронизацией dirty buffers и диска занимается системный процесс syncer,

который тоже работает в терминах vnode.

Он примерно 1 раз секунду обратывает очереди vnode, которые заполняются

ядром. А кто тогда метит блоки а главное зачем , ведь целостность

достигается именно этим путем?

Все равно если не syncer успеет сбросить dirty caches ядра, то метаданные

погибнут ? Что и наблюдаем в случае kernel panic.

Саныч

> linuxhacker.ru для меня. А LOR - для всех. НА linuxhacker.ru я
> выкладываю то что нахожу интересным.

Значит ответы других участников той рассылки тебе неинтересны? Обычно
люди, либо принимают непосредственное участие в обсуждении, либо ждут
пока оно закончится и лишь затем сохраняют у себя всю ветку. Если
тебе неинтересна дискуссия, то зачем приводить вырваное от туда
единственное понравившеесе лично тебе мнение? С тем же успехом, на
какой нибудь computerra.ru могут появляться "новости" основаные на
чьём-то выссказывании из linux.org.ru. А какие тут бывают
выссказывание надеюсь все знают.

> Где живет архив этой рассылки (и есть ли он вообще) я незнаю. У
> меня есть интересные письма - я их выкладываю, будь то письма из
> lkml или других листов.

Как я уже говорил, выкладывать лучше не одно-два письма вырваные из
рассылки, а более-менее весь разговор. А архив, вот он - www.freebsd.org/mail

2anonymous (*) (2003-01-18 16:44:15.283): ку! статья-то еще про NT4... Поменялся алгоритм выделения с той поры это раз, два - дефрагментация в NT это палка о двух концах, ибо единыжды ее сделав будешь вынужден делать ее регулярно и часто, а если ни разу не делат, то вполне можно жить и без нее... Вообще по мне так лучше без нее вообще обходится...
2Korwin: ну про дефрагментацию я уже сказал (у меня после года (даже немного болше) интенсивной работы она сейчас около 4%), на счет больших блоков данных - не замечал, где почитать можно?
Ктому же это все относится к реализиции, а я вообщем говорю о структуре и идеях, заложенных в разных FS... Если говорить о реализации, то сразу надо заметить что под линукс просто нет достаточно стабильной реализиции журналируемой FS - все что есть пока весьма сыровато имхо...

Re:

в подтверждение журналируемости NTFS - можно провести следственный эксперемент: подойти к каком-нибудь знакомому, сидящему под win2k на NTFS разделах. Ну и тихонько, что-бы никто не заметил - reset нажать... NTFS репеарится в таком случае считанныей секунды, а вот если взять win2k, которая живет на фате - то прийдется несколько минут ждать...

P.S. Сам я не сторонник винды, просто факты указываю :)

Нет, все-таки ты не хочешь думать. ;) Последняя подсказка:

Системный процесс syncer обработал очередь "в терминах vnode" ;) Затем все это дело ушло к диску, диск положил данные в свой кеш и бодро отрапортовал что все готово и записано. syncer дождался этого подтверждения от диска и опять впал в спячку. Диск записал, домустим, первый блок из тех что он принял непосредственно на диск. Пропало питание. Все те данные которые syncer вроде бы как скинул на диск - на самом деле пропали кроме первого блока. (а на самом деле может диск решил что ему выгодней записть блок из середины и записал его, тут не так важно, хотя для журналирующей системы таки важно). Так же вместо syncer вполне мог быть процесс вызвавший sync() или fsync().

Смысл в том что если не использовать write barriers, то OS и приложения считают что данные уже на диске, тогда как они на самом деле пока еще в кеше и пропадут в случае неожиданного пропадания питания/резета/whatever

в подтверждение журналируемости NTFS - можно провести следственный эксперемент: подойти к каком-нибудь знакомому, сидящему под win2k на NTFS разделах. Ну и тихонько, что-бы никто не заметил - reset нажать... NTFS репеарится в таком случае считанныей секунды, а вот если взять win2k, которая живет на фате - то прийдется несколько минут ждать...

Ну Вы батенька шутник. А если там 1с с dbf и 10 теток из бух. баланс сводят ?

Вам не то что нажмут, а все оторвут по самое небалуйся :)

Саныч

Сравнение с LOR некорректно. Ведь напиши Alan Cox письмо в lkml с какими-нибудь откровенными заявлениями, никого не будет интересовать что там ответил ему какой-нибудь John Doe. Потому что John Doe ничего не решает. И распространяться будет в основном письмо или цитаты из письма именно Alan Cox'а.

Саныч прости, но это проблемы 1С... Ой не зря мелкософт их статуса своего партнера лишил...;)

> FreeBSD 5.0 вышло вчера.

Во первых не надо путать рода, FreeBSD 5.0 - это она, а не оно.
Она система, а не оно ядро, не путай с Linux. Во вторых "появилась"
и "вышла" - это две большие разници. Есть официальная дата выхода
(которая может изменяться), есть анонс наконец; очень советую
использовать эти источники, а не лазание по ftp или "одна бабка
сказала". В третьих есть несколько FreeBSD 5.0, я говорил о FreeBSD
5.0-RELEASE, а ты?

> А видеть провокации во всем - попахивает паранойей. Но все же
> надеюсь большинство с интересом прочитают то письмо, подумают сами
> и сделают для себя какие-нибудь выводвы. Или не сделают, но все
> равно узнают что-нибудь новое.

Ну а как кроме провокации это можно понимать? Ты вырываешь отдельно
взятое письмо из рассылки и за полтора дня до релиза приводишь его
тут как некую очень важную новость. Мол смотрите все, как круто они
ошибались. При этом предыдущих и последующих писем на ту же тему и из
той же рассылки у тебя нет, где находится архив ты не знаешь. Как
вообще то письмо Terry Lambert-а к тебе попало? Видимо ты подписался
на freebsd-fs@freebsd.org, тогда зачем утверждать, что ты не знанешь
где находится архив?

Большинство людей с не меньшим интересом прочитали бы всё обсуждение
целиком и возможно сделали бы для себя какие-то выводы.

Касательно 5.0, да я тоже говорил о 5.0-RELEASE, все согласно /usr/src/UPDATING где позавчера появилась строка "20030117: FreeBSD 5.0-RELEASE". При этом в тот же день (16 января) система стала по uname -a отзываться как 5.0-RELEASE.

Письмо ко мне попало из заслуживающих доверия источников. Насчет "как круто они все ошибались" - кто все? насчет чего ошибались? Ни слова я про "ошибались" не сказал. При чем тут полтора дня до релиза мне тоже непонятно.

С моей точки зрения интересная новость состоит в том что один из ключевых FreeBSD архитекторов высказал идею о необходимости журналирующей FS для FreeBSD и чем скорее тем лучше. А что там ты в своей паранойе выдумал - это уже конечно твое дело.

2 green

Про write barriers услышал только от Вас.

Это появилось недавно ?

Почему *bsd ядра не используют этот подход, а предлагают отключать write cache

при softupdates

А ядра линукс уже умеют это делать ?

А какие диски умеют это делать ? Например старые ata 33 умеют ?

И вообще кто умеет это делать, дайте ссылочку какую нибудь.

Саныч

2 Irsi

>Ой не зря мелкософт их статуса своего партнера лишил...;)

А за что лишил ? Очень интересно.

Саныч

"Это" (write barriers) появилось ну никак не меньше пары лет назад, если речь про SCSI, когда появился соответствующий IDE код я незнаю, но тоже достаточно давно, как мне кажется. В стандартах когда это появилось я тоже незнаю, в SCSI правда чуть ли не с самого начала было помоему.

Почему *BSD ядра не используют этот подход я незнаю.

Ядра линукс такое делать умеют, но в mainstream ядро кодж вошел не так давно. SuSe например уже больше года у себя такой код имеет.

ATA33 не такие уж и старые диски ;) По идее тоже должны уметь, но неуверен.

Larry Lambert - далеко не такая же, для FreeBSD, значимая фигура
как Alan Cox в Linux, поэтому пример неуместен. Что-то не видно его,
ни в http://www.freebsd.org/doc/en/articles/contributors/staff-core.html
ни в http://www.freebsd.org/doc/en/articles/contributors/staff-committers.html
а то что он записан в http://www.freebsd.org/doc/en/articles/contributors/contrib-additional.html
не делает его личность столь уж известной, а мнение столь уж решающим.
Он даже не коммитер. Кроме того, не хотелось бы здесь устраивать
сравнение титулов и званий.

Саныч, я не в курсе за что конкретно... Но то что 1С ни разу не соответствует спецификациям на софт от мелкософта это факт... То что оно хранит свои данные где угодно, окромя домашнего каталога, то что оно ну никак не увязывается например с AD имхо вполне достаточно для того чтоб мелкософт им дал пинка под зад... А за то как оно с SQL DB работает вообще надо стрелять на месте, ну или ладно блин, будем гуманистами - оборвать руки (чтоб по клаве не барабанили) и яйца (чтоб такие уроды не плодились)...

2Irsi (*) (2003-01-18 17:36:22.958):

>Ктому же это все относится к реализиции, а я вообщем говорю о структуре >и идеях, заложенных в разных FS... Если говорить о реализации, то сразу >надо заметить что под линукс просто нет достаточно стабильной >реализиции журналируемой FS - все что есть пока весьма сыровато имхо...

1) Во-первых там рассматривается и Win2000, и потом, ну не 4% фрагментации у меня на системном диске, который был отформатирован в августе, а заполнен на половину...

2) Вы опять начинаете перегибать - посмотрите первую фразу - "а я вообщем говорю о структуре и идеях, заложенных в разных FS...", а сразу же потом опять какая-то чушь - "Если говорить о реализации, то сразу надо заметить что под линукс просто нет" - напоминаю, секунду назад вы решили говорить о концепциях!

3) Хорошо, я соглашусь, что в концепции это все по большей части здорово, но реализации нет. Ни под Win (практически, т.к. у NTFS море недостатков - например из-за этой чертовой фрагментации фильм копируется на FAT раздел раза в 1.5 быстрее, чем на NTFS и наоборот, о поиске файла по сравнению с той же ReiserFS и говорить не приходится), ни под Lin (где, как вы утверждаете нет даже концепции).

4sseREGa: а думаешь почему я спросил - журналируемая ли она?
за стенкой стоит машина на ntfs (w2k) и репарится она отнюдь не секунды.
Разделы: 10, 10, 20Gb, pIII-900, 384ram.
Но это фигня. Раз в месяц лучше делать дефрагментацию, иначе комп
начинает тормозить немерянно (на машине сидит дизайнер и туда-сюда файлы
таскает/создает/убивает).

2Irsi (*) (2003-01-18 17:36:22.958):

Да, добавление, если мысль "Вообще по мне так лучше без нее вообще обходится... " возникла до прочтения статьи, то очень рад за вас, значит у вас есть довольно большой опыт использования NT/2k.

Мне как раз хотелось бы узнать, не улучшилось ли чего в XP, по этой проблеме. Т.к. 2к перед глазами и ясно вижу, что если и улучшилось, то не кардинально.

Ok, более корректным будет сравнение с Remy Card.

2jackill (*) (2003-01-18 18:55:12.882):

С Fat это происходило бы за 5-10 мин/раздел.

2anonymous (*) (2003-01-18 18:50:04.475): нет я не понимаю онанимусов... я же имхо четко сказал, если немного подумать, а именно - "я вообще-то говорил о концепции, но если вам хочется поговорить о реализациях, то получите". Или все как малым детям разжевывать надо?
На счет недостатков NTFS - я не знаю как Вам удалось добится таких проблем с фрагментацией на оной, могу предположить несколько вариантов, а именно:
1. Конвертнули fat/fat32 в ntfs.
2. Воспользовались дефрагментатором.
3. Использовали утилитки типа Partition Magic.

Я не говорю что проблем с фрагментацией в NTFS совсем нет - есть разумеется, но порядок тот же что и на других современных FS. Реально принимать какие-то меры борьбы с ней мне приходилось только на файл-сервере, где кроме всего прочего (файлопомоки и т.д.) жили БД 1С и перемещаемые профили сотни-другой юзеров... Но и там мне гораздо больше проблем создавал IDE RAID5 от Promise

2anonymous (*) (2003-01-18 18:56:39.188): да ничего не улучшилось... и имхо - не уличшится... Посмотри соответствующую статью на сайте ConfigNT (на systeminternals тоже вроде что-то было по этому вопросу) - там неплохо расписаны причины, по которым к дефрагментатору в NT/2k/XP лучше вообще не прикасаться...

2jackill: дефрагментацию NTFS лучше ВООБЩЕ не делать. Ибо сделав один раз, ты будешь вынужден делать ее как минимум ежемесячно, а то и еже недельно...

> Т.е. linuxhacker.ru есть зеркало linux.org.ru?

та нее.... зеркало linux.org.ru это linux.org.tw

> Касательно 5.0, да я тоже говорил о 5.0-RELEASE, все
> согласно /usr/src/UPDATING где позавчера появилась строка "20030117:
> FreeBSD 5.0-RELEASE". При этом в тот же день (16 января) система
> стала по uname -a отзываться как 5.0-RELEASE.

Ну что ты мне свой /usr/src/UPDATING и `uname -a` показываешь?
Очередной FreeBSD 5.*-STABLE ты тоже релизом назовёшь посколько строка
обновилась? Вместо непонятно каких и непонятно почему "заслуживающих
доверия источников" следует пользоваться официальной информацией:
http://www.freebsd.org/releases/5.0R/schedule.html

> Письмо ко мне попало из заслуживающих доверия источников.
> Насчет "как круто они все ошибались" - кто все? насчет чего
> ошибались? Ни слова я про "ошибались" не сказал. При чем тут
> полтора дня до релиза мне тоже непонятно.

Ты противопоставил свою "новость" известному факту о том, что команда
разработчиков FreeBSD в своё время отвергда идею журналирующей
файловой системы. Если есть противопоставление, то значит кто-то
считает, что кто-то другой ошибался, не так ли?

> С моей точки зрения интересная новость состоит в том что один из
> ключевых FreeBSD архитекторов высказал идею о необходимости
> журналирующей FS для FreeBSD и чем скорее тем лучше. А что там ты в
> своей паранойе выдумал - это уже конечно твое дело.

Да никакой он не ключевой, я об этом уже говорил. Интересной новостью
это было бы если действительно ключевые фигуры FreeBSD Team
*приняли бы решение* о том что журналируемая файловая система для
FreeBSD действительно необходима. А так, далеко неключевые люди ведут
чисто теоретический диспут. И если бы новостью был сам диспут, так нет
же... "заслуживающие доверия источники" вырвали от туда одно
единственое высказывание.

4anonymous (*) (2003-01-18 18:59:00.944):
А на ext3 такого г..на вообще нет.
Как говорится, почувствуй разницу.
4Irsi: я тут прочитал только что статью на ixbt - они утверждают,
что при наполнении раздела на 90 процентов и выше начинается дикая
фрагментация. Что, собственно, я и наблюдаю на соседней машине.
А линукса стоят три года, два с половиной из которых они провели
на ext2. Фрагментация 3%.
Да, еще вопрос - почему после дефрагментации придется ее часто
проводить? По теории дефрагментатор должен выстроить данные файла
как можно ближе друг к другу, а лучше подряд.
MS-овский дефрагментатор признан одним из худших (да он еще и тормозной). Лучшим является из NU (speeddisk).

Бздуны и Линурасы... Ламберт кажется понятно написал, что НЕТ нормальной журналируемой FS ни в линуксе, нигде в другом месте
"If it is written correctly (there are a number of technical
challenges to writing this correctly, and SGI, IBM, and Linux
haven't done it, but it's theoretically possible, though very
hard on IDE -- much easier on SCSI because the physical geometry
can be accessed via mode page 2)."
В том виде, в каком она реализована, её нафиг не надо портировать на FreeBSD или делать с нуля - SoftUpdates с теми проблемами, которые решают текущие реализации, справляются.
А надо - как следует. Идеально. Как никогда не будет реализовано нигде, а в Linux особенно.

... и имя его было Пророк, а в миру Shadow..

2jackill (*) (2003-01-18 19:29:26.343):

С ext2/3 вы не открываете Америки я думаю и Irsi, т.к. лет ext2 уже много, очень много. И на ней всю жизнь стабильно держится 2.5-3.5% фрагментации годами. Насколько я помню там все же стоит какой-то механизм, препятствующий дефрагментации.

Далее, насчет дефрагментации нормально написано в статье на ixbt.com, которая приводилась мной выше. Просто прочтите ее чуть подальше, а именно "Часть 2. Особенности дефрагментации NTFS", и второй абзац...

2Irsi (*) (2003-01-18 19:07:48.998): Спасибо за ссылки.

2jackill: короче - мелкомягкое API для дефрагментации оперерирует "кусками" в 16 раз большими чем размер кластера (не блока!!!) на диске... Для чего было так сделано - х3. В связи с этим после дефрагментации на диске после каждого файла появляется дырка, размером <16 кластеров... Последствия имхо очевидны.
Далее - НЕТ мелкомягкого дефагментатора, есть diskeeper lite, который стал поставляться в составе win2k/xp. Нортоновский (АКА симантековский) дефрагментатор чуть ли не единственный, который не использует мелкомягкое API для дефрагментации. У этого есть два последствие - хорошее и плохое. Хорошее заключается в том что после дефрагментации им не возникает вышеописанной проблеммы. Плохое заключается в том что как и любое ПО, написанное не в строгом соответствии со спецификациями на данную ОС, он иногда вызывает проблемы, выражающиеся в разрушение структуры дефрагментируемого им диска...
Если диск забит >80%, то надо думать не о дефрагментации, а о покупке нового диска... Притом срочной. Кстати, каково заполнение дисков с ext2? ;)

Гм, если не uname -a, то что же?

А "известный факт" того что "команда разработчиков FreeBSD в своё время отвергда идею журналирующей файловой системы" я только что узнал от тебя. ;) Вроде как вменяемые люди ;)

Ну что ж, вырвите высказывание действоительно ключевой, по вашему мнению, фигуры на эту тему и опубликуйте его здесь.

> где позавчера появилась строка "20030117: FreeBSD 5.0-RELEASE".

Может я чего-то не понимаю, но если 20030117 - это позавчера, то какая
дата сегодня?

Позавчера эта строка появилась в файле. cvs умеете пользоваться - проверьте.

> Гм, если не uname -a, то что же?

Я уже приводил ссылку, неужели ты по ней не пошёл? Релиз - это не
версия, а факт выпуска продукта. Изменения в CVS, которые происходят
довольно часто, релизами не являются. Ты не можешь установить новую
систему с нуля используя CVS, так же ты не можешь установить packages
по ftp используя /stand/sysinstall до того они на этих ftp серверах
появятся. Какой же это релиз?

> А "известный факт" того что "команда разработчиков FreeBSD в своё
> время отвергда идею журналирующей файловой системы" я только что
> узнал от тебя. ;) Вроде как вменяемые люди ;)

Ну попробуй вменяемо опровергнуть. А лучше прочти вот это:
http://www.freebsd.org/doc/en/books/handbook/configtuning-disk.html
Кстати, Soft Updates не только в FreeBSD используют, но и в других
BSD системах. Видимо не зря.

> Ну что ж, вырвите высказывание действоительно ключевой, по вашему
> мнению, фигуры на эту тему и опубликуйте его здесь.

Зачем же мне уподобляться тому, кого я критикую? Я уже говорил, что
лучше приводить всё обсуждение целиком, а не вырваные из него части.
Обычно, если обсуждение было интересным, именно так и делают.

А я отказался от ext3. Если честно, то меня задавила жаба. Не смог спокойно перенести 15-20% потери производительности файловой системы ;)
Серваки падают очень редко. 10 минут fsck пережить можно.

По ссылке на "Tuning Disks" фигня написана. В частности "Meta-data updates are still written synchronously..." про журналинг. Ничего synchronously не пишется ясное дело. "Because the logging area is a small, contiguous region on the disk" - опять фигня. Чуваки не слыхали аро relocated journal никогда? А некоторые файлуха аллоцируют журнал по ходу дела и потом не копируют ничего никуда.

Вот еще любопытный момент: "the data blocks are sorted according to their position so that they will not be on the disk ahead of their meta-data". То есть Метаданные записались, а в файлах - предыдущее содержимое тех блоков? Очень интересное кино.

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

По поводу вырывания из контекста - ну не вырывайте, просто ссылки на ответ ключевой фигуры хватит ;)

Еще мне понравилась рекомендация выключать write cache. То что при этом write throughput в отдельных случаях падает 5-10 раз видимо никого не волнует.

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

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

Что же ты считаешь за ноль?

Я? Я незнаю. Как то мне системы вообще без ничего не попадались. Ты упомянул установку с нуля - ты и скажи что такое ноль, а там посмотрим можно ли с этого нуля установить из cvs чо-то или нет.

> По ссылке на "Tuning Disks" фигня написана.
> [skiped]

Я приводил ту ссылку не для обсуждения достоинств и недостатков
Journaling и Soft Updates, а как демонстрацию того, что команда
разработчиков FreeBSD отвергла Journaling в пользу Soft Updates
для родной в BSD файловой системы FFS.
Зачем передёргивать? Если ты не согласен с тем, что написано по
ссылке, напиши в freebsd-doc@freebsd.org. Либо с тобой согласятся
и исправят FreeBSD Handbook, либо популярно объяснят в чём ты
заблуждаешся.

Ясно. Ну отвергла и отвергла. Что ж теперь. Буду знать.

2green:
> Тerry Lambert это такой известный FreeBSD-архитектор/девелопер. http://people.freebsd.org/~terry/

Вольно, вьюноша. Терру Lambert - это такой известный говорящий ящик, обретающийся на FreeBSD mailing list-ах, и пишущий ненормальное количество писем безапелляционным тоном и по любому поводу.

Ну да это надо знать, а вам-то откуда. Вы ж числу людей, знающих предмет по личному опыту, не относитесь.

> А что, UPS помогает от багов в кернеле?
А журнал от них панацея?

Журнал - так же не панацея. В писме рассмотрено несколько ситуаций когда журнал помогает, а softupdates - нет.

> > > > > Гм, если не uname -a, то что же?
> > > >
> > > > Я уже приводил ссылку, неужели ты по ней не пошёл? Релиз - это
> > > > не версия, а факт выпуска продукта. Изменения в CVS, которые
> > > > происходят довольно часто, релизами не являются. Ты не можешь
> > > > установить новую систему с нуля используя CVS, так же ты не
> > > > можешь установить packages по ftp используя /stand/sysinstall
> > > > до того как они на этих ftp серверах появятся. Какой же это
> > > > релиз?
> > >
> > > По поводу установки системы с нуля - смотря что считать за ноль.
> >
> > Что же ты считаешь за ноль?
>
> Я? Я незнаю. Как то мне системы вообще без ничего не попадались.
> Ты упомянул установку с нуля - ты и скажи что такое ноль, а там
> посмотрим можно ли с этого нуля установить из cvs чо-то или нет.

Ты конечно можешь установить предыдущую версию и потом обновить её
через CVS. Однако это не будет называться установкой
FreeBSD 5.0-RELEASE. Я уже говорил, что релиз - это готовый продукт,
а то, что лежит в CVS таковым не является. Как по твоему, зачем
вообще выпускают *.X-RELEASE если можно просто установить *.0 и потом
наращиваться через CVS?

> Там есть его мыло, можно все спросить напрямую. Мне на тот же вопрос
> он ответил в духе "Если мы не можем прочитать один из треков с
> журналом, то можем считать его пустым"
Заодно пустым будем считать и попавшую на этот трак информацию => продолжая цепочку приходим к необходимости горько оплакать консистентность данных на FS вообще, да и саму FS тоже.

p.s. на могилке напишем: "Был спасён журналом...типа"

> Журнал - так же не панацея. В писме рассмотрено несколько ситуаций
> когда журнал помогает, а softupdates - нет.

Так всё таки журнал - панацея или иногда не помагает?

> А кто такой David Schultz и чем он известен чтобы воспринимать его серьезно?

А вот для этого надо бы почитать списки годиков так пять, вопрос бы просто не возник.