Сравнение файловых систем

> По чему она занимает первое место, малыш?

> Многопоточность, малыш

Ты педофил? Или у тебя *там* проблемы с размерами? :-) Что-то часто ты о "малышах" вспоминаешь :-)

> Еще бы bzip2 использовал. Вот с этим http://www.oberhumer.com/opensource/lzo/ потести

Не имеет смысла.

Берем простейший случай - садимся редактировать звук. Редактор создает временный файл на пару сотен мегабайт, изначально заполненый нулями (не "не дырявый" файл, а именно забитый нулями - типа "звука нет"). Замечательный алгоритм сжатия файл мне "уминает" до одного блока - типа все круто?

Щас. Я ведь сел редактировать? Вот и началось - тут я вставил самплик, в другом месте, тут понизил амплитуду, здесь поджал... И все. Пришел зверь песец - процессор старательно зажимает-разжимает файл, пытается предугадать насколько блок может расшириться... А пользователь ждет и любуется оптимизированными тормозами.

А потом пользователь говорит "а теперь пожмем-ка мы этот файлик в vorbis или aac" - и файл начинает считываться с самого начала. Вот только блоки идут не один за другим, а в порядке редактирования. А еще каждый блок надо разобрать - сколько же в нем на самом деле записано и так далле?

И нахрена такое счастье?

И даже то, что показатели у алгоритма по ссылке интересные, ничего не меняет. Потому как сжимал он эти 120 мегабайт 2 секунды. А на втором тесте команда dd if=xx of=yy bs=`expr 1024 "*" 1024` count=120 отработала за 1.5 секунды.

> Опять победа за сжатием.

Ответь только на один вопрос: сколько времени замет замена 14 байт на символы "БОБРУЙСК-РЯДОМ", начиная с позиции 32764 и по 32777 включительно, в случае податого файла, и сколько в случае несжатого :-)

Идея была в том чтобы сжимать данные на flush-е. То есть когда данные по каким либо причинам уходят из pagecache и падают на диск. В pagecache они не сжатые естественно и ничто не мешает модифицировать 14 байт не то что на БОБРУЙСК но и даже на МУХОСРАНСК :)

из сжатием общая идея которая признана правильной пока что:

время на сжатие + время на запись сжатого <= время на запись несжатого

IO более борогое чем CPU

Я допускаю что есть такая комбинация оборудования (CPU, RAM, etc) на котором это не будет работать. Ксли так - отключи сжатие и все.

>Не с Аленушкой как раз все нормально было, а вот с братцем Иванушкой... ;)
Ну да, очень приятно, когда брат - козёл :-)

> время на сжатие + время на запись сжатого <= время на запись несжатого

Неверно. Есть понятие "загрузка системы". Если я смотрю фильм с -vo x11 параллельно с копированием файла, то без сжатия я этого копирования не замечу. Со сжатием - это будет ЖОПА. Именно так, большими буквами. А ведь самый что ни на есть десктопный случай, верно?

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

>>Не с Аленушкой как раз все нормально было, а вот с братцем Иванушкой... ;) >Ну да, очень приятно, когда брат - козёл :-)

anonymous угадал мою мысль, того и гляди я тоже пить начну

:-)

> время на сжатие + время на запись сжатого <= время на запись несжатого

насколько я понимаю эту формулу, время на сжатие зависит от загрузки процессора

>Берем простейший случай - садимся редактировать звук. Редактор создает временный файл на пару сотен мегабайт, изначально заполненый нулями (не "не дырявый" файл, а именно забитый нулями - типа "звука нет"). Замечательный алгоритм сжатия файл мне "уминает" до одного блока - типа все круто?

>Щас. Я ведь сел редактировать? Вот и началось - тут я вставил самплик, в другом месте, тут понизил амплитуду, здесь поджал... И все. Пришел зверь песец - процессор старательно зажимает-разжимает файл, пытается предугадать насколько блок может расшириться... А пользователь ждет и любуется оптимизированными тормозами.

Опять мимо. Только дурной аудиоредактор редактор будет создавать файл с нулями - места не напасешся.

Возьмем Audacity (я хорошо изучил его систему пока данные восстанавливал и баг репорт писал). У него проект в xml. Каждый трек разбивается на блоки ~1mb (вроде зависит от дискретизации/битности). В xml описаны блоки для каждого трэка и их порядок следования. Тоесть если я копирую удар по барабану 30 раз, то блоки используются одни и теже.

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

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

