дефрагментация файла

← →
mem (2010-11-24 16:13) [0]

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

← →
Юрий Зотов © (2010-11-24 19:15) [1]

Если на диске НЕТ свободного куска нужного размера, то записать файл без его фрагментации не получится никак.

А если на диске ЕСТЬ свободный кусок нужного размера, то система сама запишет файл без его фрагментации.

← →
Юрий Зотов © (2010-11-24 19:24) [2]

С учетом размера кластера, конечно. Если он меньше размера файла, то файл в любом случае будет разбит по кластерам, но фрагментацией это не считается.

← →
DiamondShark © (2010-11-24 19:31) [3]

> mem (24.11.10 16:13)

А вы с какой целью интересуетесь?

Я почему уточняю? Это уже верный признак: если человек хочет странного, то с вероятностью 93,14159% он пытается решить НЕ ТУ задачу, которую требуется решить на самом деле.

← →
mem (2010-11-24 21:06) [4]

> DiamondShark © (24.11.10 19:31) [3]

> А вы с какой целью интересуетесь?

Делаю индексный файл для поиска. Данные тоже в нем лежать будут, вот, чтобы ускорить перемещение и считывание и нужен последовательно записанный файл.
Средства СУБД мне не подходят.

> если человек хочет странного

Желание ускорить дисковые операции - странное? хм...

> Юрий Зотов © (24.11.10 19:15) [1]
>
> Если на диске НЕТ свободного куска нужного размера, то записать
> файл без его фрагментации не получится никак.
>
> А если на диске ЕСТЬ свободный кусок нужного размера, то
> система сама запишет файл без его фрагментации.

сначала я загоняю в него данные из БД - набор записей. Потом создаю и записываю в него же несколько индексов. Заранее его размер мне неизвестен, да даже если и известен(установлю сразу с запасом), то ведь CreateFile после возвращения дескриптора уже записала файл размером 0 в определенное место, так? Т.е. с очень большой вероятностью файл будет дефрагментирован, даже при наличии нужного куска. Если я конечно правильно понимаю, как виндовз записывает файлы... Прошу поправить, если ошибаюсь с CreateFile.

← →
mem (2010-11-24 21:08) [5]

> CreateFile после возвращения дескриптора уже записала файл
> размером 0 в определенное место

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

← →
clickmaker © (2010-11-24 21:09) [6]

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

игра не стоит свеч.
в любом случае, если на винте есть свободный кусок в 1Гб, винда постарается записать его без фрагментов. Она не враг сама себе

← →
mem (2010-11-24 21:10) [7]

> то файл в любом случае будет разбит по кластерам

на кластеры я согласен))

← →
mem (2010-11-24 21:13) [8]

> Она не враг сама себе

это радует)))

> clickmaker © (24.11.10 21:09) [6]

а что насчет

> mem (24.11.10 21:08) [5]

?

← →
clickmaker © (2010-11-24 21:16) [9]

> CreateFile после возвращения дескриптора уже записала файл
> размером 0 в определенное место, так?

SetEndOfFile()

> Т.е. с очень большой вероятностью файл будет дефрагментирован,
> даже при наличии нужного куска

не стоит забывать, что могут быть еще процессы-претенденты, горящие желанием записать на свободное место.

← →
mem (2010-11-24 21:19) [10]

> clickmaker © (24.11.10 21:16) [9]

>
> SetEndOfFile()

т.е. файла как такового еще не существует?

> не стоит забывать, что могут быть еще процессы-претенденты,
> горящие желанием записать на свободное место.

упсь, а с ними что делать?

← →
Anatoly Podgoretsky © (2010-11-24 21:22) [11]

> mem (24.11.2010 21:19:10) [10]

А забить и пойти выпить пива или по серьезней.

← →
mem (2010-11-24 21:27) [12]

> Anatoly Podgoretsky © (24.11.10 21:22) [11]
>
> > mem (24.11.2010 21:19:10) [10]
>
> А забить и пойти выпить пива или по серьезней.

Серьезно: после выполнения

