а reiserfs 4 тянет?
А на слакокаке работает?

Чукча не читатель, чукча писатель?

EXT2/EXT3 не нужны.

да. виндузятникам. им вообще по правде говоря ничего кроме веника не нужно. и слишком сложно

>EXT2/EXT3 не нужны. Нужны нужны, хурд еще не дописан рейзера на него еще нету :(

R.I.P, ext[23] !

"и на обломищах гнумарча напишут наши имена"? ;)))

> R.I.P, ext[23] !

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

а что, рейсер/xfs/jfs уже в debian stable живет?

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

За тормоза -- где это видано, чтоб журналирование приводило к _снижению_ производительности!

За напрасную трату места ( меньше blocksize файлы не бывают, да еще блок для inode ).

> а что, рейсер/xfs/jfs уже в debian stable живет?

ReiserFS -- давненько, со времен релиза woody.

> За тормоза -- где это видано, чтоб журналирование приводило к _снижению_ производительности!

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

Кому рип, а кто и живет спокойно.

2Dselect: Все бы тебе давить, 8-ми битные кодировки, ext[23], а что по твоему можно оставить? Все что из альфы стадии не вышло и на продакшн страшно ставить?

> разве журналирование не должно в общем случае уменьшать производительность?

Нет, должно быть наоборот.

> Все бы тебе давить, 8-ми битные кодировки

Без всякой жалости. "На польты пойдут.... Там из их белок делать будут..."

> Все что из альфы стадии не вышло и на продакшн страшно ставить?

Это про тормозное глюкало ext3?

спорно. обоснуй!
что бы что-то в журнал записать требуются ресурсы

> спорно. обоснуй!

> что бы что-то в журнал записать требуются ресурсы

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

Конечно, метаданные все равно потом надо писать в FS, но изменить за _одну_ операцию метаданные нескольких файлов все равно выгоднее, чем затевать такую операцию ради одного файла.

Экспериментальное подтверждение: UFS с soft updates (FreeBSD), UFS с включенным logging (Solaris).

одного не учел хваленый фашистский инженер DSelect
Кроме метаданных есть еще и данные, и если есть желание держать их
в соответствии с метаданными при powerlost, то рулит ext3 с журналом в режиме ordered!!
У других журналируемых фс такого вааабще нету! либо метаdata журнал либо full data с большими тормозами...

> Только журнал не раскидан по всей FS, потому запись метаданных в него -- это гораздо быстрее

Стоп. Пусть она хоть совсем мгновенно происходит. Всё равно она
остаётся _дополнительной_ операцией. То есть производится в дополнение
к записи метаданных в FS.

> метаданные все равно потом надо писать в FS, но изменить за _одну_ операцию метаданные

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

> Экспериментальное подтверждение: UFS с soft updates (FreeBSD), UFS с включенным logging (Solaris).

Хо-хо. UFS с soft updates - это и есть глюкодром (смотри багтрек). Не
выдерживает никакого сравнения с ext3 (ordered) в плане надёжности
хранения данных. И при этом примерно равна по скорости...

UFS с включенным logging (Solaris) - а это и есть тормоз, хоть ты ей
тройной logging сделай ;) Смотри рельные бенчмарки без всяких кспериментов.

Ничего надежней чем ext3 в
Линуксе из ф.с. пока не видел

> Всё равно она остаётся _дополнительной_ операцией. То есть производится в дополнение к записи метаданных в FS.

А нафиг тогда кеширование нужно? Все равно данные потом записываются в ФС, так что это -- лишняя операция...

Рекомендую помедитировать на тему того, что происходит быстрее -- много мелких изменений, или несколько крупных...

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

Какая, нафиг, разница -- писать или изменить. Смысл в том, что не нужно каждый раз ради записи < 4kb передвигать головки с одного края диска на другой.

> UFS с включенным logging (Solaris) - а это и есть тормоз

Ню-ню. Вы Solaris хоть на картинке-то видали?

> Кроме метаданных есть еще и данные, и если есть желание держать их в соответствии с метаданными при powerlost то рулит

UPS :)

> ext3 с журналом в режиме ordered!

1) Не держит она их в соответствии. Сбой мог произойти во время записи данных, а метаданные при этом просто потеряются.

2) Именно этот идиотский режим и является основной причиной жуткой тормознутости ext3.

