> По поводу суперскоростных операций софтапдейтов - проведи эксперимент, > открой с десяток файлов с O_SYNC и позаписывай в них по одному в цикле > по одному байту. Посмотри на скорость. Правда прикольно? :)
Давай то же на ext3? Без data journaling? А теперь потоком с десятки мегабайт, но с data journaling.

Идею уловил?

Идею не уловил, почему БЕЗ data journaling?

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

>Тамессага что ты показал выдается инит скриптами и к ядру отношения не имеет.
И во фре тоже (в /etc/rc помойму)
> И если ты Y не нажмешь, никакого fsck не запустится (в случае с reiserfs, в случае с ext3 - оно запустится чтобы проиграть журнал).

Так тут вроде ext3 и рассмвтривали. Это же mainstreem ))
И ваще большинство здешних линуксоидов ведь считают что "в живых должен остаться один", так что, есля следовать этой логике поделки типа JFS, XFS, reiserfs рано или поздно сдохнут вместе с бздёй :-)
А играть журнал зачем?

Чем же открытие насчет фрагментации ложное?

disk image с потерянными блоками консистентным НЕ ЯВЛЯЕТСЯ, в не зависимости от того что ты утверждаешь. И в штатном режиме работать не может, потому как ей может блоков-то свободных и не хватить, хотя они и есть. Кстати у меня есть неслабые сомнения насчет того что потерянные блоки - единственный возможный тип коррапшена при аварийном завершении при использовании софтапдейтов.

Как знать кто сдохнет, reiserfs или ext3 ;) Опять же кто из них более mainstream - тоже тот еще вопрос. reiserfs в ядре раньше вроде как.

Журнал играть очевидно зачем, чтоб коррапшенов избежать. И это может и само ядро сделать, но вот инитскрипты решили по другому (не все, кстати сказать)

Во фре - не то же. Во фре ты обязан запускать fsck после аварийного завершения для того чтобы исправить появившиея (возможно) ошибки, почистить зазря занятые блоки и тп). А если ты его запускать не будешь - то у тебя будут проблемы при использовании этой fs.

> Идею не уловил, почему БЕЗ data journaling?
Вот потоковую запись мне и продемонстрируй.

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

Демонстрирую потоковую запись с data-journaling на reiser4. ;)

Я сейчас уезжаю на KS, буду обратно 29го числа, тогда можно и продолжить прикидывать как софтапдейты сливают правильно реализованному журналу ;)

> Чем же открытие насчет фрагментации ложное?
Потому как годами используемую FS тебе показывали, цифирки там были _типичные_.

> disk image с потерянными блоками консистентным НЕ ЯВЛЯЕТСЯ,
FS работает, блоки между разными файлами не шарятся - значит является.
У тебя странная тенденция путать понятие исчерпывающей информации с её консистентностью.

> И в штатном режиме работать не может, потому как ей может блоков-то
> свободных и не хватить, хотя они и есть.
Безусловно, в FS эксплуатируемой с 99.99% заполнением. Получит user 'out of space' сейчас, которое всё равно получил бы очень скоро, FS то при этом не упала, значит работает _штатно_.

> Кстати у меня есть неслабые сомнения насчет того что потерянные
> блоки - единственный возможный тип коррапшена при аварийном
> завершении при использовании софтапдейтов.
Это у тебя всё по той же причине - статьи не комментировать надо, их надо читать. Вообще там целый класс описан.

Никакую исчерпывающую информацию я не видел. Вот что ты сказал: "Консистентность disk image FS - вот цель softupdates." так вот о какой целостности идет речь с потерянными блоками то? Сам разбирайчя что ты там где путаешь ;)

Насчет "все равно он бы скоро его получил", а если ему требуется для работы всего один блок? А там есть десять, но утекли... Ерунда вобщем происходит. Никакой консистентности. Что значит "штатно"? она возвращает ошибку там где все должно работать без ошибки.

Толстозадые водоплавающие в манишках, вы проиграли.Проиграли бесповоротно и окончательно:

http://news.com.com/2100-1016_3-1027188.html?tag=fd_top

Кстати забыл сказать про фрагментацию-то. Так вот показали внутрифайловую фрагментацию, причем при неизвестном usage pattern. А как насчет фрагмментации между файлами в одном каталоге, например?

> Никакую исчерпывающую информацию я не видел.
Дык мы о чём. Однако ж судишь.

> так вот о какой целостности идет речь с потерянными блоками то?
Она повреждена или неработоспособна? Существуют ссылочные противоречия? Нет.

> Насчет "все равно он бы скоро его получил", а если ему требуется для
> работы всего один блок?
Тады ему или его админу - в больницу.

> Никакой консистентности.
Люблю я ваши термины...