hFile := CreateFile(PChar(ExtractFilePath(Application.ExeName) + "index.dat"),
GENERIC_READ or GENERIC_WRITE,
FILE_SHARE_READ or FILE_SHARE_WRITE,
psa, CREATE_NEW, FILE_FLAG_SEQUENTIAL_SCAN, 0);
есть только запись в MFT и больше ничего, размер его ноль, а после выполнения
SetFilePointerEx(hFile, SizeOf(THashNode) * RecordCount, CurrHashPos, FILE_END);
SetEndOfFile(hFile);

уже выделяется место в области для файлов?

← →
clickmaker © (2010-11-24 21:30) [13]

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

← →
mem (2010-11-24 21:35) [14]

> clickmaker © (24.11.10 21:30) [13]

ХС присущ и один довольно существенный недостаток: он медленно работает, если индекс фрагментирован: то есть в том случае, если списки слов с одинаковыми сигнатурами разбросаны по несмежным секторам на диске.

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

> И не смущает, что между софтом и винтом еще куча посредников,
> влияющих на скорость: API, кэш, дисковый контроллер, наконец?
>

очень, очень смущает, но как избавиться?))

← →
mem (2010-11-24 21:36) [15]

> а это я не пропустил при первом чтении:

а это я пропустил при первом чтении:

← →
Anatoly Podgoretsky © (2010-11-24 21:41) [16]

> mem (24.11.2010 21:35:14) [14]

Кеш снять и продать, контроллер выпилить и сдать в драгметаллы - деньги
пропить

← →
mem (2010-11-24 21:44) [17]

> супермегабыстрый алгоритм поиска по индексу

там еще и данные. И один индекс пользуется другими. Так, навскидку, читать надо будет десятков пять последовательных массивов за присест, если каждый раз позиционировать - 50*мс эдак 5(или больше?), четверть секунды, да еще потом выбирать сами данные...

> Anatoly Podgoretsky © (24.11.10 21:41) [16]
>
> > mem (24.11.2010 21:35:14) [14]
>
> Кеш снять и продать, контроллер выпилить и сдать в драгметаллы
> - деньги
> пропить

много возни, предпочитаю начинать с последнего пункта))

← →
Anatoly Podgoretsky © (2010-11-24 21:48) [18]

> mem (24.11.2010 21:44:17) [17]

С последнего пункта не получится, сначало надо где то деньги взять.

← →
mem (2010-11-24 22:01) [19]

Удалено модератором

← →
Inovet © (2010-11-24 22:24) [20]

Про резюме в МС не зря сказали. Как-то ведь у них MSSQL работает без дефрагментации, а у тебя она критична, значит твой алгоритм круче.

← →
mem (2010-11-24 22:32) [21]

> Inovet © (24.11.10 22:24) [20]

> Как-то ведь у них MSSQL работает без дефрагментации

серьезно? Про фрагментированность индексов мы не слышали... попробуй, сравни скорости выполнения запросов с фрагментированными индексами и нет.

а в микрософт следует стремиться, в первую очередь, пиарщикам - по этому показателю они впереди планеты всей без всяких сомнений.

← →
Inovet © (2010-11-24 22:48) [22]

> [21] mem (24.11.10 22:32)
> серьезно? Про фрагментированность индексов мы не слышали...

Сервер непрерывный кусок диска под базу требует? Выделяет куски под страницы, потом заполняет по мере надобности. Дефрагментировать файл ну хорошо, средствами сервера дефрагментацию сделать в самом файле, тоже наверно хорошо.

← →
sniknik © (2010-11-24 23:02) [23]

> серьезно? Про фрагментированность индексов мы не слышали...
очень...
http://img708.imageshack.us/i/msfrag.png/
и никто не "парится"

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

← →
Rouse_ © (2010-11-24 23:07) [24]

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

← →
Плохиш © (2010-11-24 23:12) [25]

Прикольная ветка...

← →
mem (2010-11-24 23:29) [26]

> Rouse_ © (24.11.10 23:07) [24]

спасибо

← →
Anatoly Podgoretsky © (2010-11-24 23:39) [27]

> mem (24.11.2010 23:29:26) [26]

Это все комплексы.

← →
mem (2010-11-24 23:56) [28]

> Anatoly Podgoretsky © (24.11.10 23:39) [27]
>
> > mem (24.11.2010 23:29:26) [26]
>
> Это все комплексы.

верю

> очень, очень смущает, но как избавиться?))

