Программа пишет на диск несколько файлов одновременно, заранее известен размер файлов, есть какое нибудь кросс платформенное решение записать эти файлы на диск с минимальной фрагментацией?
как то увеличить буфер в которым хранятся данные перед записью на диск?
если кросс платформенного подхода нет, может кто покажет это решение для винды/линукса?

для Linux:
>man 2 truncate
>man 2 ftruncate

то что нужно, не устраивает только то что освобожденное пространство заполняется нолями (
сколько времени займет создание файла например в 1ГБ?
я раньше после создания файла записывал ноль в его последний байт (seek, write), но я не знаю как система работает и потому понятия не имею освободится ли все место под файл или только два фрагмента (стартовый и последний в котором я пишу один байт).

зачем ты спрашиваешь? проверь!

boostcoder, это была риторика ))
просто если я создам дюжину таких файлов (возможно с размером побольше), это разве не убьет мой поток на некоторое время?
пишу под виндой, нет никакой возможности проверить под линухом, но код все равно запишу )

наверное забавно писать код который не можешь проверить.

asmdzen, поставь virtual box (он бесплатный) и arch linux туда какой-нибудь или ubuntu. Очень хорошая и, главное, простая виртуальная машина. Зато тестировать все сможешь. Времени на скачивание/установку/настройку и т.п. займет минут 20-30 + время инсталла ОС.

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

  
Сколько я линуксы ни ставил (начиная с Mandrake в начале 2000-х и Gentoo с 2005 года), но никогда они не требовали столько места. Под систему можешь выделить 6-10 ГБ в виртуальной машине (если же хочешь установить на другой раздел основного диска, то выделить рекомендую не менее 20 ГБ).
У меня стоит убунта и особых проблем не знаю.

да я так прикололся, на самом деле я выделил в виртуалке где то 5ГБ (винт маленький был), устанавливал Debian где то пол дня, в конце оказалось что ему не хватает каких то 500 МБ чтоб установить оконный интерфейс, вот я и забросил это дело, думаю программу допишу чтоб под виндой работала потом уже линукс установлю, но все же это придется сделать )
мне нужна самая легкая версия чтоб можно было проект скомпилировать и потестить, все остальные навороты пока не к чему.
попробую arch.

Это сообщение отредактировал(а) asmdzen - 29.7.2011, 14:12

если у тебя прога без ГУИ, то и ставить его поддержку необходимости нет никакой. *nix - это тебе не Windows/DOS, в которых через консоль хрен что сделаешь.

GUI на wxwidgets


ненавижу работать с системой, мой принцип: установил - работает. в винде у меня стоит Тотал Командер, VC и CodeBlocks, это все. Не очень хочется выучивать все линуховские команды, хотя знаю что пригодятся.

для винды SetEndOfFile

asmdzen, https://wiki.archlinux.org/index.php/Offici...x_Install_Guide
Я недавно заводил на virtual-box'е арк + кеды. Делал, кстати, динамический раздел для ОС с минимальным размером 10Гб. Даже близко весь его не забил, но если надо он сам пополнится. Там же всего 1 файл с машиной получается. Главное, чтобы он лежал на винте, где места хватит. Но раз у тебя есть GUI, то я рекомендую не заморачиваться с арком и ставить убунту - времени меньше уйдет, проверено.  Т.к. в арке ставится сначала тупо ядро, потом иксы и т.п. Короче, лучше не париться и ставить debian/ubuntu. 

bems, спасибо. Вот только он хочет HANDLE, теперь надо будет открывать файлы при помощи CreateFile я так понимаю.
а есть какие то функции для увеличения буфера записи данных на диск? желательно из с++, как именно нужно работать с файлами чтоб можно было изменять размер буфера (iostreams, fopen, open)?
например у меня записываются 100 маленьких файлов (~100кБ), нужно увеличить буфер так чтоб они записались разом на диск или хотя бы по завершении записи (close).

spyswamp, где ты раньше был? я уже скачал и устанавливаю Arch ) да ладно, не получится попробую Убунту.

Это сообщение отредактировал(а) asmdzen - 29.7.2011, 15:02

asmdzen, я знаю винапи, но совершенно не знаю плюсов 
но вот какая-то open из io.h вроде возвращает хендл

нашел кое что интересное - boost::filesystem::resize_file(const path& p, uintmax_t new_size);
работает как truncate

оО..

буду знать 

вот только и она и file_size требуют не хэндл а имя файла, получается что если файл уже открыт (ofstream и open) то выдает ошибку типа:

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

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

