Легенды и мифы ext4

А как сильно влияет на скорость копирования эта опция?

Предвижу большую тему ФСсрача...

О! Бирди!

А на SSD на фрагментацию пофигу

запустил e2fsck для просмотра фрагментации - о Боже:

2341 non-contiguous files (19.8%)

А тесты, тесты где?

Снова к мифу об отсутствии фрагментации на линукс FS'es

ТС, этот миф покрылся мхом 100500 лет назад, как, собственно, и ты сам :)

Учитывая, что скоро мы поголовно перейдем на SSD, о фрагментации можно в принципе не беспокоится.

Вопрос из зала: насколько сильно эти 20% повлияли на производительность?

ладно, будем использовать. нужно как-то особо включать в мс?

А что, недостатки SSD уже преодолели?

Нет, они все еще дорого стоят.

Не недостатки, а недостаток. Большая цена за гигабайт.

А что с ограниченным числом циклов перезаписи?

Устарело так же, как и сабжевый миф.

размером от 300 байт до 600MB, средний размер файла 30MB
2341 non-contiguous files

Если файл в 32 метра развалится на два куска по 16, то что от этого изменится в плане скорости?

Знать бы, что на 2, а не на 32 куска, а то и более.

Думаешь, ext4 писали разработчкики btrfs?

Озвучьте, какие именно недостатки вы имеет в виду.

Цена и ограниченное количество циклов перезаписи.
Второе видимо исправлено.

SandForce

они все еще дорого стоят.

Они дешевеют: 2,5-дюймовые 960GB Crucial M500 SSD будут стоить меньше $600.

Всё равно дороговато. Баксов 350-400 - уже нормально.

А для btrfs есть точные данные по кол-ву кусков?

Preallocate space ээ, как его использовать то?

О, вспомнил, что когда-то давно читал, дефрагментатора нет, т.к. не нужен. Не в смысле, что происходит чудо, а в смысле, что просто взял mv туда, потом обратно и всё. Выходит, что и этот факт оказывается мифом. Вот этого не ожидал.

они дешевеют

Слишком медленно. К тому времени как они нормально подешевеют, уже эра облачных хранилищ наступит. Системы будем грузить прямо с серверов Canonial, приложения тоже будем запускать напрямую с их серверов, хомяк будет храниться тоже там, в one.ubuntu.com.

Пусть дальше дешевеют. Надеюсь, что в следующем моем ссд цена за гигабайт будет стоить вменяемых денег.

Ну и щикарно, а мы будем пользоваться локальными SSD.

Ага, так в coreutils уже было направлено предложение. Только что-то результата не видно.

Второе видимо исправлено.

Нет, современные mlc ячейки обладают в разы меньшим ресурсом, чем предыдущие поколения. Удешевление за счёт этого и идёт. Другое дело что проблема изначально существовала практически эксклюзивно в головах анонимных аналитиков.

Нет, современные mlc ячейки обладают в разы меньшим ресурсом, чем предыдущие поколения. Удешевление за счёт этого и идёт. Другое дело что проблема изначально существовала практически эксклюзивно в головах анонимных аналитиков.

Я для своего SSD прикидывал, что при моей интенсивности использования он исчерпает гарантированный ресурс перезаписи через 45 лет. При этом статистически я умру раньше. :) Ну а перестраховщики пусть продолжают бояцца и ждать.

Я для своего SSD прикидывал, что при моей интенсивности использования он исчерпает гарантированный ресурс перезаписи через 45 лет.

С ext4 прикидывать вообще стало проще пареной репы: tune2fs сообщает время создания фс и объём записи на неё. Правда умножить/поделить для многих задача непосильная, что подтверждается стабильным потоком тем и сообщений на тему «ssd-капец».

Файлы копировались подряд, одной программой

любопытно. Интересно чем можно объяснить фрагментацию. По-идее, даже если файлы зависли в кэше для них всё равно выделяется блок на диске. Я бы грешил именно на этот механизм.

Знать бы, что на 2, а не на 32 куска, а то и более.

Я как-то написал небольшую утилиту. По идее под linux'ом может работать с любой ФС. Достоверность результата не гарантирую 8).

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

shake пробовал, работает. На глаз никакой разницы не заметил.

спользуйте Preallocate space в Midnight Commander (кроме vfat и ntfs-3g - там оно как-то странно работает).

А как оно будет работать, если целевой файл уже существует, но имеет меньший / больший размер? Не ухудшит ли это ситуацию?

4.2, он есть и давно.

когда-то давно читал, дефрагментатора нет

4.2, он есть и давно.

«давно» - понятие относительное.

В этой теме не хватает KRoN73 и i-rinat

«давно» - понятие относительное.

https://savannah.nongnu.org/projects/shake

2006 это да, недавно совсем.

2006 это да, недавно совсем.

Я о 2001..2003 говорил, когда начал пересаживаться, и одним из первых сюрпризов было отсутствие дефрагментатора, а ж.д. ох как головками стучали-скрежетали.

Я о 2001..2003 говорил, когда начал пересаживаться, и одним из первых сюрпризов было отсутствие дефрагментатора, а ж.д. ох как головками стучали-скрежетали.

Ужас какой :)

Я как-то написал небольшую утилиту. По идее под linux'ом может работать с любой ФС.

Кстати, filefrag -v тоже показывает положения и размеры блоков. Но у тебя форматирование лучше. Когда есть только FIBMAP, вывод filefrag тяжело читать.

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