LINUX.ORG.RU

Пополнение в проекте GNU — GNU ccd2cue

 , , ,


1

1

Одновременно с выходом версии 0.3 приложение для конвертирования CCD-файлов в формат CUE вошло в состав проекта GNU.

CCD (CloneCD Control File) — проприетарный формат файлов, описывающий последовательность треков CD/DVD, используемый в проприетарной Windows-only программе CloneCD, применяемой для эмуляции оптических дисков. Аналогом CCD является формат CUE.

ccd2cue появилась в феврале 2011'ого года и является единственной свободной (на данный момент распространяется под GPLv3) программой для конвертации файлов CCD в файлы CUE.

24 января была выпущена версия 0.3, главным изменением которой было становление ccd2cue частью проекта GNU. Помимо этого, в этом выпуске была обновлена документация и исправлено несколько ошибок в программе.

Страница проекта на gnu.org

Репозиторий проекта на GNU savannah

>>> Список изменений в новой версии

Ответ на: И да и нет... от Moisha_Liberman

Это регулируется через /proc/sys/vm/dirty_ratio по дефолту у меня там 20% от RAM, делать что-то типа echo 100 > /proc/sys/vm/dirty_ratio и отдавать 100% на кеши записи, превращая свой хост в «машину только для копирования», я бы не рекомендовал. Как правило, на хосте есть ещё и другие задачи, кроме копирования.

под кеш отдаётся не «вообще вся», а только та память, которая не используется. Если тебя не затруднит, объясни мне пожалуйста, ЗАЧЕМ тебе эта память и почему ты не хочешь отдать её в кеш?

По поводу dirty_ratio, то оно несколько для другого, и дефолт там 40.

/proc/sys/vm/dirty_ratio (default 40): Maximum percentage of total memory that can be filled with dirty pages before processes are forced to write dirty buffers themselves during their time slice instead of being allowed to do more writes.

http://www.westnet.com/~gsmith/content/linux-pdflush.htm

Ну и, справедливости ради, я бы ещё посмотрел на /proc/sys/vm/vfs_cache_pressure (по дефолту 100). Его можно увеличить и заставить ядро достаточно редко писать на диск, лишь бы памяти хватило:

заняться мне больше нечем. У меня и так ВР.

Считается на уровне user-space приблуды, я замечу. Что там реально произойдёт с kernel-space буфером, приблуде неизвестно. Однако, сама по себе ОС не даст отмонтировать девайс, пока не сбросит до конца буферы.

да. Ты споришь или соглашаешься?

Я в курсе про iostat, скажу сразу и копирования там в момент наблюдения не было. Светодиод моргает всякий раз, когда есть обращение к флешке. Т.е., есть +5V на шине USB, включились. Нет — выключились. «Интеллекта» там ноль. По-моему, автомаунтер это балуется. Хотя, я и не проверял, скажу честно.

интеллект не во флешке, а в самой системе. Твоя не в меру умная система пытается что-то именно ЧИТАТЬ, а именно что ты воткнул, и не вынул-ли. Если отключишь свой DE, то увидишь, что моргать оно перестанет(естественно и наличие флешки можно будет проверить лишь попытавшись её смонтировать).

Мы можем поговорить о подборе планировщика ввода-вывода

можем. Он не нужен.

emulek ()
Ответ на: комментарий от emulek

Не затруднит...

... объяснить:

Если тебя не затруднит, объясни мне пожалуйста, ЗАЧЕМ тебе эта память и почему ты не хочешь отдать её в кеш?

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

По поводу dirty_ratio, то оно несколько для другого, и дефолт там 40.

Смотрел кошкой на Генту 3.13.1, было 20. А про «несколько для другого», так буферы выделяются страницами памяти, так что всё правильно:

Maximum percentage of total memory that can be filled with dirty pages before processes are forced to write dirty buffers themselves during their time slice instead of being allowed to do more writes.