> она возвращает ошибку там где все должно работать без ошибки.
99.99% - это уже ошибка.

Она повреждена. Она неработоспособна (см. мой пример). Этого достаточно.

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

99.99% - уже что ошибка? ;)

> Кстати забыл сказать про фрагментацию-то. Так вот показали
> внутрифайловую фрагментацию, причем при неизвестном usage pattern
Не забыв упомянуть о типичности цифирей, не забудьте и это. То есть чтобы достигнуть большую фрагментированность, придётся искать совсем уже клинический случай. Что тот же случай сделает с extent based FS догадаетесь сами?

> А как насчет фрагмментации между файлами в одном каталоге, например?
Это как? Фрагментация "между" файлами - термин несколько непривычный и догадки делать не берусь.

Про rpm: в src.rpm все это конечно можно. А как ты компилятор укажеш делая rpm -ivh *****.rpm?? :0

Про то что с софт апдейтами данные не теряются коментариев нет?

Konokrad

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

> Она повреждена.
Как?

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

> 99.99% - уже что ошибка? ;)
А у вас это нормально?

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

Что-то я не понял логики. То есть выходит файловая система не дает никаких гарантий возможности записи в файл даже при наличии достаточного количества места на диске и наличии необходимых разрешений? Клевый подход.

Фразы про 99.99% и их смысл продролжают ставить меня в тупик... Я непонимаю что ты пытаешься ими сказать.

Кстати о каких предположениях идет речь - неясно. Возникает ошибка в ситуации когда ошибки быть не должно... Следовательно имеет место какая-от проблема.

> Фразы про 99.99% и их смысл продролжают ставить меня в тупик... Я
> непонимаю что ты пытаешься ими сказать.
Фактор замедленного возвращения блоков начинает играть хоть какую-то роль когда файловая система и без того работает на грани переполнения. Это само по себе внештатная ситуация. Так понятнее?

> Кстати о каких предположениях идет речь - неясно. Возникает ошибка
> в ситуации когда ошибки быть не должно...
В ситуации, когда на ошибку _напрашиваются_.

По поводу суперскоростных операций софтапдейтов - проведи эксперимент,
открой с десяток файлов с O_SYNC и позаписывай в них по одному в цикле
по одному байту. Посмотри на скорость. Правда прикольно? :)

С дуру и не такое можно поломать.

........
И взяли суровые сибирские мужики стальной рельс.
- вжж-трах-так-так-так, - задымилась новая японская бензопила.
- Эге, - сказали суровые сибирские мужики и пошли пить водку.

http://uafug.org.ua/projects/faq/ports.settings.make.conf/

Эх! Напрасно ты дал линк! Полезет теперь туда всякое ламерьё...

а чего это у Ukrainian FreeBSD User Group флаг ставят NetBSD'шные черти???

Нормальные люди давно уже используют portupgrade, и /usr/local/etc/pkgtools.conf вместе с ним. Там все, в принципе, понятно...

А какая разница? Главное чтобы черти были *BSD :)

ports

> как ты компилятор укажеш делая rpm -ivh *****.rpm?? :0
пассаж непонятен.
1) rpm -ihv даст ошибку (очевидно, либо имеется в виду -Uhv либо -iv)
2) rpm -i ставит готовый уже СОБРАННЫЙ пакет. Зачем здесь нужен компилятор - я не знаю.=D

99%

>> 99.99% - уже что ошибка? ;)
> А у вас это нормально?
ну, скажем так, на работе на моей машине - это нормально. ведь на 10гб /home - это не менее 1м. у меня очнеь часта такая ситуация (диск больше не дают пока), а бывает что скачешь что-нибудь большое, компиляешь на грани св. места, а тут свет моргнул.;-)
btw, UFS всё равно практически неработоспособна при заполнении fs >99%
9в силу используемых алгоритмов). Вот как про это сказано у Лукидиса в "System Performance Tuning":"The BSD filesystem's algorithm for finding free blocks becomes extremely slow as the filesystem becomes full" - проверено на опыте.:(
В сравнении с ext2 её производителность падает меньше и более линейно на участке до %75-80 где она начинает резко падать и падает почти до 0 при >99%.
ext2 ведёт себя по-другому - у неё начинается более крутое падение прозив. с 50-60% и так доходит почти до конца (когда остаётся всего несколько св. блоков). что лучше? смотря что кому надо.
BTW, ещё фраза из Лукидиса: "If you don't have an extent-based filesystem, the only way to eliminate fragmentaion is to start from scratch".

> А какая разница? Главное чтобы черти были *BSD :)

ну никто же на slackware.ru красной шапкой не размахивает!!! %)

> btw, UFS всё равно практически неработоспособна при заполнении fs >99%

