| 1.1, butcher (ok), 11:15, 05/05/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Note that lowering the threshold can adversely affect performance:
o Settings of 5% and less force space optimization to always be used which will greatly increase the overhead for file writes.
o The file system's ability to avoid fragmentation will be reduced when the total free space, including the reserve, drops below 15%. As free space approaches zero, throughput can degrade by up to a factor of three over the performance obtained at a 10% threshold.
Так что лучше подумать, прежде чем уменьшать.. | | |
| |
| 2.3, Dmitry U. Karoiv (?), 12:36, 06/05/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Аналогично обстоит дело в абсолютно любой разумно усироенной файловой системе, т.к. при отсутсвии запаса свободного места нет места для маневра. Впрочем, процент зарезервированного места зависит от соотношения размера раздела диска, размера файла и размера трека, причём это высшая математика с привлечением теории вероятностей...
PS: Вообще-то, алгоритмы распределения файлов должеы зависеть и от того, как система собирается работать с этими файлами - /usr надо бы дефрагментировать так, чтобы там не осталось свободного места между файлами, т.к. в конец файла там никто не дописывает. | | |
| |
| 3.4, uldus (ok), 12:41, 06/05/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Зачем на 300Гб диске запас в 24 Гб ??? Тогда размер резерва тоже интеллектуально должен выбираться. | | |
| |
| 4.6, butcher (ok), 10:16, 19/05/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Дело в том, что это свободное место резервируется не просто для нужд суперпользователя. Это место необходимо FFS для оптимального размещения файлов/каталогов, чтобы обеспечить приемлимое время доступа/поиска/чтения. Чем меньше места становится, тем хуже у FFS это получается. | | |
| |
| 5.7, uldus (ok), 10:31, 19/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Дело в том, что это свободное место резервируется не просто для нужд
>суперпользователя. Это место необходимо FFS для оптимального размещения файлов/каталогов, чтобы обеспечить
>приемлимое время доступа/поиска/чтения. Чем меньше места становится, тем хуже у FFS
>это получается.
Резервировать место через процент - это хак, зависимость между общим размером FFS и необходимым резервом не носит линейный характер. | | |
| |
| 6.8, butcher (ok), 10:46, 24/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
Это не хак, это дизайн. В исходниках вообще рекомендуется устанавливать это значение в 10%. При уменьшении до 5% и ниже FFS отключает алгоритм оптимизации выделения свободных блоков, что приводит к росту фрагментации, росту затрат дискового пространства при расположении файлов - из-за неоптимального расположения, части блоков остаются не занятыми, если файл не занимает его целиком; и, теоретически, к снижению скорости чтения. Здесь стоит подумать и выбирать между двумя золами: оставить зарезервированное пространство, либо отказываться от него и иметь возможность заюзать лишние гигабайты, и получить выше перечисленные проблемы.
| | |
|
|
|
| 3.5, Nick (??), 17:17, 08/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
Re: PS: смотря в каких ОС
иногда в /usr еще и как дописываются файлы. И свободное место между файлами никому не помешает. Или софт апдейтить не нужно?
| | |
|
|
| 1.10, ffsdmad (ok), 15:20, 14/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
tune2fs -l /dev/hda6 # Смотрим установки
tune2fs -m 2 /dev/hda2 # Меняем на 2 процента
смотри на hda6 а меняем почему то на hda2, как так?
| | |
| 1.11, NETDTHC (?), 18:25, 27/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Согласен с butcher, ведь чтобы заюзать лишние гигабайты, необходимо существенно уменьшить размер зарезервированного места под root, а это неизбежно приведет к указанным проблемам, особенно сильно это скажется на степени фрагментации диска.
| | |
| |
| 2.12, th3m3 (ok), 01:06, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
 В общем, лучше туда не лазать. Оставлять настройки по умолчанию.
| | |
|
|