Согласен, перед тем, как эти самые «буферы» (страницы) будут сбрасываться, система постарается забить их возможно более полно, если ей хватит на это времени. Но опять же — 40% это больно дофига. По моим прикидкам, 40% можно забить при серверной модели вытеснения (server preemptive model), т.е. когда систему мало что отвлекает от работы (например, переключения контекстов задач сравнительно редки). В desktop preemptive model (или, что ещё хуже, в low-latency desktop preemptive model), система будет выделять буферы, но записывать туда может просто не успевать — time slices маловаты могут оказаться. В результате, гипотетически мы отобрали 40% от доступной на момент операции памяти, а использовать её просто не смогли.

да. Ты споришь или соглашаешься?

Если прочесть тред изначально (я там от анонима писал), то я вообще-то, про то и говорил. Изначально.

Если отключишь свой DE, то увидишь, что моргать оно перестанет(естественно и наличие флешки можно будет проверить лишь попытавшись её смонтировать).

Да фиг его знает — я не проверял автомаунтер там шалит или ещё что. Помаргивает раз в 2-3 секунды, да и фиг бы с ней.

можем. Он не нужен.

Для флешки в 16/32G он да, не нужен. Разве что эксперимента ради. Однако рекомендую поставить SSD и организовать там например, хомяк или /tmp (есть у меня в хозяйстве такие задачки, где /tmp ой как важен и его приходится делать в RAM, благо её достаточно) и тогда пересмотр стандартного для системы алгоритма планировщика для SSD будет то, что доктор прописал.

Ну и вот лежит, синеньким светодиодом помаргивает, BeagleBone Black (да, там тоже Gentoo). На нём мозгов 512M, плюс 16G microSD. HDD нет и в помине, хотя можно присунуть по USB. Планировщик там сразу deadline выставил. Другие да, не нужны. Но, справедливости ради, замечу что там с ядром вообще по-взрослому пришлось... И это нетипичный случай. Просто привёл как пример.

Moisha_Liberman ()
Ответ на: Не затруднит... от Moisha_Liberman

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

система и не станет свопится, если есть память под файловый кеш. Она просто уменьшит этот кеш.

например

$ free -m
             total       used       free     shared    buffers     cached
Mem:           988        949         39          0          0        585
-/+ buffers/cache:        363        625
Swap:          121        121          0
когда какой-то malloc(3) просит немного памяти, система их выделяет из 585и «свободных».

Конечно если ты ничего не «оптимизировал».

В результате, гипотетически мы отобрали 40% от доступной на момент операции памяти, а использовать её просто не смогли.

почему «отбросили»-то? И да, если зело умный, то уменьши/увеличь, и насладись тормозами.

Да фиг его знает — я не проверял автомаунтер там шалит или ещё что. Помаргивает раз в 2-3 секунды, да и фиг бы с ней.

больше некому.

Для флешки в 16/32G он да, не нужен. Разве что эксперимента ради. Однако рекомендую поставить SSD и организовать там например, хомяк или /tmp (есть у меня в хозяйстве такие задачки, где /tmp ой как важен и его приходится делать в RAM, благо её достаточно) и тогда пересмотр стандартного для системы алгоритма планировщика для SSD будет то, что доктор прописал.

вот рядом комп жены

Файловая система         Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sda1                  942M         501M  376M           58% /
/dev/sda3                  3,7G         3,3G  225M           94% /var
/dev/sda5                  9,1G         7,5G  1,1G           88% /usr
/dev/sda6                   41G          26G   16G           62% /home
tmpfs                      1,8G          24M  1,8G            2% /dev/shm
tmpfs                      1,0G          32K  1,0G            1% /tmp
             total       used       free     shared    buffers     cached
Mem:          3624       2929        694          0        415       1240
-/+ buffers/cache:       1273       2350
Swap:         3906        195       3710
а ты — диванный теоретик.

И это нетипичный случай. Просто привёл как пример.

плохой пример.

emulek ()
Ответ на: комментарий от emulek

Угу...

... конечно:

система и не станет свопится, если есть память под файловый кеш.