btw заполнить fs до такого предела может только root. По умолчанию на ufs резервируется 8% свободного места для нужд системы, и простым смертным его юзать нельзя.

не ufs а ffs

и в NetBSD 5% по дефолту резервируется

GPL

> не ufs а ffs
изначально было "UFS" - так во многих учебникамх и книжках, в том же Лукидисе например. BTW:
The filesystem used natively in NetBSD is the Berkeley FFS. The name was changed from Unix File System (UFS) to avoid the trademarked term "Unix".

99%

> заполнить fs до такого предела может только root
давай логин на свой сервак - я тебе от обычного пользователя заполню...;-) не надо мне рассказывать где , что и как бывает - в 1997 и 1999 году во фришнике по умолчанию newfs делало 10%: я начинал работать в 2 конторах где к моменту моего прихода df зачастую показывал - (минус) на кол-во св. блоков fs (если Вы, конечно, пониаете о чём это я;). вскоре всё было OK.

>> заполнить fs до такого предела может только root >давай логин на свой сервак - я тебе от обычного пользователя заполню...;-)

Ну пароль я не дам, а вот подельться методом заполнения попрошу.

Только что для эксперимента забил диск под завязку юзером. свободно 0 и писать больше не дает. Потом закатал туда еще немного рутом. Свободное пространство ушло в минуса :)

99%

> вот подельться методом заполнения попрошу
нуу, это работа творческая, в самом общем случае - через syslog забиваем /var до 100% со всеми вытекающими. чтобы скзаать как - надо видеть систему, что стоит и т.д.
> Свободное пространство ушло в минуса
дело в том, что под 99% я понимал ВСЁ место fs, а не то, что доступно для обычных пользователей.

> df зачастую показывал - (минус) на кол-во св. блоков fs (если Вы, конечно, пониаете о чём это я;).

Ну дык правильно, то что в "минусе" - это и есть зарезервированное пространство.

>давай логин на свой сервак - я тебе от обычного пользователя заполню...;-)

ню-ню заполнятель

В 60-ом Фраке был практически работающий код для int overflow в опене.

Все-таки, green, не надо говорить о том, в чем плохо разбираешься. Прочитал письмо Ал Виро, но проследить за устранением указаных рейсов забыл.

"практически работающий код" - это стесняюсь спросить как?:)

Посмотрите статью, поймете, как.

>> как ты компилятор укажеш делая rpm -ivh *****.rpm?? :0 >пассаж непонятен. >1) rpm -ihv даст ошибку (очевидно, либо имеется в виду -Uhv либо -iv) >2) rpm -i ставит готовый уже СОБРАННЫЙ пакет. Зачем здесь нужен компилятор - я не знаю.=D

1) или то или другое :)) 2) ПРАВИЛЬНО!! Кем и чем собранный и с какими опциями компилятора??? Не легче ли его пересобрать самому откоректировав один конфиг (/etc/make.conf) и набрав make install clean??? Сам и оптимизацию поставиш и т.п.

Konokrad

>Придурь, они не _забили_, они никогда её до сего дня не использовали. Большая разница, особенно учитывая, что число FreeBSD пользователей _растёт_.

2 месяца назад я стал таким пользователем. Очень доволен, так что срать мне с высокой крыши теперь на всяких флэймеров, которые зазря ругают хорошую систему, лишь только потому что ее логотип - не пинвин. Очень обидно, что прирост пользователей *nix систем сегодня составляют в основном дуболомы, умеющие только флэймить на разных форумах почем зря. Очень неприятно видеть, когда такие люди гадят на хороший программный продукт просто из желания погадить. При этом сам продукт они не видели, а собственное мнение о нем составили, читая разные непонятные статейки в инете. Про солярис, кстати, такая же байда. Не юзали - не вякайте. Достали уже, блин.

2scum (*) (2003-07-21 11:35:41.534715)

Золотые слова :)

Прошу извинение за наглость Приходилось ли тебе работать в полной неопределенности. Так вот неопределенность сложная штука. Мне сейчас нужен MatLab для Линунс имеется ли у тебя такое. Занимаюсь разработкой систем ЦОС, первая приставка была сделана на COST- технологии на операционной системе OS-9. Сейчас как я понял важней всего технология программного обеспечения так как технология харда быстро идет вперед и польно кто знаем переходит на МультиКор.

> на всяких флэймеров, которые зазря ругают хорошую систему

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

Какая бы она хорошая ни была, она - отмирающая ветвь эволюции.

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

er, меняем сакс с рулез-ом местами.

Мораль - раз посылать уродов, то всех симметрично.

>Какая бы она хорошая ни была, она - отмирающая ветвь эволюции.

LOL и откуда такие ЕкспЕртЫ берутся только