3) Никакое журналирование не гарантирует целостность данных.

> У других журналируемых фс такого вааабще нету!

Правильно, чай их не пЫонеры писали, а грамотные люди, которые понимают, что никакой ordered и никакое журналирование не гарантирует ни сохранности, ни непротиворечивости данных.

> А нафиг тогда кеширование нужно?

Ты чего, идиот? Данные копируются дважды. Ты сам это подтвердил. Что ты
сейчас пытаешься доказать?

> Какая, нафиг, разница -- писать или изменить.

А та разница, что писать два раза - не одно и тоже, что писать один раз.

> Вы Solaris хоть на картинке-то видали?

Имел честь наблюдать его тормоза. А как по картинке можно судить об ОС? ;)

> 1) Не держит она их в соответствии. Сбой мог произойти во время записи данных

Слушай, ясно, что ты попугай, начитавшийся разного бреда пятилетней
давности. Будет проще, если ты назовёшь первоисточник, и не будешь
работать плохим диктофоном. А мы тебе скажем, в чём он был не прав.

> Данные копируются дважды.

Да.

> Что ты сейчас пытаешься доказать?

Что произвести commit раз в N секунд и записать накопившиеся изменения -- это быстрее, чем поочередно записывать каждое изменение. > А та разница, что писать два раза - не одно и тоже, что писать один раз.

Для особо одаренных: время записи на диск не является линейной функцией объема данных, да и вообще -- не является функцией объема данных; hint: вспомните из термодинамики функции состояния vs функции процесса.

Так что идите дальше медитировать над смыслом кеширования :)

> Будет проще, если ты назовёшь первоисточник

Голова ( своя собственная ).

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

>одного не учел хваленый фашистский инженер DSelect Кроме метаданных есть еще и данные, и если есть желание держать их в соответствии с метаданными при powerlost, то рулит ext3 с журналом в режиме ordered!! У других журналируемых фс такого вааабще нету! либо метаdata журнал либо full data с большими тормозами... szh (*) (29.03.2004 23:51:04)

man mount ordered This is the default mode. All data is forced directly out to the main file system prior to its metadata being committed to the journal.

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

> Что произвести commit раз в N секунд и записать накопившиеся изменения
-- это быстрее, чем поочередно записывать каждое изменение

Это набор слов, лишённых смысла. Накопившиеся изменения сначала нужно
накопить ;) Накопление - дополнительная операция, съедающая ресурсы.
Это раз. А теперь расскажи, что такое "поочередно записывать каждое
изменение". Это как часто? Это какие объёмы? Для каких типов нагрузки
(workload). Приведи расчёт.

> время записи на диск не является линейной функцией объема данных

Строго говоря - да. Но для твоих не основанных на опытных данных
объяснений - нет. Ты доказываешь на пальцах, а пальцы твои, к несчастью,
кривые ;( Точно так же можно выдать бред, типа "время заливки дорожного
полотна асфальтом не зависит от длины дороги" ;)

> может случится так, что инфа второго файла попадет на место освобожденное первым

Не может. Кури исходники.

>> может случится так, что инфа второго файла попадет на место освобожденное первым

>Не может. Кури исходники.

все равно первый файл содержит inconsistent data

> За тормоза -- где это видано, чтоб журналирование приводило к >_снижению_ производительности!

не заметил я, чтоб ext3 тормозила.. дома у меня на мощной тачке Reiser, на работе [тачка послабее будет] EXT3.. в общем-то заметно, что ехт3 пошустрее..

вот тесты производительности различных файловых систем.. [сразу скажу, что в самой жопе, ессно, VFAT.. :) ] http:// aurora.zemris.fer.hr/filesystems/index.html

> меньше blocksize файлы не бывают

коряво ты, конечно, сказал.. :)
я согласен, но никто не заставляет тебя делать большие blocksize`ы.. и это твоё замечание относится не только к EXT3.. это нормальное поведение ФС.. в том же древнем ДОСе 512 байт были минимумом.. вычислительные мощности вырасли в тыщи раз, надёжность во столько же, теперь мы знаем, что есть что-то лучшее ДОСа, а ты пытаешься экономить на спичках.. всё равно не получится.. :)

если насчёт нескольких КБайт дискового пространства тебя душит жаба, то уменьши свой swap.. :)

в общем, на мой взгляд, пока что Reiser R.I.P.`овал.. нужно 4-ую версию попробовать..