Если есть память. А если нет? Внезапно оказалась занята чем-то? Поубивать лишнее? Ну, в общем-то не все на своих хостах только музончик слушают, да фильмачки глядят. Кое-кому и работать надо (под «работой» здесь понимается слегка не веб-дизайн и совсем не правка курсовиков).

Ага:

Она просто уменьшит этот кеш.

Системе вот просто делать нефига кроме как уменьшать кеш, увеличивать кеш (и так по кругу). Проще поставить некое разумное в наши дни значение и не париться. Что, кстати, команда Gentoo и сделала. Я не правил значение 20%, оно там уже было.

когда какой-то malloc(3) просит немного памяти

Странно, но я про «немного» почему-то и не подумал... :) Понятие «немного», оно как всегда, весьма относительное. ;) «Немного» для BeagleBone Black и HP DL-980, с забитыми под завязку разъёмами RAM (4Tb), это немного разные «немного».

И да, если зело умный, то уменьши/увеличь, и насладись тормозами.

Информация к размышлению. 20% от 4G, 20% от 8G и 40% от 512M или 40% от 1G... Зачем выделять 40% от 4-8G? Если хватит и 20 в численном выражении (в байтах). Использовать 40% от 4-8G нам не позволят короткие time slices.

а ты — диванный теоретик.

Ну, не буду спорить, Вам виднее.

плохой пример.

Правда? http://lmgtfy.com/?q=ssd deadline noop

Moisha_Liberman ()
Ответ на: Угу... от Moisha_Liberman

Если есть память. А если нет?

тогда NoWay. Только магазин тебе поможет.

Внезапно оказалась занята чем-то? Поубивать лишнее? Ну, в общем-то не все на своих хостах только музончик слушают, да фильмачки глядят. Кое-кому и работать надо (под «работой» здесь понимается слегка не веб-дизайн и совсем не правка курсовиков).

да. man OOM.

Системе вот просто делать нефига кроме как уменьшать кеш, увеличивать кеш (и так по кругу).

это одна из основных задач системы:

  • когда приложению нужна память, оно просит память например malloc(3)'ом. Система отрезает память от кеша.
  • когда нужно что-то скопировать, система занимает память освобождённую free(3).

если задач слишком много, и они слишком много жрут памяти по совокупности, то это — авария. Самое лучшее, что может сделать система, это прибить какой-нибудь процесс, который слишком часто и слишком много жрёт. Она так и делает.

В обычном режиме файл считанный из памяти так и валяется в кеше, и второй раз система его с носителя НЕ читает. «Записанный» файл также лежит в кеше, и записывается. Программа, которой это надо(было), работает дальше, думая, что файл записан.

Проблемы и тормоза начинаются лишь если памяти мало. Тогда системе приходится по десять раз читать одно и то же. Кроме того, приходится ждать, пока все «записанные» файлы запишутся, что-бы отрезать немного памяти. Никакими настройками это НЕ лечится. Только через магазин...

Странно, но я про «немного» почему-то и не подумал...

а зря, потому что malloc(3) действительно обычно немного просит. Файловые операции просят больше.

Информация к размышлению. 20% от 4G, 20% от 8G и 40% от 512M или 40% от 1G... Зачем выделять 40% от 4-8G? Если хватит и 20 в численном выражении (в байтах). Использовать 40% от 4-8G нам не позволят короткие time slices.

откуда ты взял какие-то «байты»? Что значит «хватит»? В конце концов, если программа прочитала 1Мб, а потом попросила 1Мб памяти, то вполне вероятно, что если-бы программа(эта же) прочитала 100Мб, то она после этого попросила-бы не 1Мб, а 100Мб. Линейное потребление памяти — обычное дело. Потому, качественно, процессы на сервере эквивалентны процессам в твоём роутере. Хотя в роутере памяти и меньше на порядки.

Ну, не буду спорить, Вам виднее.

ессно. У меня твои «рекомендации» давно и успешно работают. А ты их только-что нафантазировал.

Правда? http://lmgtfy.com/?q=ssd deadline noop

да! http://lmgtfy.com/?q=защита от вредных излучений компьютера кактусом

