ФС NTFS

Тогда PerfectDisk и не мучай голову. Только это не для этого форума.

Если на свежеотф-ную NTFS подряд копировать файлы, не удаляя, никакой фрагментации не будет. Порядок копирования вообще никакого значения не имеет

Если на свежеотф-ную NTFS подряд копировать файлы, не удаляя, никакой фрагментации не будет.

4.2 Венда совершенно рандомно выбирает куда кинуть файл даже на новой пустой фс.

Порядок копирования вообще никакого значения не имеет

Конечно, рандом есть рандом :D

В том и дело - винт я подключил под Ubuntu. Отформатировал его в нужную ФС. Теперь вопрос в том, как это пространство аккуратно заполнить? То, что вЕнда рандомит файлы даже на чистый раздел я давно знаю, как и тот факт, что под виндой доступно только 88% пространства (12 резервируется прод рост $MFT). Ребутать комп, чтобы сократить 12% в два раза - глупость (это сколько раз мне придётся ребутать комп, чтобы забить 99,99% свободного места ФС?). Так что под виндами - никак без фрагментации, вот и курю тему из под убунты.

Если было-бы место на моём компе - сделал бы образ диска с NTFS, смонтировал, и вопхнул в него что надо, а потом dd на раздел... Вот только нет ни места, ни времени проверять этот бред...

Мы сейчас про ntfs-3g говорим, не?

Тогда к чему ваша ремарка?

Не слушайте вумников.

1. Кхм. А что если FAT32 ? Какой функционал тебе в данном случае нужен от NTFS?
2. Если все-таки NTFS: там функция сжатия есть. Если файлы текстовые или типа того - может помочь.
3. Если никсы не рандомно разбрасывают файлы, а пишут последовательно - запиши под никсами.

1) FAT - ограничения размера файла (у меня есть много ОЧЕНЬ крупных банков БД).

2) Сжатие в NTFS - оно напрягает процессор при чтении (декодирование виртуальных байтов), плюс не знаю как этот параметр включается под никсами (да он и бесполезен к тому же).

3) Если никсы... - Так вот я и не знаю, как там себя ntfs-3g ведёт и какая у неё логика. Иначе стал-бы писать сюда?

Скопировать, потом дефрагментировать и не думать. Процесс не настолько долгий.

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

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

Так вот я и не знаю, как там себя ntfs-3g ведёт и какая у неё логика

Есть подозрение, что ntfs-3g пишет файлы последовательно: http://www.tuxera.com/community/ntfs-3g-advanced/data-compression/

ntfs-3g tries to allocated consecutive clusters to a compressed file, thus avoiding fragmentation of the storage space when files are created without overwriting

Но, надеюсь, пока ты пишешь в этот форум у тебя на фоне копируется? ;) Ну, так чтобы вермя не тратить и убедиться.

...to a compressed file...

А если не компрессить, то хоть трава не расти? (Не очень хорошо понимаю контекст).

А если не компрессить, то хоть трава не расти? (Не очень хорошо понимаю контекст).

Я тоже заметил. Но я так понял, что это просто контекст такой, глава про скомпрессированные файлы. Посуди сам - нелогично размещать скомпрессированные файлы последовательно, а не скомпрессированые как-то по-другому. Так что, я на 99% уверен что и нескомпрессированные этот драйвер размещает последовательно.

Да и проверить можно: скопируй пару файлов, запусти виндовый defrag, посмотри как расположены. Потом скопируй пару файлов под никсами и под Вендой посмотри что получилось. Кстати, отпишись сюда, аж самого заинтересовало ;)

P. S. А если все-таки рандомно, то копируешь файлы в порядке уменьшения размеров: сначала большие, потом маленькие. Если сам скриптик не сочинишь, люди здесь помогут.

Забить ФС до отказа с минимальной фрагментацией.

Зачем?

Если по фату, то имеется винт на 500 G халявы, на него нужно отправить данные (300 000 файлов), после копирования которых останется менее 2-х G свободного места, то есть задача «избежать фрагментации» выполнима на все 100%

Она будет выполнена если копировать файлы по очереди и ничего не удалять

>нелогично размещать скомпрессированные файлы последовательно, а не скомпрессированые как-то по-другому.

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

Эксперемент на рабочем месте поставить не смогу, а дома венду перестал юзать года 4 назад, в этом году снёс нехрен... Мусор... Хотя бто была моя любимая сборка хрени.

Как думаешь, на виртуалке можно так побаловаться? Или лучше ставить «чистый эксперемент»?

defrag /C /H /W

не благодари

Зачем?

К сожалению, иногда ответ на вопрос «зачем» бывает грубым. В моём случае это было слово «НАДО». И самое паршивое что оно пришло мне сверху (от начальника, непосредственно), и все мои доводы, мысли и слова были посланы по короткому адресу игнора... :-(

будет выполнена если копировать файлы по очереди и ничего не удалять

А вот тут не факт... И это предстоит проверить.

имеется винт на 500 G халявы, на него нужно отправить данные (300 000 файлов), после копирования которых останется менее 2-х G свободного места

Мольбы о покупке SSD были успешно проигнорированы.

Не хорошо шантажировать родителей таким образом, ая-яй!

Я на работе. Дома у меня 6 ТВ на сервере и пока хватает.

Оставлю копирование и пойду домой... Может там манны найдутся на эту тему.

300000 файлов со средним хвостом 2 килобайта = 600 000 килобайт = 600 мегабайт будет использовано лишнего места в хвостах кластеров. Влезет, нечего беспокоиться.

Зачем^2

А начальнику не нада там у порше каен салон переделать так, чтобы клеевых и шовных соединений небыло?

Ухмыляясь, отдаешь «этому хорошему человеку» диск с данными.
Потму что долбанько требует от тебя то, что сам производитель ФС не предусмотрел в своем поделии.

Да, находят же линуксоиды себе работенки.

Вот же делать не хрен!

tar

а если просто скопировать и все? Никто проверять же не будет.

не благодари

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

а если просто скопировать и все? Никто проверять же не будет.

будут.

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

Полностью согласен, а второе даже проверял и подтвердил. Сейчас состряпал на скорую руку машину с XP и копирую поштучно шлифуя O&O... Уж ОЧЕНЬ нужна эта дрянь и именно в таком бредовом виде. Честное слово - такое чувство, что эта идея высосона из пальца директором или кем-либо ещё. Вот ПРИПЁРЛО им. А разгребать пришлось мне...

По окончании займусь тестами и эксперементам с ntfs-3g. Потом отпишусь... Спасибо всем за помощь.

поштучно шлифуя O&O

Не знаю как нынешние версии, но версии около 8-й тормозили. Бесплатный Defraggler и то быстрее работал. Но на диске в 1.5 ТБ выяснилось, что и он тормозит. Сейчас пользуюсь auslogics disk defrag, у него пока деградации производительности на больших дисках не наблюдается.

и эксперементам с ntfs-3g

На свежем 1 ГБ диске 600 Мб свежескопированных сравнительно мелких файлов (исходники linux и ещё чего-то) оказались частично фрагментированы. Так что тут неутешительный прогноз.

Итоги

Примерно 5-7% фрагментировано. Некоторые файлы и каталоги под Win считаются «защищёнными системой» (или защищаемыми), и их невозможно переименовать/удалить или записать что-либо внутрь, если это каталог (под Linux этой проблемы нет). Единственный способ решения проблемы таких файлов - копирование под виндой с уничтожением исходного файла из-под Linux.

При заполнении файлами до 90% диска - фрагментация не сильная, но начинает расти при заполнении оставшихся 10%.