1. Написать драйвер файловой системы
2. Использовать выделенный раздел
3. Поставить дисковый контроллер с 16 ГБ кэша.
...
4. PROFIT!!!

Но, скорее всего, алгоритм индексирования фиговый, если он НАСТОЛЬКО сильно деградирует в условиях, отличных от сферического вакуума.

З.Ы.
Всё-таки, критерий желания странного практически безошибочный ;)

← →
Дмитрий Белькевич (2010-11-25 01:13) [30]

>Размер в пределах 1 Гб.

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

> В памяти всё держать - не?

1. В памяти, скорее всего, не окажется непрерывного региона в 1 ГБ.
(Если, конечно, не 64-битная ОС)
Придётся городить огород с "окнами" доступа.

2. Страницы из региона размеров в 1 ГБ с большой вероятностью будут откачиваться.
Забудьте миф о "дешёвой оперативной памяти". В конкурентной многозадачной среде виртуальная память -- это ДИСКОВАЯ память с кэшированием в ОЗУ.

> и на фрагментацию можно забить.

Но придётся вспомнить о фрагментации свап-файла ;)

Разницы между "в памяти всё держать" и "на диске всё держать" почти нет.

> Дмитрий Белькевич (25.11.10 01:13) [30]
>
> >Размер в пределах 1 Гб.
>
> В памяти всё держать - не?

Можно подумать, что память в отличие от диска не фрагментирована.

P.S. Тут вспомнилось какое-то обсуждение о скорости доступа к секторам диска. Где убедительно было доказано, что максимальную скорость доступа к данным на диске можно получить "особым" расположением данных по секторам диска.

← →
Дмитрий Белькевич (2010-11-25 11:07) [33]

А зачем непрерывный кусок? Seek в памяти, в отличие от веников, из-за чего и происходят основные тормоза при фрагментации, равен нулю.

> Забудьте миф о "дешёвой оперативной памяти". В конкурентной
> многозадачной среде виртуальная память -- это ДИСКОВАЯ память
> с кэшированием в ОЗУ.

Своп можно выключить, что я у себя давно и сделал. Производительность сильно возросла. Иногда, правда, бывает, не хватает памяти. Но это, обычно, не чаще раза в 2-3 месяца. Перезагрузка помогает, не всё же машину в хибернейте держать.

> Дмитрий Белькевич (25.11.10 11:07) [33]
> А зачем непрерывный кусок?

Признайся: TPAW -- твой клон.

← →
Дмитрий Белькевич (2010-11-25 11:18) [35]

> Признайся: TPAW -- твой клон.

Это кто? :) Не знаю такого...

← →
Дмитрий Белькевич (2010-11-25 11:23) [36]

Господа. Поставлена конкретная задача. Зачем теоретизировать об общих случаях? 1 гиг вполне реально держать в памяти современной средней машины с, думаю, 2-мя гигами оперативки. Ну нужен человеку быстрый доступ к данным настолько, что он уже в оптимизацию на уровне жёсткого полез. Зачем это ему? Пусть в памяти всё делает.

← →
mem (2010-11-25 12:52) [37]

Всем спасибо, значит дефрагментация файла мало влияет на производительность. Хорошо, тогда почему фрагментированность индексов в том же MS SQL Server очень заметно влияет? Ведь это одно и то же по сути - фрагментирован файл->фрагментирован индекс.

> DiamondShark © (25.11.10 00:58) [29]

>
> З.Ы.
> Всё-таки, критерий желания странного практически безошибочный
> ;)

не торопись с выводами.

> Но, скорее всего, алгоритм индексирования фиговый, если
> он НАСТОЛЬКО сильно деградирует в условиях, отличных от
> сферического вакуума.

см. выше про индексы.

Может надо было сразу сказать? Программка будет получать много поисковых запросов последовательно - десятки, сотни тысяч, поэтому экономия каждой капли времени будет заметна в конечном итоге. Если б нужно было обработать один запрос, я б не парился.

← →
mem (2010-11-25 12:52) [38]

впрочем, хрен с ней, с дефрагментацией - индексы загоню в память, конечно

Дети Ивана Кулибина

← →
mem (2010-11-25 13:18) [40]

дефрагментация файла Найти похожие ветки