К сожалению, это самое распространенное заблуждение — в миф о бесполезности кактусов верят даже опытные пользователи ПК, которые, к тому же, навязывают свое ошибочное мнение начинающим.

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

emulek ()
Ответ на: комментарий от emulek

Нндэ? А, ...

... стесняюсь спросить,

Только магазин тебе поможет.

Мозгами пользоваться не пробовали?

man OOM.

Он здесь не нужен.

это одна из основных задач системы:

Это не одна основных задач системы дёргать системные буферы. malloc()/free() здесь не при делах, я бы ещё пообсуждал бы kmalloc()/kfree(), но здесь даже и обсуждать нечего.

Что касается «немного», и

Линейное потребление памяти — обычное дело.

То я могу рекомендовать поставить эксперимент по выделению/освобождению памяти от гектара и больше. Ну и засечь время на эти операции, если не затруднит. Когда оцените (хотя бы на гектаре), то можно будет прикинуть сколько надо будет времени на выделение нескольких гектар из 4Т (выше уже говорил на каком железе). Там это будет «немного». Тогда, как мне кажется, до Вас должно дойти почему народ загоняется по in-proccess memory caching, и почему это Ваше «линейное потребление памяти» зачастую бред и ересь, за которую надо разжаловать в рядовые и сослать на Восточный фронт.

откуда ты взял какие-то «байты»? Что значит «хватит»? В конце концов, если программа прочитала 1Мб, а потом попросила 1Мб памяти, то вполне вероятно, что если-бы программа(эта же) прочитала 100Мб, то она после этого попросила-бы не 1Мб, а 100Мб. Линейное потребление памяти — обычное дело. Потому, качественно, процессы на сервере эквивалентны процессам в твоём роутере. Хотя в роутере памяти и меньше на порядки.

Этот прогон выше был вообще ни о чём. Мы тут про «копирование файлов», вообще-то. Так что, «если программе» следует отдохнуть и вкурить матчасть. «Байты» взяты из того, что ядро не резервирует 40% и не резервирует 20%. Оно резервирует память менее извращённым способом.

«Хватит» (я уже показал сколько именно на Gentoo резервируется) идёт от того, что 40% от 4G это намного больше 20% от тех же 4G. Посчитать осилите? В каком там классе проценты проходят?

Теперь следующий момент — эти ваши 40%, их надо скинуть умудриться на диск. Иначе мелкие копируемые файлы будут там болтаться немного дольше, если система их не будет успевать скинуть (ещё раз — time slices имеют определённую величину). Большие файлы при копировании столкнутся с тем, что так же не будут во-время сбрасываться на диск. Нужны будут повторные итерации. Напоминать о том, что при записи данных могут возникнуть блокировки надо? Вот корень ваших 12309 — фиговая работа с буферами системы. Рекомендую примерно оценить временные затраты для разных размеров буферов простой строкой $sync; sudo echo 3 > /proc/sys/vm/drop_caches Время на исполнение посмотреть осилите? Для 20 и 40 % соответственно.

Второй корень 12309 — косой планировщик ввода-вывода, что, кстати, тоже приводит к фиговой работе с буферами. Я не знаю что там у Вас лично реализовано и насколько давно, но косвенный факт, что у Вас начался баттхёрт, выражаемый в треше про кактусы, от обсуждения планировщиков deadline и noop показателен.

А ты их только-что нафантазировал.

Мне надоело тут рассусоливать, я ещё «только что нафантазирую». Короче, чтобы с системой всё было ровно в части памяти, я для себя «нафантазировал» такие значения — под «систему» я могу отдать до 10% RAM (да, буферы стека TCP/IP так же оптимизированы), под буферы файлового IO — 20%, остальные 70% — свободная RAM, доступная для работы.

Moisha_Liberman ()
Ответ на: комментарий от meduza

Re: Бесплатные альтернативы pianoteq

Ответ на сообщение:

Попробуй LV2 порт MDA Piano.

Ещё можно попробовать всякие библиотеки семплов (soundfont и др.) вроде Salamander Grand Piano.

PS: тему надо было создавать в этом разделе.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.