Хе-хе. Помню спор двухгодичной давности, когда бесплатные
бздуны пяткой в грудь себя стучали и говорили, что "это нам ненадо". А я им говорил, что через пару лет оно у вас все
равно появится, и вы будете жутко гордиться ;)

Бсдуны

Та же фигня... Типичная речь бсдуна

Этап первый: "xxx нам не надо, всё это от лукавого" - когда оно есть где-то, но не во фряхе Этап второй: "Вот, теперь <xxx> сделали, вообще рулез теперь, фряха порвёт всех как тузик грелку. ".

Переход к этапу номер 1 для другого xxx

А кто такой это Терри Ламберт? Звучит не очень убедительно. В частности,
что журнал спасет от уничтожения информации на дорожке.
Вообще я bsd не юзаю, но знаю, что если нужна надежность информации
люди используют ups.

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

А что, UPS помогает от багов в кернеле?

2 green (*) (2003-01-17 23:55:55.677)
А что журнал помогает?
Вот думаю поставить 2.5 ;) Там говорят IDE новый, хороший...

to Toster :

>Вообще я bsd не юзаю, но знаю, что если нужна надежность
>информации люди используют ups.

:)))

Если нужна надежность то нужно как минимум :

1) админ не с опилками в башке
2) backup
3) ups
4) hardware raid (желательно с горячей заменой)

В статье обсуждается что от чего помогает, а что нет ;)

to Toster :

>А что журнал помогает?

Часто :)

>Вот думаю поставить 2.5 ;) Там говорят IDE новый, хороший...

:) А чем ext3/XFS УЖЕ СЕЙЧАС не угодили ?

2 MrBool (*) (2003-01-18 00:09:54.466)

> Если нужна надежность то нужно как минимум :
Это уже насколько сильно нужна надежность..

2 MrBool (*) (2003-01-18 00:12:03.964)
> :) А чем ext3/XFS УЖЕ СЕЙЧАС не угодили ?
Это я так. По поводу надежности журналирования для экстремалов.
Меня лично reiserfs на 2.4 вполне устраивает.

Вопрос: почему ссылка ведет на http://linuxhacker.ru?
И почему у меня она скачивает какой то мусор вместо txt?

А куда еще ссылке вести?

Мусор потому что Ваш клиент неумеет гзипованного контента. Рекомендую воспользоваться Netscape/Mozilla/IE/Opera/lynx на выбор.

Да, зелёный, что ты в самом деле =)

Кстати, насчёт linuxhacker.ru мне лично не понятно - для чего он? Сейчас это вроде как только другое имя для ЛОРа.

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

Письмо интересно, но ещё мне понравилась строка X-Mailer: Mozilla 4.79 [en] (Win98; U) =)

> но ещё мне понравилась строка X-Mailer: Mozilla 4.79 [en] (Win98; U)

Ха-ха. Виндовс и БСД - эта ж близнецы братья. Половина мессаг
в списках рассылки БСД написано в виндовых мэйлерах. И никого
это не удивляет (^||^)

> :) А чем ext3/XFS УЖЕ СЕЙЧАС не угодили ?

смотрим новости LOR за прошлый месяц:
"Вышел патч, устраняющий неприятный баг в Ext3!
Основная проблема заключалась в
том, что виртуальная файловая система (VFS) "недостаточно договаривала"
файловой системе, что на самом деле происходит. ext3 должна знать разницу
предназначений между регулярным memory-cleansing writeback и
sync-for-data-integrity."



"Линукс и связанные с ним технологии.." блин :)))

Граждане! Сей Ламберт- мудак из мудаков.
99% имеющихся в природе файловых систем журналируют только метаданные,
я, если честно, знаю только ext3, которая и данные журналирует.
Кроме того, а почему обязательно запишется трек с журналом,а?

Для того анонимуса, кто в танке:
ext3 не могла сделать sync при выходе на определенном типе
журнала (название забыл, помню, что его редко кто ставит из-за
тормознутости). Кто использовал журнал по-умолчанию (ordered), как я,
например, и куча других людей, проблем не испытывал.
Вчера пи...ры электрики вырубили свет - ну и х. - все в порядке,
никаких fsck на входе (а были бы винды, так еще бы какой-нить
scandisk выпал минут на семь - файлов в досовом разделе много,
за 80.000 перевалило).

А вот и ответ этому Лемберту:

