LINUX.ORG.RU

e2fsprogs 1.35


0

0

Вышло обновление набора утилит для работы с файловыми системами EXT2/EXT3. В новой версии исправлены некоторые ошибки, а также добавлена поддержка новой возможности htree для ядер серии 2.6

>>> e2fsprogs на sourceforge

anonymous

Проверено: maxcom

Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Dselect

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

anonymous
()
Ответ на: комментарий от Spherix

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

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

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

Dselect ★★★
()
Ответ на: комментарий от HellAngel

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

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

Dselect ★★★
()
Ответ на: комментарий от Dselect

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

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

HellAngel ★★
()
Ответ на: комментарий от Dselect

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

McMCC ★★★
()
Ответ на: комментарий от HellAngel

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

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

Dselect ★★★
()
Ответ на: комментарий от McMCC

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от HellAngel

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

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от Dselect

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

szh ★★★★
()
Ответ на: комментарий от Dselect

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от szh

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

UPS :)

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

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

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от Dselect

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от Dselect

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Да.

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от Dselect

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

anonymous
()
Ответ на: комментарий от szh

>одного не учел хваленый фашистский инженер 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), а метаданные еще нет, и тут резет или пауер лост, откат метаданных: второй файл потерялся, размер первого исходный, первая программа в ауте...

anonymous
()
Ответ на: комментарий от Dselect

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

не заметил я, чтоб 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

Spherix
()
Ответ на: комментарий от Spherix

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

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

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

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от McMCC

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

anonymous
()
Ответ на: комментарий от Dselect

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

anonymous
()
Ответ на: шагом марш медитировать! от Dselect

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Dselect ★★★
()
Ответ на: шагом марш медитировать! от Spherix

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

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

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

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

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 )

Dselect ★★★
()
Ответ на: комментарий от Dselect

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

jackill ★★★★★
()
Ответ на: комментарий от Dselect

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

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

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

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

jackill ★★★★★
()
Ответ на: гонки сферических коней в вакууме от Dselect

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

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

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

jackill ★★★★★
()
Ответ на: комментарий от jackill

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

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

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

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

Лопата...

Dselect ★★★
()
Ответ на: комментарий от jackill

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

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

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

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

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

Dselect ★★★
()
Ответ на: комментарий от jackill

про баги...

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

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

Dselect ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.