> Можно брать среднюю загрузку системы за ближайшее время [...] Еще можно принять во внимание дисперсию загрузки системы, размер файла и тип данных(для оценки коэффициента сжатия).

А может еще и положение солнца в на небосводе, близость к чукотским шаманским бубнам, количество черных кошек в подвале президентской дачи, курс доллара на бобруской товарно-сырьево и колчество девочек на тверской учитывать? А если я сначала запустил копирование, и только потом запустил просмотр фильма? Кстати да - есди изменение количества шаманских бубнов за последнюю неделю будет по критерию Колмогорова коррелировать с количеством девочек, то можно построить кубический сплайн, от него взять опеределенный интеграл, и если значение этого определенного интеграла от -1 до текущей версии Windows превысит константу из /proc/sys/dick_nows_it, то необходимо срочно включить сжатие...

А тип данных будем опредеять по расширению, потому что hardlink'и не нужны (где ты, Irsi!), а и определять размер файла в момент его создания (для выставления на нем флажка сжимать-не сжимать) будем путем взятия логарифма по основанию из /proc/sys/the_dick_length от предыдущей величины. Кстати вопрос - AVI'шки сжимать или нет? А если в этой AVI'шке непожатые видео и звук? Встраиваем в ядро AVI demuxer! А если мы пишем TIFF? Не сжимать? А если этот TIFF непожатый и размером в 60 мегабайт? А, тогда встраиваем разборщик TIFF'а в ядро! Ну потом еще разборщик OGG'а (тоже контейнер) и анализатор GIF и PNG - они тоже бывают как пожатые, так и нет... Осталась в сущности мелочь - встроить в ядро X11, OpenOffcie и KDE. Чтобы они могли сообщать ядру без оверхеда на переключение контекста, что сжимать а что нет.

Не надо пложить сущности без необходимости. Есть нормальный способ удвоить производительности дискового I/O. Называется RAID0. Работает гарантировано.

Да, но сжатие должно использоваться когда загрузка процессора минимальна или ее вообще нет, дабы не затормаживать общую производительность.

Читая ваш пост можно подумать, что самая совершенная фс - fat32. Ведь остальные файловые системы пляшут с хитрыми бубнами типа журналирования, самотестирования хитрыми поисками в дебрях деревьев.

Если будет сжатие, то тот кому оно нужно включит его. Я привел задачи, где оно в дополнение к рейду дает хороший результат много лет (corel draw, photoshop). Понятное дело, что файловая система сама не сможет всего предугадать, но кое-что реализовать возможно.

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

>А тип данных будем опредеять по расширению, потому что hardlink'и не нужны (где ты, Irsi!), а и определять размер файла в момент его создания (для выставления на нем флажка сжимать-не сжимать) будем путем взятия логарифма по основанию из /proc/sys/the_dick_length от предыдущей величины. Кстати вопрос - AVI'шки сжимать или нет? А если в этой AVI'шке непожатые видео и звук? Встраиваем в ядро AVI demuxer! А если мы пишем TIFF? Не сжимать? А если этот TIFF непожатый и размером в 60 мегабайт? А, тогда встраиваем разборщик TIFF'а в ядро! Ну потом еще разборщик OGG'а (тоже контейнер) и анализатор GIF и PNG - они тоже бывают как пожатые, так и нет... Осталась в сущности мелочь - встроить в ядро X11, OpenOffcie и KDE. Чтобы они могли сообщать ядру без оверхеда на переключение контекста, что сжимать а что нет.

Покажи мне не пожатый PNG ;) Можно построить сжатие на конкурентной основе: если i/o загружен на 100%, то повышаем степень сжатия. Если проц сильно загружен, то работаем без сжатия или понижаем его степень. А вообще на эту тему много можно придумать - сжимать вовремя простоя компьютера. Или делать предсказание коэффициента сжатия, как rar.

Кстати, а идея не плохая насчет анализатора. Займет он очень мало - так как будет использовать стандартные библиотеки, главное что бы скорость считывания заголовков файлов была большой. И что-то смутно припоминаю, может даже в планах Рейзера читал или другой фс - определение типа файла и оптимальная его обработка самой фс. То есть к примеру жать только не сжатый заголовок.

>А может еще и положение солнца в на небосводе, близость к чукотским шаманским...