Date:      Fri, 17 Jan 2003 14:24:10 -0800
From:      David Schultz <dschultz@uclink.berkeley.edu>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Jason Schoonover <jason_jks@yahoo.com>, freebsd-fs@FreeBSD.ORG
Subject:   Re: JFS vs. Soft Updates (again) (was: Re: large filesystem, journaling filesystem support)
Message-ID:  <20030117222410.GA5449@HAL9000.homeunix.com>
In-Reply-To: <3E27DA7F.D5DBEFB@mindspring.com>
References:  <20030114192634.75751.qmail@web13505.mail.yahoo.com> <20030117075118.GA3493@HAL9000.homeunix.com> <3E27DA7F.D5DBEFB@mindspring.com>


Thus spake Terry Lambert <tlambert2@mindspring.com>:
> > FreeBSD uses softupdates, which achieves similar efficiency and
> > reliability goals to journaling. With softupdates, you don't need
> > to fsck at all at boot time following a power failure or crash
> > because the worst case scenario (hardware failure aside) is that
> > some disk space that is really free is marked as allocated.
> 
> No, the worst case following a power failure is a screwed disk
> track.

Yes, I'm familiar with this failure mode; it has been discussed on
the lists before.  I was grouping it in the ``hardware failure''
category I mentioned so I could make my post concise, so as to not
fall asleep in the middle of it.  ;-)

> Soft updates optimizes for sector writing, not track writing,
> while journalling can journal on the basis of track-sized
> extents.
> 
> 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).

Even if you know the size of each physical track and manage to
write a journalling filesystem that takes that into account, I
would think that you'd wind up wasting memory or paying for
read-modify-write cycles to commit entire tracks.  Nevertheless, I
suppose it could be done.  The LFS was very nearly a solution to
this problem, but it didn't take the disk geometry into account.

If you are going to assume that the hardware is going to do
something stupid (a good assumption), then the problem is actually
much worse than you imply.  RAID controllers and disk firmware,
like operating systems, have race conditions and other bugs.
Neither softupdates nor journalling alone will save you from a
misdirected or phantom write, a misdirected read, or an interface
error.  Hardware checksums will not fix the problem either.  In
the cases of misdirected reads and writes, the checksums match.
For an interface error, there isn't even a checksum to verify,
because it's already been verified and discarded by the disk.  You
need far more than just DC holdup if you want to detect and
possibly correct these problems.

In light of that, I do group softupdates and journalling in the
same category, since neither provides filesystem integrity in the
face of hardware errors.  I agree with you that journalling could
solve one particular problem associated with full track writes,
but as you mentioned, nobody actually does journalling that way.
But the idea that you can take a UFS-like filesystem and fix all
of its metadata integrity problems by adding journalling to it is
nonsense.

There is some ongoing work on a commercial filesystem that can
verify metadata integrity and usually recover from errors on the
fly.  Think of an LFS structured around a Merkle tree.  The
ultimate goal is to be able to swap to it for a while, and still
be able to mount it afterwards without running a filesystem
checker.  People who really need that kind of reliability should
be using that kind of filesystem, and paying the associated
performance penalty.  The rest of us can use softupdates or
journalling and have protection against what is by far the most
common case: filesystem corruption as a result of unordered
metadata updates.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message

А вообще эта новость похожа на провокацию. Завтра выходит FreeBSD 5.0-RELEASE и как раз за полтора дня до этого тут публикуется "новость" с линком линуксхакера (в лице Green-а) на письмо вырваное из рассылки для БСДхакеров. Расчёт прост - мало кто будет разбираться чего там написано и тем более чего на это ответили и грянит флейм.

2jackill: а что такое scandisk?
Для тех кто в танке - забудте про win9x, в NT файловая система изначально была жирналируемой и многопоточной, уже 10 лет как. У линуксоидов она появилась без году неделя как (с многопоточностью правда не склалось, да и с журналом... не очень) и теперь они радостно раздвигают пальцы. Хотя я помню еще те времена, когда каждый линуксоид орал что "журнал никому нафиг не нужен"...:)

>жИрналируемой

А вот и наш тузик проснулся. В новостях скзали что BSD отстает от линукса, а тут пришел пиздунок и сказал что NT всех лучше.

