Автор Тема: CD, DVD, Blu-ray диски и болванки. Audio проигрывание, запись, ISO-образы, прожиг и все вопросы.  (Прочитано 55054 раз)

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 251
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
1 - как вы скачивали образ ?
2 - проверяли-ли md5sum ?
3 - как вы записывали образ ?
« Последнее редактирование: 19.03.2009 09:37:47 от ruslandh »

Оффлайн Rolland

  • alt linux team
  • ***
  • Сообщений: 241
  • Шаман с бубном
    • Свободное ПО
Скорее всего неправильный образ
Да прибудет с нами сила

Оффлайн npanop

  • Начинающий
  • *
  • Сообщений: 3
ftp://ftp.altlinux.com/pub/distributions/ALTLinux/4.1/Desktop/4.1.1/iso/altlinux-4.1.1-desktop-i586-install-dvd5.iso

Качал манагером оперы, мд5 проверил - порядок, писал 4-й скоростью

Оффлайн npanop

  • Начинающий
  • *
  • Сообщений: 3
Проблема решилась сама-собой, купил другие болванки.

Использовал:
Daewoo (-R) - была проблема
TDK (+R) - установка прошла нормально


Оффлайн Rolland

  • alt linux team
  • ***
  • Сообщений: 241
  • Шаман с бубном
    • Свободное ПО
Всегда верил в TDK и Verbatim:)
Да прибудет с нами сила

Оффлайн Alsnake

  • Начинающий
  • *
  • Сообщений: 22
У меня, кстати, тоже диск при записи Alt...DVD.iso, точнее при проверке записи, ошибку выдает. Болванки Вербатим. Писать пробовал и ImgBurn и Infra Recorder. Пробовал ставить с этих дисков установка проходит вроде нормально.
Так что если в Волгограде кому надо - есть парочка лишних DVD AltLinux 4.1.1 :)

lad

  • Гость
Программа manDVD, создаю структуру каталогов DVD и на этапе выполнения перекодировки "Finalization of the project" интерфейс подмораживает, каждое действие на секунд 5 -10. т.е. крест - закрыть окно, закроется через 10 сек. в уже открытой консоли запускаешь top запускается через 7мь сек.
вывод топа выдаёт "D" т.е. очень интенсивный обмен с диском. Причём после этого безобразия всё работает, но теряется (вытесняется) кэш программ и библиотек, и запускается всё очень медленно (некоторое время).
Обидно то, что у меня 4 гб и kernel-pae без свопа. т.е. понятно, что обработка гигабайт мультимедиа вытесняет всё из кэша.  (непонятно нахрена :( )
Вопрос для десктопа 4.1.1:
1. можно для какой-либо программы/процесса уменьшить или жёстко задать объём данных в кэше для процесса.
2. обычным nice нельзя ограничить дисковый обмен процесса (приоритетность), вообще есть такая возможность?
3. запретить вытеснять из кеша что-нибудь по шаблону какому-нибудь, ну типа не вытеснять по пути /lib;/bin;/usb/bin или с признаком исполняемый?


lad

  • Гость
Я так понял, что это к выделению оперативки для процесса (new, delete, malloc) т.е. информация для программиста (и скорее для для очень системного: библиотеки, компиляторы и всё такое).
А я (пользователь) управлять этим не могу.

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

Alexei_VM

  • Гость
Тут подумалось, что некоторые виртуальные машины это могут

Может проще смотреть в сторону SCSI вместо IDE/SATA?

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 251
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Обычно помогает использование swap и 64-битной архитектуры.

lad

  • Гость
SCSI - не думаю, что в данном случае это значительно поможет. Я правда не очень представляю разницу scsi-sata. Но проблема в том что идёт очень интенсивный обмен (скорее всего копирование Гбайтный файлов) и проблема imho упирается в железа - тупо в поиск дорожек и сектора (с учётом отсутствия приоритетов на IO). хотя для sata вроде присутствует оптимизация и если при переходе на "дальний" сектор (дорожку) можно получить сектор из запроса который стоит выше в очереди (самого винта) то получается сначала тот что ближе а не тот что первый в очереди. Для scsi это ещё круче????

свап imho скорее всего не будет использоваться, т.к. программами занято меньше 700 мб а файловый кэш в 3гб это не причина для свопинга, процесс в своё адресное пространство затягивает небольшие куски мультимедиа а не весь обрабатываемый (тем более 2 - ещё и выходной) файл.

64 бита вроде тоже не совсем из этой оперы. Разве только поиметь физической оперативы гарантированно больше чем весь объём мультимедиа. :) это конечно мысль, мануал брешет, что мать у меня до 16 гб держит. :)

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

Спасибо.

Alexei_VM

  • Гость
SCSI - не думаю, что в данном случае это значительно поможет.

Как раз в этом случае поможет. Во всяком случае в тот момент, когда будет идти интенсивная работа с диском, приложение и все система в целом не будут замирать на секунды. Скорее всего вообще не будет заметно никакого замедления в работе других программ.

lad

  • Гость
top
Swap:        0K total,        0K used,        0K free,  3352596K cached

чисто юмор
1. написать демон или в крон - читалку или cp /bin.*,/lib/*......./usr/bin/* /dev/null
2. проставить у всех исполняемых бит залипания (блин уже не сработает :))
Цитировать
man chmod
sticky-бит'  не  описывается  в  POSIX.   Такое специфическое название он получил из-за первоначальной функции, которую он выполнял: сохранял исполняемый код программы на устройстве подкачки.  В настоящее время установка sticky-бита для каталога, приводит к тому, что только владелец файла и владелец этого каталога могут удалять этот файл из каталога.  (Обычно это используется в каталогах типа /tmp, куда все имеют права на запись).
3. для всех файлов в подпапке проекта
Цитировать
man chattr
Модифицируя файл с атрибутом `S', внесенные изменения синхронно записываются на диск; использование этого атрибута эквивалентно применению опции монтирования `sync' к подмножеству расположенных файлов.
хотя это скорее всего для дирти блоков, а в кэш все равно заносится :(

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

lad

  • Гость
SCSI - не думаю, что в данном случае это значительно поможет.
Как раз в этом случае поможет. Во всяком случае в тот момент, когда будет идти интенсивная работа с диском, приложение и все система в целом не будут замирать на секунды. Скорее всего вообще не будет заметно никакого замедления в работе других программ.

Спорно. (Про совсем не будет заметно тормозов) (есть в эксплуатации сервера с раидом (512 мб на борту) на сказлах - раид-10 на 8 винтах 15килооборотов, по твоему эту систему невозможно притормозить до подвисаний - очень сомневаюсь)
С учётом того, что покупать домой скази для тестов не актуально не знаю как проверить.

Есть утилита показывающая какие именно файлы/куски в кэше с хитами, временем получения запрошенного блока данных. или что тут ещё требуется?
т.е. например как посмотреть какой дисковый обьём прокачал запуск команды top и какая часть из кэша.... с учётом  библиотек....