LINUX.ORG.RU

История изменений

Исправление frame, (текущая версия) :

В который раз повторюсь: это счётчик фрагментированных файлов, т.е. фрагментирован может быть только 1 файл и оно будет тешить вас 0.01% non-contiguous, но побит он будет на 10000+ частей - и тут уже никакое самовнушение не поможет против тормозов. Правильнее сравнивать общее число файлов с числом фрагментов. Что же до баек про «SSD всё равно»: в ext4, напомню, екстентная запись, т.е. при отсутствии фрагментации - это сильно экономит метаданные, а вот в противном случае (если взять наихудший вариант, к примеру) - требует _в разы_ больше метаданных (читай - больше операций чтения/записи, меньше полезного места) /thread

Исправление frame, :

В который раз повторюсь: это счётчик фрагментированных файлов, т.е. фрагментирован может быть только 1 файл и оно будет тешить вас 0.01% non-contiguous, но побит он будет на 10000+ частей - и тут уже никакое самовнушение не поможет против тормозов. Правильнее сравнивать общее число файлов с числом фрагментов. Что же до баек про «SSD всё равно»: в ext4, напомню, екстентная запись, т.е. при отсутствии фрагментации - это сильно экономит метаданные, а вот в противном случае (если взять наихужший вариант, к примеру) - требует _в разы_ больше метаданных (читай - больше операций чтения/записи, меньше полезного места) /thread

Исходная версия frame, :

В который раз поврорюсь: это счётчик фрагментированных файлов, т.е. фрагментирован может быть только 1 файл и оно будет тешить вас 0.01% non-contiguous, но побит он будет на 10000+ частей - и тут уже никакое самовнушение не поможет против тормозов. Правильнее сравнивать общее число файлов с числом фрагментов. Что же до баек про «SSD всё равно»: в ext4, напомню, екстентная запись, т.е. при отсутствии фрагментации - это сильно экономит метаданные, а вот в противном случае (если взять наихужший вариант, к примеру) - требует _в разы_ больше метаданных (читай - больше операций чтения/записи, меньше полезного места) /thread