Ирси, дорогое наше лесное уебище! Я помню, как NT 4.0 еще без сервис паков не могла запонить настройки default gw. Стоило открыть свойства сетевого окружения и закрыть, после чего настройки слетали, и приходилось долго и нудно возить мышой чтобы их прописать снова.

Кстати не у линуксоидов не сложилось, а у тебя с судьбой, несчастный!

А если в raid 256M cache который не успели слить на дорожки, а питание

пропало ? Какой журнал спасет от этой ситуации ?

Нужна надежность ?

Поставьте smart ups, который умеет грамотно останавливать сервер и регулярно

меняйте на нем батарейки, тогда проблем не будет.

Саныч

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

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

Hi!

ISO'шники FreeBSD 5.0 уже выложили.
Анонса вот только нет.

ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/5.0/

-rw-r--r--  1 1006  1006  603783168 Jan 18 04:55 5.0-RELEASE-i386-disc1.iso 

-rw-r--r--  1 1006  1006  279576576 Jan 18 00:24 5.0-RELEASE-i386-disc2.iso 

-rw-r--r--  1 1006  1006  231604224 Jan 18 01:56 5.0-RELEASE-i386-miniinst.iso 

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

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

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

Ну пропадет немного данных. Ничег острашного. ДАвно уже есть механизмы позволяющие сказать IDE/SCSI устройству нечто вроде "Не записывай этот блок пока не запишешь все что попало в кеш перед ним". ТАким образом вполне можно избежать нежелательнного реордеринга при записи.

4Irsi: разве NTFS журналируемая? Где об этом можно почитать? Интересно.

to anonymous (*) (2003-01-18 05:39:46.19) :

>смотрим новости LOR за прошлый месяц:
>"Вышел патч, устраняющий неприятный баг в Ext3!
>Основная проблема заключалась в том, что виртуальная
>файловая система (VFS) "недостаточно договаривала"
>файловой системе, что на самом деле происходит. ext3
>должна знать разницу предназначений между регулярным
>memory-cleansing writeback и sync-for-data-integrity."

У меня проблемы с ext3 были только на 2.4.19 от Mantel (SuSE)
После дружеского пинка Мантель починил это хозяйство. То
что ты описываешь относится к data=journal, по умолчанию
же везде data=ordered и там все в порядке :)

2green

>Ну пропадет немного данных. Ничег острашного.

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

Она успешно завершилась, деньги отъехали в Сингапур, а у Вас пропал

cache.

И что будем делать ?

Звонить в Сингапур и просить вернуть деньги взад ?

Никакой журнал не обеспечивает сохранности данных.

Его основное назначение - восстановить состояние fs на момент минус n секунд

до краха. И сделать это можно за несколько минут.

А без журнала стандартному fsck потребуется несколько часов/суток на

большой fs.

Саныч

Транзация не завершилась до тех пор пока от диска не пришло подтвержденеие успешной записи блока. Блок помечен как "пока все что передомной не скинешь на диск, меня не записывай". Таким образом то что ты описываешь непроисходит. А если происходит - то это ошибка в программе которая отдала деньги до того как убедилась что запиь об этом локально присутствует и не потеряется.

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

>ДАвно уже есть механизмы позволяющие сказать IDE/SCSI устройству нечто >вроде "Не записывай этот блок пока не запишешь все что попало в кеш перед >ним". ТАким образом вполне можно избежать нежелательнного реордеринга >при записи.

В случае raid это утверждение несправедливо, т.к. контроллеры представляют

собой очень мощные интеллектуальные устройства, управляемые закрытым

firmware, которое к сожалению, не знает что сектора М, N, P содержат суперблоки

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

усмотрению.

Саныч

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

>Транзация не завершилась до тех пор пока от диска не пришло подтвержденеие >успешной записи блока. Блок помечен как "пока все что передомной не скинешь >на диск, меня не записывай". Таким образом то что ты описываешь >непроисходит.

Драйвер диска ничего не знает про транкзацию и вернет признак успешной

операции даже если блок в кеше.

Саныч

Нет. Перечитайте что я написал ранее. Есть возможность проставлять специальные метки каждому записываему блоку. На эти метки смотрит непосредственно диск/умный кеш. Один из типов меток "не записывать блок, пока не очистится кеш". Таким образом эта метка дает нам возможность очищать/сбрасывать на диск кеш устройства в произвольный момент времени.

>и в случае пропадания питания не имеет возможности записать свой кеш на диск,

К чему весь этот огород с пометкой блоков ?