******************************************************
а вот ликбез для самых маленьких.. :) http://www.opennet.ru/docs/RUS/fs/l-fs7_ru.html

> я согласен, но никто не заставляет тебя делать большие blocksize`ы..

4k -- это не большой blocksize, просто много мелких файлов.

> и это твоё замечание относится не только к EXT3..

Из Linux'-овых ФС -- только к ext3. ReiserFS делает tail merging, XFS хранит мелкие файлы непосредственно в inode, etc.

> если насчёт нескольких КБайт дискового пространства тебя душит жаба

За счет них набирается ~30% дискового пространства.

hint: попробуйте /usr/share скопировать на ReiserFS | XFS, почувствуйте разницу...

шагом марш медитировать!

> Накопление - дополнительная операция, съедающая ресурсы.

Опять 25. На лекции надо было ходить, да книжки умные читать...

> Точно так же можно выдать бред, типа "время заливки дорожного полотна асфальтом не зависит от длины дороги"

1) Дык если узнают, что завтра по ней поедет ВВП, зальют к утру, независимо от длины :)

2) Утверждения

а) величина F не зависит от y,

б) зависимость величины F от y не является функциональной

не эквивалентны. Если это не ясно -- шагом марш в школу, там объясняют, что такое функция.

у него еще на слово гнумарч оргазм наступает

нефик хвастаться дселект тем что ты соларис на картинке видел :)

ты про тормоза расскажи. ext3 пользовал на 166 и 100 пнях. работает быстро. тормозов нет. можут ты мозги свои разогнал и для тебя все вокруг медленно? тогда понятно почему у тебя мысли такие "перегретые" возникают на ровном месте...

> ext3 пользовал на 166 и 100 пнях. работает быстро.

Дык на убогом железе всегда рулил убогий софт. А попробуйте ее погонять хотя б на 2-way Xeon. Сразу все на свои места станет.

ну и на ксеонах юзал все быстро работало дальше что? что ты еще придумаешь?

> ну и на ксеонах юзал все быстро работало дальше что?

Быстро по сравнению с чем?

шагом марш медитировать!

ё-моё, для кого я линк на бенчмарки выкладывал?.. :(

гонки сферических коней в вакууме

> для кого я линк на бенчмарки выкладывал?

Дык тест там весьма малореалистичный. Как правило, чтение/запись идет на один раздел, причем этим одновременно занимаются несколько процессов.

Попробуйте вот это:

time dd if=/dev/zero of=test.1 bs=1M count=2048

time ( cat test.1 >/dev/null & dd if=/dev/zero of=test.2 bs=1M count=2048 )

Все хочу узнать - почему тормозное глюкалово? Не падает она.

UFS с soft updates - это несколько другое.

Писали в redhat, насколько я помню, ibm тоже руку прикладывало.

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

Ну да, не лидер скоростного забега, но последний серьезный баг в ней был в 2.4.20.

А тот же reiser до сих пор ставить страшно, хотя по тестам он очень хорош (до сих пор мечтаю, но раздел жалко).

Мда, а этот тест прямо таки пример реализма.

>Дык тест там весьма малореалистичный. Как правило, чтение/запись идет на один раздел, причем этим одновременно занимаются несколько процессов.

Разве что по ночам, часа в 4 утра.

> Мда, а этот тест прямо таки пример реализма.

До безобразия реалистичный. На диск (по NFS) пишутся данные (кусками ~ 1Gb), в это время обрабатывается предыдущий файл.

> > Как правило, чтение/запись идет на один раздел, причем этим одновременно занимаются несколько процессов.

> Разве что по ночам, часа в 4 утра.

Лопата...

про "остается целым"

> ordered хороший режим - я ничего не потерял.

Только тормозной малость, а так -- ничего.

> Да, запись во время сбоя теряется, что неудивительно, зато изменяемый файл целым остается.

Что значит "останется целым"? Я архивировал чего-то, а тут... гык. Не факт, что tar потом не ругнется на получившийся blah.tar.gz, скорее всего -- наоборот. И какое мне поможет data=ordered?

про баги...

> Ну да, не лидер скоростного забега, но последний серьезный баг в ней был в 2.4.20

Нет, в 2.4.23 была ошибка с xattr на линках. Ядро паниковало и роняло FS...