Здравствуйте, niXman, Вы писали:

CK>>... Boost.Asio — не может работать с файлами (точнее может, но только под windows).
X>с каких это парофф? вроде всегда был и posix::stream_descriptor, и windows::stream_handle. даже использовал несколько раз.

stream_descriptor не подходит, мне нужен случайный доступ а не потоковый, а posix::stream_descriptor подходит для пайпов и всего такого, но не для файлов, открытых через O_DIRECT, ну и я уверен что он там внутри linux aio не использует. Мне подходит windows::random_access_handle, но у него нет аналога в пространстве имен posix.

Здравствуйте, chaotic-kotik, Вы писали:

CK>stream_descriptor не подходит, мне нужен случайный доступ а не потоковый
разве в топике об этом сказано?

Здравствуйте, niXman, Вы писали:

X>разве в топике об этом сказано?

Там упоминается Direct I/O. Этого достаточно, ИМО.

Здравствуйте, chaotic-kotik, Вы писали:

CK>Там упоминается Direct I/O. Этого достаточно, ИМО.
совершенно недостаточно. O_DIRECT можно использовать и на потоковом доступе.

Здравствуйте, niXman, Вы писали:

X>совершенно недостаточно. O_DIRECT можно использовать и на потоковом доступе.

Ты можешь это утверждение чем-нибудь подкрепить?
Как минимум странно использовать потоковые дескрипторы в асинхронном режиме, т.к. операции все равно должны быть выстроены в очередь. So what's the point?

Здравствуйте, chaotic-kotik, Вы писали:

CK>Ты можешь это утверждение чем-нибудь подкрепить?
могу подкрепить ссылкой на ман(вдруг ты не читал), и еще вот этой. а так же, своим опытом использования этого флага.
из приведенных мною ссылок и опыта, могу смело утверждать, что ни "случайный", ни "потоковый" доступы к этому флагу не имеют никакого отношения. все что этот флаг "делает", так это Try to minimize cache effects, и что дополнительно нужно помнить про The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC flag that data and necessary metadata are transferred. To guarantee synchronous I/O, O_SYNC must be used in addition to O_DIRECT.

CK>Как минимум странно использовать потоковые дескрипторы в асинхронном режиме, т.к. операции все равно должны быть выстроены в очередь. So what's the point?

что вообще понимается под "потоковые дескрипторы"? мне кажется мы говорим о разном...

могу еще провести экскурс реализации для флагов O_DIRECT и O_SYNC внутри ядра, но не думаю что оно того стОит.
к тому же, не уверен, что для вянды есть какие-то аналоги этим флагам...

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, niXman, Вы писали:

X>>совершенно недостаточно. O_DIRECT можно использовать и на потоковом доступе.

CK>Ты можешь это утверждение чем-нибудь подкрепить?
CK>Как минимум странно использовать потоковые дескрипторы в асинхронном режиме, т.к. операции все равно должны быть выстроены в очередь. So what's the point?

O_DIRECT определяет только механизм ввода/вывода используемый драйвером ФС, кроме ФС данные проходят ещё через слой блочных устройств в ядре, саму передачу данных драйвером адаптера шины, на всё на это O_DIRECT никак не влияет. Но нотификация при выполнении всех операций будет прилетать при использовании O_DIRECT так же, как и при его неиспользовании.

Здравствуйте, niXman, Вы писали:

X>из приведенных мною ссылок и опыта, могу смело утверждать, что ни "случайный", ни "потоковый" доступы к этому флагу не имеют никакого отношения. все что этот флаг "делает", так это Try to minimize cache effects, и что дополнительно нужно помнить про The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC flag that data and necessary metadata are transferred. To guarantee synchronous I/O, O_SYNC must be used in addition to O_DIRECT.

Если бы ты по делу пользовался O_DIRECT, то вспомнил бы про другое

X>что вообще понимается под "потоковые дескрипторы"? мне кажется мы говорим о разном...

Потоковые это pipe, fifo, unix socket etc. Они не поддерживают seek. Если ты открываешь файл с флагом O_DIRECT то он поддерживает seek, в него конечно можно писать последовательно, но это не значит что файл это то же самое что и pipe.

Мне же нужно работать с файлом как с блочным устройством напрямую, в обход кеша и параллельно. Т.е. у меня есть несколько потоков, которые асинхронно записывают блоки фиксированного размера в файл. Я там выше писал что это — оптимизация под SSD, мне нужна асинхронность для того чтобы загрузить очередь команд eNVM SSD, иначе пропускную способность не получается утилизировать. Сделать это через boost::asio::posix::stream_descriptor нельзя, так как у него нет а) возможности указать offset для каждой операции записи б) при записи последовательно получить оффсет по которому произошла запись в) писать параллельно в несколько потоков (я имею ввиду не потоки ОС, а возможность отправить устройству несколько команд записи/чтения параллельно).

Здравствуйте, chaotic-kotik, Вы писали:

CK>Если бы ты по делу пользовался O_DIRECT, то вспомнил бы про другое
про какое?

Здравствуйте, chaotic-kotik, Вы писали:

CK>Мне же нужно работать с файлом как с блочным устройством напрямую, в обход кеша и параллельно. Т.е. у меня есть несколько потоков, которые асинхронно записывают блоки фиксированного размера в файл. Я там выше писал что это — оптимизация под SSD, мне нужна асинхронность для того чтобы загрузить очередь команд eNVM SSD, иначе пропускную способность не получается утилизировать. Сделать это через boost::asio::posix::stream_descriptor нельзя, так как у него нет а) возможности указать offset для каждой операции записи б) при записи последовательно получить оффсет по которому произошла запись в) писать параллельно в несколько потоков (я имею ввиду не потоки ОС, а возможность отправить устройству несколько команд записи/чтения параллельно).

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

Здравствуйте, niXman, Вы писали:

X>откуда эта задача вообще взялась? оО

из обсуждения (вот так неожиданность)

X>в топике ничего об этом нет я же отвечал исключительно по информации описанной в топике.

в топике сказано что то что есть в boost.asio мне не подходит

Здравствуйте, niXman, Вы писали:

CK>>Если бы ты по делу пользовался O_DIRECT, то вспомнил бы про другое
X>про какое?

про необходимость выравнивания и работу в обход кэша например

Здравствуйте, chaotic-kotik, Вы писали:

CK>в топике сказано что то что есть в boost.asio мне не подходит
не правда. в топике сказано, цитирую:

Boost.Asio — не может работать с файлами (точнее может, но только под windows).

я же указал на то, что это не соответствует действительности, и что asio предоставляет фозможность работать с файлами и в линукс.
ни о каких O_DIRECT, как и ни слова про seekable в топике нет.

Здравствуйте, chaotic-kotik, Вы писали:

CK>про необходимость выравнивания
если вы берете на себя заботу о кеше — то и выравнивание становится вашей заботой.

CK>и работу в обход кэша например
т.е. вы хотите сказать, что я процитировал ман, и не заметил что в цитате говорится именно о этом? =)

Здравствуйте, niXman, Вы писали:

X>я же указал на то, что это не соответствует действительности, и что asio предоставляет фозможность работать с файлами и в линукс.

через жопу

X>ни о каких O_DIRECT, как и ни слова про seekable в топике нет.

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

ну и обсуждение состоит не только из первого комментария