0
На диске, куда качает eMule, пропадает место
Автор
kraleksandr
, 31 дек 2011 10:20
Сообщений в теме: 11
#1 OFFLINE
Отправлено 31 Декабрь 2011 - 10:20
eMule находится и скачивает на внешний жесткий диск с файловой системой NTFS+сжатие. При скачивании хотя бы одного файла (со скоростью около 100 кбс), свободное место на диске уменьшается примерно на 5 мегабайт в секунду. Если, закрыв eMule, отмонтировать диск и подключить его заново, то все "неправильно пропавшее" место вернется. Почему так происходит?
#2 OFFLINE
Отправлено 31 Декабрь 2011 - 20:25
За 11гб скачанного за 6 часов, с диска съелось около 60гб места.
#3 OFFLINE
Отправлено 31 Декабрь 2011 - 21:21
а после завершения скачивания место возвращается или нет?
#4 OFFLINE
Отправлено 01 Январь 2012 - 00:05
Вроде бы да, как удастся проверить, напишу.
#5 OFFLINE
Отправлено 01 Январь 2012 - 01:42
Неа, не возвращается. Возвращается после перемонтирования диска.
#6 OFFLINE
Отправлено 01 Январь 2012 - 04:34
kraleksandr (Jan 1 2012, 01:42) писал:
Неа, не возвращается. Возвращается после перемонтирования диска.
давно не работал с компресными дисками в винде. но помнитцца что врала она безбожно. попробуйте записать туда без перемонтирования какой нито архив размером больше чем free space ... но именно архив. сжатый уже. помницца что получалось :)
#7 OFFLINE
Отправлено 01 Январь 2012 - 08:08
извините, что встряну..
имхо давно пора отказаться от всякого рода "сжатий" (если только диск, куда скачивает еМул, не используется под хранилище каких-то ещё данных, сильно поддающихся сжатию). Ибо в Мулосети (опять-таки глубоко имхо) сейчас всё и так уже всё сжато оптимально (видео: avi-шки и mkv-шки и так уже сжатый формат, аудио: мр3 и упакованное лосслесс - тоже). Экономия места - мизерная, а шанс потери данных имхо выше, чем без всякого "сжатия"...
имхо давно пора отказаться от всякого рода "сжатий" (если только диск, куда скачивает еМул, не используется под хранилище каких-то ещё данных, сильно поддающихся сжатию). Ибо в Мулосети (опять-таки глубоко имхо) сейчас всё и так уже всё сжато оптимально (видео: avi-шки и mkv-шки и так уже сжатый формат, аудио: мр3 и упакованное лосслесс - тоже). Экономия места - мизерная, а шанс потери данных имхо выше, чем без всякого "сжатия"...
#8 OFFLINE
Отправлено 01 Январь 2012 - 12:53
Диск размером 100гб, временный файлов на 167гб, средний размер файла 1гб. Без сжатия никак...
#9 OFFLINE
Отправлено 01 Январь 2012 - 16:59
NeByvalyi (Jan 1 2012, 08:08) писал:
извините, что встряну..
имхо давно пора отказаться от всякого рода "сжатий" ...
имхо давно пора отказаться от всякого рода "сжатий" ...
вот полностъю согласен.
и с тем что виндовое "realtime" сжатие плохо само по себе - так-ж. и применимо только в особых случаях сильно разряженных документов (тексты (и соотв. все xml, чистый html к примеру), .dwg, и прочее подобное) - опять-ж Леонид об этом и говорит.
Более того - были давно поставлены тесты, показавшие что к примеру rar с максимальным сжатием, подвергнутый мелкосовтовскому реалтайм сжатию - займет больше чем исходный rar. причем чем больше размер - тем заметнее будет разница (это вообще говоря вполне математически закономерно, не буду углубляться, но это так - на самом деле можете проверить даже попыткой сжать хороший rar скажем старым arc или подобными архиваторами). Возможно Вы это и наблюдаете (хотя помнится разница была не на столь велика как у Вас, но правда это было на заре появления алгоритмов реалтайм сжатия от M$, многое наверняка поменялось).
так что Леонид на 100% прав.
#10 OFFLINE
#11 OFFLINE
Отправлено 02 Январь 2012 - 19:32
Может быть речь идёт не о сжатой отдельной папке, а всём сжатом диске? И "свободное место", которое уменьшается непомерно быстро, тоже, не реальное, а "сжатое"? Точнее не реальное физическое место, а как-бы пересчитанное с коэффициентом сжатия (средним по всему диску)? Тогда было бы понятно: мул качает кусок файла, он сжимается плохо, занимает реальный гигабайт на диске, а "свободное место" уменьшается на 5 гигабайтов - потому что на этот занятый гигабайт места можно было бы положить 5 гигабайтов хорошо сжимающихся файлов (по мнению винды) ...
Надо бы приложить информацию (или скрин-шоты) реального свободного места на диске, которое без сжатия, до и после закачки скажем гигабайта информации мулом. А то если диск 100ГБ, а папка мула уже 240ГБ, то не совсем понятно сколько же свободного места на диске, которое уменьшается? Может его тоже, не 60ГБ (100 диска - 40 у мула), а скажем 500ГБ? :-) Тогда оно может и быстрее уменьшаться, не только 5:1, а и 100:1 ...
PS. Мораль проста: надо понимать отличие реального свободного места и виртуального (сжатого). Впрочем и занятого тоже.
Надо бы приложить информацию (или скрин-шоты) реального свободного места на диске, которое без сжатия, до и после закачки скажем гигабайта информации мулом. А то если диск 100ГБ, а папка мула уже 240ГБ, то не совсем понятно сколько же свободного места на диске, которое уменьшается? Может его тоже, не 60ГБ (100 диска - 40 у мула), а скажем 500ГБ? :-) Тогда оно может и быстрее уменьшаться, не только 5:1, а и 100:1 ...
PS. Мораль проста: надо понимать отличие реального свободного места и виртуального (сжатого). Впрочем и занятого тоже.
#12 OFFLINE
Отправлено 02 Январь 2012 - 20:28
я на старой машине таки жал раздел D не один год, ибо там было реально мало места (что-то ок. 55 Гб. при общем объеме жесткого в 80) и приходилось бороться за каждый мегабайт.
таких фокусов при этом не видел, осёл на D работал постоянно... т.ч. само по себе сжатие тут ИМХО непричём.
Сжимать перестал как ценник на харды стал более оптимистичным, больше этим не занимаюсь...
таких фокусов при этом не видел, осёл на D работал постоянно... т.ч. само по себе сжатие тут ИМХО непричём.
Сжимать перестал как ценник на харды стал более оптимистичным, больше этим не занимаюсь...
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных