|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Bormotov 2:5020/400 19 May 2003 23:49:07 To : Sultan Azhiguzhayev Subject : Re: defrag --------------------------------------------------------------------------------
Hi, Sultan!
>>>>> "SA" == Sultan Azhiguzhayev <Sultan.Azhiguzhayev@f84.n5083.z2.fidonet.org>
>>>>> writes:
[skip]
VB>> Ты поинмаешь, что запись файла будет происходить бустрее, если его
VB>> будет писать в ближайший к головкам сектор, а не в конце файла, да?
SA> а если там мало места, а ближайший свободный кусок находится фиг знает
SA> где?
вывод 1 - держим на винте место "с запасом".
VB>> А где у нас в произвольный моент времени головки? Учитывая что
VB>> всякие syslog'и пишут логи, cron'ы выполняют задания, почтовки
VB>> принимают почту, и ваще свапер вытесняет ненужные страницы памяти на
VB>> диск.
VB>> Ту-же логику примени к чтению.
SA> кэш чтения/записи? по-моему, неплохо было бы если б вещи делались
SA> разумно.
мысль 1 - кешатор дисков на линуксе вполне разумный. Иногда даже слишком
разумный :))
VB>>>> Допустим у меня пять разделов, с ext3/reiser/xfs,
VB>>>> на которых фрагментация составляет от 1% до 5%.
SA>>> ну это пока... но "энтропия системы постоянно растет и весь мир
SA>>> погибнет..." :)
VB>> в моеё вселенной я не видел фрагментации ext2 более чем 5%.
SA> чем оценивал? :)
при кадом монтировании по загрузке системы пишут.
SA> таки интересует проблемка? :)
У меня интерес к файловым системам еще с момента перехода на HPFS, а потом
на HPFS386, у которой по мимо более грамотного кешатора (в сравнении с
hpfs) еще и статистика выдавалась какая-никакая (по поаданиям в кеш), и
возможности "более тонкой настройки" были. С тех пор интерес поугас (мне
теперь дешевле необходимую производительность получить экстенсивным
путем), но за некотоыре цифры "глаз цепляется".
[skip]
SA>>> восстановление производительности операций чтения/записи.
VB>> еще раз - зависимость производительности от дефрагментации в студию.
SA> скопируй пару фильмов на сильнофрагментированную fs и на
SA> свежемороженную. да и субиде всякие при фрагментации (у них слава
SA> богу свои средства борьбы есть) несколько "проседают"
возвращаемся к "вывод 1" и твоему вопросу в предыдущем письме - да, у меня
на диске почти всегда есть свободного места столько, чтоб туда легко влез
"средний мой файл".
В итоге, драйвер fs может более оптимально записать данные, с учетом того,
что их будут читать, а кешатор диска, позволяет реальной записи на диск
происхдить еще более оптимально, переставляя в очереди запросов на запись
блоки так, чтоб уменьшить количество long seek.
Т.е. за мои годы использования linux и ext2/3, у меня не возникало мысли о
том, чтоб увеличивать поизводительность дисковой подсистемы путем
дефрагментации файловых систем.
Даже на OS/2 я запускал дефрагментатор "чисто по приколу". Кроме того,
насколько я помню всякие статейки про hpfs, там говорилось что файл
лежащий в двух-трех экстентах в среднем читается быстрее, чем тот, который
лежит одним куском. Аргументов не помню, но были они весьма убедительны :))
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/25416c9efe6b.html, оценка из 5, голосов 10
|