Добавлено через 4 минуты и 19 секунд
хотя сообщение в ислючении говорит что операция завершилась успехом  
оберни этот вызов в try-catch, и посмотри, файл изменяет свой размер?
но в любом случае изменять размер файла который уже используется, как-то не правильно. его размер может изменять использующий его код.

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


есть версия resize_file которая получает в качестве параметра ссылку на boost::system::error_code
и возвращает в нем код ошибки, но размер файла не меняется все равно.

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

ну так определи необходимый размер и потом создавай.


откуда мнение что он чем-то должен заполняться?


fstream.rdbuf()->pubsetbuf(ptr, size);

разве можно создать файл сразу с определенным размером??   


да нет, это спецификация resize_file, т.е. он и должен быть заполнен нолями, я писал что никакой нагрузки не заметил когда он заполнялся )

большое спасибо. т.е. я создаю этот буфер (насколько понял можно и перед открытием файла)? при уничтожении fstream'а он освободится?

Это сообщение отредактировал(а) asmdzen - 29.7.2011, 20:29

нет. создаешь файл. изменяешь его размер. и пишешь в него!  


пруф, пожалуйста.


сам выделяешь, и сам освобождаешь. или используй смарт-поинтер.

файл и в самом деле был заполнен нолями )
всем спасибо, вопрос считаю закрытым.

кросплатформенный вариант:


Добавлено @ 21:32
у меня немного иначе написано.


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


Это сообщение отредактировал(а) boostcoder - 29.7.2011, 21:35

так и есть. прочитал расширенных 100Гб, и никакой активности на HDD не возникло 

видимо так и есть, я просто предпологал что туда что-то пишется из-за этого 
т.е. я думал что это похоже на операцию malloc, а в линуксе еще выполняется ZeroMemory )



не могу понять как это возможно

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


Это сообщение отредактировал(а) asmdzen - 29.7.2011, 22:19

написал же выше:


Добавлено через 1 минуту и 22 секунды
по идее блоки которые добавились, имеют какой-то атрибут, который ядро проверяет при чтении. смысл читать то, куда никто и никогда не писал?  все логично.

Это фича файловой системы. Называется sparse file.

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

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

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

asmdzen, там может и не sparse file. По умолчанию эта фича выключена. Наоборот чтобы включить надо сделать кое-какие движения.

Если же к первоначальному вопросу про нефрагментированный файл, то в МСДН есть инфа как создать нефрагментированный файл средствами winapi. Начните отсюда
но 

не знаю.

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

asmdzen, эта тема затянулась на три страницы, а я так и не могу понять чего конкретно ты пытаешься добиться, и почему постоянно это "добивание" у тебя новое  

Это сообщение отредактировал(а) boostcoder - 30.7.2011, 11:33

Насчет того что там "sparse file" - возможно. Я просто хотел сказал что есть такая фича, и про нее забывать не стоит.
Посмотреть/поменять атрибут "sparse file" можно в файловых менеджерах. Например FAR позволяет это сделать для любого файла.


Даже если вы реально заняли какое-то кол-во блоков, не факт что эти блоки расположены не фрагметнировано.
Система сама определяет какие блоки выделить для файла, и повлиять на этот выбор стандартными средствами, имхо, нельзя.

пишутся несколько тон файлов сразу, кусками по несколько КБ, если я просто создам эти файлы и начну писать то у меня такое подозрение что система их хорошенько перемешает. Насколько я понял в NTFS файл разделен на блоки размером в 64КБ, получается 64КБ от одного файла, следующие от другого, меня это не устраивает, хочется записывать файлы с минимум фрагментов.


не понял вопрос, или это не вопрос )


все же, IMO, если зарезервировать для файлов весь размер сразу то фрагментации будет меньше.

Добавлено через 6 минут и 27 секунд
поведение как у sparse файлов, т.е. весь файл как бы заполнен нолями, но при попытке растянуть файл на 100ГБ при свободных 50 работать не хочет, со sparse файлами вроде должно было прокатить.

asmdzen, для проверки, сразу после резервирования места для файла, вызовете функцию GetCompressedFileSize ();
Если размер равен тому что зарезервировали, то значит все нормально. Это не "sparse file" и не сжатый файл.

наконец то положительный результат ))
вернул размер до байта.

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

asmdzen, посмотрите как это делается в бусте

Подробнее здесь.

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

это ясно. я лишь хотел сказать, что зарезервированное пространство для файла, не значит что оно sparse.

не хочется под винду именно писать, к тому же мой вариант не на много хуже:
результат такой же как от boost::resize_file, по крайней мере я разницы не вижу.