Зачем кидаться в крайности? Если брать данные хотя бы раз 10 за 20сек, то много времени это не займет. И взял я это только ради того чтобы вам было удобно смотреть свои фильмы.

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

По-моему явно видно, что чем быстрее процессор и медленнее i/o, то тем больше сжатие себя оправдывает.

> Ведь остальные файловые системы пляшут с хитрыми бубнами типа журналирования, самотестирования хитрыми поисками в дебрях деревьев

Узнаю гуманитария. Журналирование и самотестирование - это способы обеспечения устойчивости к сбоям, которая является необходимым требованием для любой ФС. А деревья - это самый эффективный алгоритм поиска - быстрее только хэш. Вдобавок ко всему, деревья на файловой системе достаточно редко балансируются, в основном потому, что имена достаточно равномерно разбросаны по алфавиту в подавляющем большинстве случаев, да и перебалансировка дерева - операция хотя и требовательная к процесоору, но весьма редкая.

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

> Зачем кидаться в крайности? Если брать данные хотя бы раз 10 за 20сек

Объясняю - я СНАЧАЛА запустил копирование, на незанятой системе (и по вашему алгоритму оно начало "сжиамть"), и только затем запустил просмотр фильма. Десктопная задача. Последовательность действий вполне нормальная, но _приципиально_ непредсказуемая. Зато тормоза гарантированы.

> Опять же коэффициент можно использовать и усредненный

Какой нафиг "коэффициент" - вы сами хоть поняли о чем говорите? Вы должны на этапе _создания_ файла определить будет он сжатым или нет. И даже если вы сможете на десятом мегабайте понять что файл не жмется - вы уже ничего не сможете исправить - файл был создан как "сжатый". Все, приехали. Тот же самый образ DVD - он же в начале (где идут данные ISO9660) замечательно жмется. Вот только когда начинается поток видео и звука, наступает задница.

Вы не видите задачи в целом, и пытаетесь экстраполировать свой опыт работы с тормозной NTFS на другую систему. Понимаете, на медленной NTFS с кривым кэшом вы может и получаете получите выигрыш. На нормальных системах с мощным VFS вы этого выигрыша не получите. У меня далеко не самый новый диск (Maxtor IDE 120GB), но создание 100-мегабайтного файла занимает полсекунды. Вместе с sync'ом - 2 секунды. Чтение такого же файла с диска - 2 секунды. Даже предложеный кем-то LZO справится с таким потоком только на 100% использовании процессора.

>Вы же пытаетиесь пропихнуть нововведение, не только очень неэффективно реализуемое, но и крайне сомнительное с точки зрения эффективности .

Во многих ситуациях узким местом является i/o, а не процессор. Сжатие позволяет сократить кол-во обращений к i/o. Остается только учесть все нюансы и создать хорошую реализацию. Почему по вашему это крайне сомнительно? Ведь никто не запрещает учитывать текущую нагрузку на проц. Тем более, что во всех сложных ситуациях для сжатия его можно отключать и использовать только там, где это оправдано.

>Вы должны на этапе _создания_ файла определить будет он сжатым или нет. И даже если вы сможете на десятом мегабайте понять что файл не жмется - вы уже ничего не сможете исправить - файл был создан как "сжатый". Все, приехали. Тот же самый образ DVD - он же в начале (где идут данные ISO9660) замечательно жмется. Вот только когда начинается поток видео и звука, наступает задница.

И что мешает реализовать отключение/включение сжатия и смену алгоритма отдельно для каждого сектора?

>Вы не видите задачи в целом, и пытаетесь экстраполировать свой опыт работы с тормозной NTFS на другую систему. Понимаете, на медленной NTFS с кривым кэшом вы может и получаете получите выигрыш. На нормальных системах с мощным VFS вы этого выигрыша не получите. У меня далеко не самый новый диск (Maxtor IDE 120GB), но создание 100-мегабайтного файла занимает полсекунды. Вместе с sync'ом - 2 секунды. Чтение такого же файла с диска - 2 секунды. Даже предложеный кем-то LZO справится с таким потоком только на 100% использовании процессора.

Даже на ext3 c lzo я получил прирост и это без оптимизации файловой системы под сжатие.

На любой другой фс будет тот же эффект. Кстати загрузка проца на сжатии была ~44% на моем конфиге, которы я уже оглашал.

>Объясняю - я СНАЧАЛА запустил копирование, на незанятой системе (и по вашему алгоритму оно начало "сжиамть"), и только затем запустил просмотр фильма. Десктопная задача. Последовательность действий вполне нормальная, но _приципиально_ непредсказуемая. Зато тормоза гарантированы.

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

>Какой нафиг "коэффициент"...

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

Слушай, а сжатие у модема ты отключить не забыл? А то вдруг png, jpg, gif, zip или не дай Бог bz2 попадется? ;)

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

Ок. Компилятор тебе в пальцы и вперед. В настоящий момент технические специалисты, занимающиеся разработкой ядра, считают, что это не нужно (и небезосновательно считают).

> Но если есть явное смещение в сторону первого, то это может быть неплохой компенсацией.

Да сколько раз говорить - это НЕ БУДЕТ компенсацией. Десктопная задача. Домашняя бухгалтерия. Данные - в DBF'ке, сжимаемость данных - чуть не 60%. Вопрос сжимать файлы или нет? Принимается только ответ "да" или "нет".

> Слушай, а сжатие у модема ты отключить не забыл?

У меня внешний модем :-)

> Кстати загрузка проца на сжатии была ~44% на моем конфиге, которы я уже оглашал

Ты опять за свое? Ладно, живое сравнение - сначала твой "тест"

> time lzopack test.tmp test1.lzo
> lzopack: compressed 734003200 into 519447542 bytes
> real 0m55.237s
> user 0m18.105s
> sys 0m6.048s

Теперь боевой тест на нормальной системе:

$ time { dd if=/opt/dist/fc2/fc2cd1.iso of=yyy bs=`expr 1024 "*" 1024` count=700 ; sync ; }
636+1 records in
636+1 records out
real 0m31.256s
user 0m0.012s
sys 0m4.904s

Видишь ли, ты прочел, пожал и записал в своем тесте данные за 55 секунд. Я без сжатия прочел и записал 636 метров за 31 секунду. Те же 700 метров отработаются менее чем за за 35 секунд. ГДЕ выигрыш от сжатия?! Ладно, хрен с ней, с медленной записью! Тестируем чтение?

Вот твой результат:

> time lzopack -d test1.lzo /dev/null
> lzopack: decompressed 519447542 into 734003200 bytes
> real 0m15.976s
> user 0m2.028s
> sys 0m1.956s

$ time dd if=/opt/dist/fc2/fc2cd1.iso of=/dev/null bs=`expr 1024 "*" 1024`
636+1 records in
636+1 records out

real 0m11.255s
user 0m0.004s
sys 0m2.168s

Блин, ну опять "сжатие" в аутсайдерах. Самое забавное, что у тебя Athlon 2100 - насколько помню, по рейтингам это "3000+" будет (я тебя по IP посчитал :-)). У меня Sempron 2000 - это 166x12, по "рейтингам" 2800+. Твоя более быстрая машина оказалась в аутсайдерах. И после этого ты будешь заливать про "эффективность" сжатия?

P.S.: ах да - я еще вместо dd с bs=1024k погонял c bs=4k и просто делал cp. Везде и всегда с теми же результатми +-5%. Так что уж извини - циферки врать не умеют.

>время на сжатие + время на запись сжатого <= время на запись несжатого IO более борогое чем CPU

Эй, разве мы не упустили кое-что. Ведь если на выходе 2 файла 500Мб и 700Мб и быстрее был записан 2й, то и ежу понятно что в первом варианте io был загружен не полностью. В итоге за что боролись, на то и напоролись. Если процессор жмет данные быстрее чем io их пишет, то нельзя ли к примеру жать их блоками и отдавать в io очередной блок еще до того как запишется старый, те бороться с простоями?

>Да сколько раз говорить - это НЕ БУДЕТ компенсацией. Десктопная задача. Домашняя бухгалтерия. Данные - в DBF'ке, сжимаемость данных - чуть не 60%. Вопрос сжимать файлы или нет? Принимается только ответ "да" или "нет".

Ну хорошо, да. Вы ведь явно хотите чтобы я так ответил, тогда посмотрим что вы уготовили.

PS: Запустил вместе lzop(даже 2) и mplayer. Подскажите где я должен искать вашу большую ЖОПУ(т.е. ту о которой вы говорили)? Даже 2 lzopa выше чем на 50% процессор не грузили.

> Ну хорошо, да. Вы ведь явно хотите чтобы я так ответил