Если есть упс, он сообщит серверу, что проблемы с питаним, тот сделает

стандартные вызовы sync ... wait .. sync и данные на дисках.

Нет упс - чего писать ? Кеш уже разрушен.

Саныч

К тому чтобы сбросить дисковый кеш в устройстве! Да еще и сбросить в нужный момент, например по завершению транзакции. Тогда даже если вдруг сервер умрет от перегрева (тут ups не спасет), ничего особо страшного не случится. Кто сказал что по sync кеш устройства сбрасывается? Несбрасывается! Поэтому ups - не совсем решение.

>Есть возможность проставлять специальные метки каждому записываему >блоку. На эти метки смотрит непосредственно диск/умный кеш. Один из типов >меток "не записывать блок, пока не очистится кеш". Таким образом эта метка >дает нам возможность очищать/сбрасывать на диск кеш устройства в >произвольный момент времени.

Это что как-то стандартизировано ? Откуда производитель firmware знает,

что будет система будет работать под unix, а не под новелл или винду ?

Саныч

насчет XFS/Linux, по моим наблюдениям она все-таки пока не очень стабильна... за несколько месяцев активной работы видел такие вещи как самопроизвольный unmount и рассинхронизацию листинга директорий c реальным положением дел на диске. Восстановление журнала всегда идет на ура, xfsrepair конечно все находит и лечит (убивая кой-че по дороге в lost+found), но осадочек-то остается... :)

зы: ядро 2.4.19, все остальное сделано шаг в шаг по докам от SGI.

2green

Может быть Вы ведете речь про raw disk storage механизмы?

Многие субд сервера работают таким образом.

То есть сервер Субд работает напрямую с контроллером и рализует все

файловые операции мимо ядра, в этом случае я полностью согласен.

Но речь шла о стандартных fs, работающих через kernel api.

Саныч

Метки не зависят от OS. Все стандартизировано естественно.

Саныч, ходи, например, на t10.org. читай _стандарты_

raw disk storage никак не влияют на кеш дискового устройства. Оно как кеширует так и кеширует. in-kernel fs же имеют доступ к драйверам дисков и вполне могут заставлять эти самые драйвера помечать некоторые блоки как "барьерные". Причем эта барьерность уже работает на уровне дискового кеша в устройстве (а не в основной памяти/кернелном кеше). Что и позволяет убеждаться в том что диск уже записал свой кеш и данныые не пропадут после потери питания.

2green

С каких это пор приложения научились мыслить в терминах блоков ?

Может в ссылочку дадите на системный вызов, которым можно их пометить?

>Кто сказал что по sync кеш устройства сбрасывается? Несбрасывается!

Блин я уже испугался, а вдруг и правда не сбрасывается ! А то я больше по старинке libc юзаю на фре :)

Бегу скорее смотреть man 2 fsync

data moved to а permanent storage device

Если не смогли слить, то получем EIO.

И так было всегда, со времен 4.2 BSD.

Где тут про блоки ?

А если файл на NSF ? Какие блоки ?

Бегом маны читать.

Саныч

К сожаление нежелание думать с твоей стороны делает дальнейшее продолжение нашего разговора бессмысленным.

2green:

Раскол среди организаторов ЛОРа? =)

Если серьёзно - понемногу linuxhacker.ru будет отходить от ЛОРа? Или как?

2smb_about_ntfs:

да, NTFS журналируемая файловая система - так было с NT4 точно. Где об этом можно почитать - думаю на MSDN, хотя не уверен.

Организатор и создатель ЛОРа - maxcom, так что о каком расколе идет вообще речь? ;) Linuxhacker.ru никуда отходить не будет, да и не отходил никогда.

2green

NSF предыдущем постинге это NFS конечно.

Нет, все таки дайте ссылку на syscall которым приложение может пометить

блоки. И это не в пику, может я действительно чего-то недогоняю.

И уже есть более эффективные механизмы чем fsync.

Саныч

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

2jackill: Вообще-то NTFS не только журналируемая - в ней дофига чего вкусного и интересного есть. Из всего зоопарка FS, которые живут под линуксом только пожалуй RaiserFS начинает по фичности к NTFS приближаться. XFS просьба не вспоминать - то что живет под линуксом, от оригинала отличается радикально. Читать на MSDN & TechNet - там есть довольно полное описание NTFS, ее фичь, структуры и т.д.