Почему же? Я просто ожидаю объективного ответа, согласующегося с вашей "теорией". Ну так как - жмем DBF-ку или нет?

> Эй, разве мы не упустили кое-что. Ведь если на выходе 2 файла 500Мб и 700Мб и быстрее был записан 2й

Нет, не упустили. Мы просто получили итог - полезный I/O без сжатия выше чем со сжатием, и только. Не важен процент загрузки I/O - важна _полезная_ пропускная способность: 700МБ за минуту (11.5 МБ/сек) со сжатием против 700МБ за 35 секунд (20МБ/сек) без сжатия. Это называется "чистая победа в итоговой производительности".

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

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

Может у меня карма такая - ext3 меня "не любит"?:) В то же время, искренне верю знакомым, у которых ext3 отлично работает, у самого на серверах ext3 - нареканий нет (но там и работа FS кардинально отличается от таковой на рабочих станциях и ноутах, и от FS по скорости мало что зависит, и железо на порядок дороже:)). Слышал и жалобы на reiser: в большинстве случаев рекомендовал проверить винт (тем же MHDD) - в большинстве случаев я оказывался прав :(

Несмотря на всё вышесказанное, не берусь навязывать reiser и кричать "ext3 - отстой", и вам, уважаемый log1n, не рекомендую - выглядит это по-детски.

Примерно годика 2 перебирал варианты ФС под свои нужды (примерно 1 Тб на предприятии) изменяющихся файлов/каталогов. XFS - самое оно. Выигрыш особенно видно на больших обьёмах.

Читать умеем?

>time lzopack test.tmp test1.lzo lzopack: compressed 734003200 into 519447542 bytes real 0m55.237s user 0m18.105s sys 0m6.048s

>time cp test.tmp test2.tmp real 1m4.631s user 0m0.048s sys 0m9.005s

С сжатием на моей машине было 55 сек, без сжатия 65 сек. Чтение с сжатием 15 сек, без сжатия 20 сек.

Почему у тебя было быстрее не знаю, скорее всего условия разные. Раздел ext3, 50Gb, находится ближе к концу винта. Фрагментацию не смотрел, но она приличная - разделу несколько лет.

Скомпиль lzo и огласи свои результаты.

И коких размеров dbf на десктопе? Сжатие интересно только для больших файловых операций. На файлах 200mb и более, когда физически i/o не позволяет загрузить файл в 5 sec и человеку приходиться ждать.

P.S. почитай стандарты модемов типа v42bis v44, узнаешь много полезного. Без шуток.

А как это у тебя чтение ~58mb/s получилось и притом на файловой системе, которая в любом случае не позволяет достигнуть физической скорости чтения винта? Не из кэша ли данные?

hdparm -t /dev/hda в студию!

Скорость раздела, на котором я тест проводил.

/dev/hda10:

Timing buffered disk reads: 158 MB in 3.01 seconds = 52.52 MB/sec

Отсюда 52,5mb/s физическая скорость, скорость чтения с ext3 46,6 mb/s.

>скорость чтения с ext3 46,6 mb/s. Не то написал. Скорость чтения с ext3 46,6 mb/s с сжатием, без сжатия 35mb/s.

> Почему у тебя было быстрее не знаю, скорее всего условия разные.

Прогоняем два теста - данные берутся с реального hda, бросаются в
fifo, затем из fifo разгребаются пишущей программой (dd либо lzop).
Объем данных одинаковый, 700MB.

Тест 1, потоковая запись - используем сжатие:

$ time { lzop -c <ll >xxx ; sync ; }

real    0m31.160s
user    0m11.105s
sys     0m1.068s

Тест 1, потоковая запись, не используем сжатие

$ time { dd if=ll of=xxx bs=1024k ; sync ; }
700+0 records in
700+0 records out

real    0m27.892s
user    0m0.004s
sys     0m2.492s

Упс? Без сжатия пишет чуть-чуть, но быстрее.
Спишем на dd с размером блока? Легко! Прогоним на простом cp:

$ time { cp ll yyy ; sync ; }

real    0m29.674s
user    0m0.092s
sys     0m1.836s

Да пофиг, все равно быстрее. На user time внимание обратили?
Думаю, 11 секунд в случае сжатия и менее 0.1 в случае без сжатия
говорят за себя - без сжатия я еще и пару mp3-шек за это время
сожму. А со сжатием - вряд ли.

Тест 2 - чтение. Со сжатием:

$ time { lzop -dc <xxx >/dev/null; }

real    0m6.022s
user    0m4.136s
sys     0m0.568s

Использование CPU 60%, время на I/O полторы секунды, объем файла:

$ ls -l xxx 
-rw-rw-r--  1 dalth dalth 256212503 Янв 10 12:01 xxx

Без сжатия:

$ time { dd of=/dev/null if=xxx bs=1024k ; }
700+0 records in
700+0 records out

real    0m4.464s
user    0m0.000s
sys     0m1.144s

Больно красивые цифры, не находите? Проверим-ка мы их... Время
wait'ов 4.3 секунды. Скорость "реального" I/O = 700 / 4.3 = 162MБ/сек.
Уже слышу ващ радостный крик "ага - это кэш!!!".

Согласен. Вот только посмотрим на тест со сжатием под лупой:
6 секунд всего, из них 4 в юзерспейсе. Значит, скорость
"реального" I/O = 256 / (6.0 - 4.1 - 0.5) = 182MБ/сек?!

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

А что нам скажет hdparm?

# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads:  166 MB in  3.01 seconds =  55.11 MB/sec

Какая файловая система? XFS. Линейная скорость чтения?

$ time dd if=/home/ftp/pub/linux/fedora/4/fc4d3.iso of=/dev/null bs=1024k count=500
real    0m10.119s

Почти 50 мегабайт в секунду - вполне себе нормально.

В реальной ситуации сохранения результатов работы приложением кэш участвовать не будет. Для более-меннее правильного тестирования нужно минимизировать влияние кэша запуском hdparm -t /dev/hda перед каждым замером. А то получаются замеры как в статье с которой все началось. Ведь не секрет, что xfs очень хорошо подходит для работы с большими файлами, а по статье можно утверждать обратное.

Или для вас типичная ситуация размножение одного большого файла по всему винту? ;)

> Для более-меннее правильного тестирования нужно минимизировать влияние кэша запуском hdparm -t /dev/hda перед каждым замером

Вы хотите чтобы я умер от смеха? В тесте срабатывает не кэш винта, который и перебился бы при hdparm -t, ибо он хорошо если 8 мегабайт, а то и вообще 2!

В тесте работает кэш VFS - то есть оперативная память, незадействованная на данный момент, а ее МНОГО - на машинке 1GB, и даже firefox, xorg, bind, sendmail, samba, dovecot ftpd, gnome и vmware ее не выбирают.

P.S.: так я от вас по-прежнему жду объективного ответа насчет DBF'ки :-)

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

Как раз и будет. Вы пишете в ФАЙЛ. И если вы не приложите страшных усилий, эта операция пройдет через кэш. Как и при чтении - система устраивает в помощь вам небольшой read-ahead, сохраняя в ОЗУ прочитанные данные для возможного последующего использования.

Вследствие этого, например, первая команда cp для 100МБ файла пройдет за 2-2.5 секунды, а повторная - одну десятую секунды (читать-то уже не надо - вот оно все, в памяти), а при записи данные сначала укладываются в кэш, и уже в фоновом режиме пишутся на диск - то есть на 512-метровой машинке 100-мегабайтный файл почти гарантировано ложится в память. А на машинке с гигабайтом памти в кэш сразу влетает 300..400 мегабайт, а то и больше.

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

Мля, hdparm -t /dev/hda перед тестом забивает системный кэш. Вы меня за идиота держите - как может повлиять кэш в 2-8mb на hdd при файлах в 700mb? Конечно речь о кэше системы.

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

Памяти по любому не хватает, даже при работе с одним емким приложением - gimp или photoshop. У них темпы по несколько гигов бывают и не редко, особенно когда файл под печать готовишь.

> Мля, hdparm -t /dev/hda перед тестом забивает системный кэш

Второй и последний раз говорю - hdparm не забивает системного кэша:

# time dd if=/home/ftp/pub/linux/fedora/4/fc4d2.iso of=/dev/null bs=1024k count=300
300+0 records in
300+0 records out

real    0m1.237s
user    0m0.000s
sys     0m0.480s
# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:  166 MB in  3.00 seconds =  55.33 MB/sec

# time dd if=/home/ftp/pub/linux/fedora/4/fc4d2.iso of=/dev/null bs=1024k count=300
300+0 records in
300+0 records out

real    0m0.623s
user    0m0.000s
sys     0m0.476s

> Вы меня за идиота держите

Теперь да.

Ладно не полностью он его забивает, только часть, наверное столько сколько успел считать за три секунды.

time dd if=OOo_1.1.3_ru_RU_LinuxIntel_install.tar.gz of=/dev/null

real 0m2.484s user 0m0.040s sys 0m0.388s

time dd if=OOo_1.1.3_ru_RU_LinuxIntel_install.tar.gz of=/dev/null

real 0m0.364s user 0m0.044s sys 0m0.320s

hdparm -t /dev/hda

time dd if=OOo_1.1.3_ru_RU_LinuxIntel_install.tar.gz of=/dev/null

real 0m0.828s user 0m0.024s sys 0m0.372s

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

>а при записи данные сначала укладываются в кэш

Это кем они в кэш укладываются?

> Памяти по любому не хватает, даже при работе с одним емким приложением - gimp или photoshop. У них темпы по несколько гигов бывают и не редко, особенно когда файл под печать готовишь.

Только не говорите нам, что вы все это делаете на машине со 128МБ оперативки, ладно?

Берем не самую большую картинку - ну скажем 8000x8000 пикселов. Накладываем на нее не самый сложный эффект (ну например какой-нибудь blur), и в процессе наблюдаем за поведением системы. Так вот процессор используется на 90%, а система шуршит диском с интенсивностью 3-4 мегабайта в секунду, то есть I/O не вычерпан даже близко - и вы хотите у несчастного процессора на сжатие отобрать у него еще треть?

То же самое при сохранении картинки, например, в пожатый TIFF - 80% времени - это "user". Откусить еще треть под бесполезное сжатие?

> >а при записи данные сначала укладываются в кэш

> Это кем они в кэш укладываются?

Ядром:

time { dd if=/dev/zero of=xxx bs=2048k count=350; }
350+0 records in
350+0 records out
real    0m11.758s

Итого 63МБ/секунду - это явно больше hdparm'овских 55, не так ли?
Да и по gkrellm видно, что после окончания работы dd данные
продолжают лететь на диск еще несколько секунд.

Скорость это еще не все, на reiser проблемы совсем дурацкие есть. Вот на xfs у меня есть файл с таким названием: annie lennox - no more "i love you's".ogg на reiserfs 3.6 такой создать не получится.

touch annie\ lennox\ -\ no\ more\ \"i\ love\ you\'s\".ogg touch: установка временных отметок `annie lennox - no more "i love you\'s".ogg': Нет такого файла или каталога

Заметил как-то при переносе, после чего казнил reiserfs на том разделе.

> Скорость это еще не все, на reiser проблемы совсем дурацкие есть.

Я ничего не имею против reiserfs, но также не вижу серьезных преимуществ - ну не удаляю я каталоги с 10000 файлов :-) У меня вообще таких нет :-)

Так что пока - XFS на рабочей станции (если за полгода проблем не возникнет, сочту ее стабильной и пригодной для сервера :-)) и ext2/3 на сервере.

>Нет, не упустили. Мы просто получили итог - полезный I/O без сжатия выше чем со сжатием, и только. Не важен процент загрузки I/O - важна _полезная_ пропускная способность: 700МБ за минуту (11.5 МБ/сек) со сжатием против 700МБ за 35 секунд (20МБ/сек) без сжатия. Это называется "чистая победа в итоговой производительности".

Нет, я не понимаю. Объясните мне какая связь между io и сжатием. io - это работа hdd, а сжатие - процессора. Почему hdd и процессор не могут делать работу одновременно, тем более если процессор справится со своей задачей раньше?

lzop ничего не порождает, значит скорее всего работает в один процесс так: скопировать кусок, сжать кусок, записать кусок. Ведь прога сделана в первую очередь для сжатия. Почему нельзя сделать 2 нити, одна будет заниматься только io, а другая только сжатием. В результате считав первые 5Мб нить приступит к копрированию следующих 5Мб, а другая успеет эти 5Мб и отдать уже пожатые еще до того как первая успеет считать следующие 5Мб и тд. Что не так?

Я до определенного момента тоже против reiserfs ничего не имел :) Когда я после ext3 впервые попробовал reiserfs - порадовался скорости копирования каталога /dev. На системном разделе (не важно рабочая станция или сервер) ее вполне можно ставить, но вот на разделе с данными мне нужно чтобы файлы с названиями extreme - god isn't dead?.ogg создавались без проблем, xfs же умеет.