Жжоте, товарищи))
И аффтар тожо)

Заводы стоят) все админы гитаристы)

[em]тяжелее баттерфляя, лично мне, режим сложно представить, может от жизни отстал, krotov поправит, если что[/em]
Звиняйте, я в этот бред вписываться отказываюсь. Я только алкоголь из стимуляторов упортебляю, ничего больше.

посе иных batterfly-тестов винты летят, нагрузка на механику максимальная)

42-krotov > ну, насильно мил не будешь, пей йод)
43-droidman > на полтора часа нестрашно, а шлепнется - туда ему и дорога, лучше раньше, чем позже

не далее чем вчера вечером, бэкапы своих архивов делал. весь процесс занял часов 6. увы и ах, корпус у меня обычный средней поганости и без кулеров для винтов, в котором 4 винта почти друг на друге + 2 больших винта для бэкапа снаружи повесил. 1 стенка снята была. интересу ради поставил мониторингом Эверест. потолок температуры был 51 градус на 2-м или 3-м винте из внутренних, остальные не выше 47 градусов. насколько знаю, для винтов нежелательна работа в длительном режиме с температурой выше 60 градусов, это ведет к довольно быстрой деградации этих винтов. а некоторые тут издеваются и под 90 градусов их убивать пытаются. понятно, что если есть лишние деньги то убивайте свои винты на здоровье. у меня лишних средствов на покупку новых винтов не имеется, да и нет ни малейшего желания тратиться на покупку новых после их прошлогоднего подорожания. цены в прошлогодний уровень вернутся дай бог к концу 2014-го года, по прогнозам

на тему копирования большого количества файлов. понятно что лучше все упаковать в архивы, быстрее сливаться инфа будет. но часты случаи, когда нужно 1:1 перегнать такие данные. имеется конфа с 16 гигами рамы и система 7 х64, антивирусы отключены для чистоты эксперимента. сейчас попробовал типичную папку i386 из инсталляхи хр размноженную до размера в 5 гигов, мною был убран большой файл driver.cab, в несколько копий послать в разные папки одного винта. и... с каждым новым процессом копирования общая скорость падала примерно раза в 2. при 50 процессах копирования переключение в бразуер с этой страницей было проблематично из за тормозов. Теперь тот же эксперимент с копированием по локалке в 100 мегабит на комп с аналогичными характеристиками. при посылке 10 потоков скорость всех потоков упала до средних 30-50 кб/сек на поток. ну его нафих этот эксперимент, неблагодарное это дело

45-MCMXCAD > [em]нежелательна работа в длительном режиме с температурой выше 60 градусов[/em]
от модели зависит у "старых" потолок был 50
WDC WD5000AAKX-001CA0 говорит вот что
Min/Max recommended Temperature: 0/60 Celsius
Min/Max Temperature Limit: -41/85 Celsius
но это все фигня, отдельные продвинутые товарищи нам расскажут про арсенид галлия

47-gloomymen >Min/Max recommended это в режмие работы, Min/Max Temperature Limit: скорее всего в режиме хранения. у мну винтам года по 2-2,5, модели от WD и Hitachi, размером от 1 тера до 3 тер

вот и проверьте на досуге
smartctl -l scttemp /dev/sdX

49-gloomymen >друх я в линухах увы ни разу не разбираюсь и не горю желанием моск ломать ими

50-MCMXCAD > штатный порт smartmontools имеет место быть
я вам ни разу не [em]друх[/em], что за свинство?

51-gloomymen >человек человеку в интернете друх, товарисч и брат :)

Parafoil - заводы не стоят, сундуки, правда - да... стоят раскрыты - но заводы все равно дорожают. Значит гитара - не помеха... Воксовый "плуг" неделю назад получил, "басс" - ждал, правда, три(!) месяца - слава российской почте и EMS. Упаковка - после переезда танком, бумажки залиты чем-то вроде рассола из под рыбы, вонь всекитайская - но устройство РАБОТАЕТ! Чудес не ждал, но почти впечатлило. Сустейнит на безладовом круче B1-серии зумов, причем полный порядок с наводками/фоном. Недельку поиграемся - и вскрою...
...
gloomymen - дык я-ж не человек, а добрый бот, в смысле призрак пана-директора. Оправдалово "эксплуататоров"... Потому априори мог обжечь не только тыльную сторону ладоней. А потом как ни в чем на бывало - поститься на Форуме...
...
GaAs - дык это ж для солнечных артиллерийских батарей отопления! Чувствую пятница незыблема... Прошу не забывать про 22:30. "На нас напали злые чехи, село родное подожгли" (с) Народ. Но в русской песне с этими словами есть и надежда - село-то наше... до сих пор.

понятно что бот, понятно что добрый, но брехливый
сам пошутить люблю, грешен, а брехуны мне не нра

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

[em]30-gloomymen >
[b]28-Перпетум Мобиле >что будет происходить с бошками винта при двух потоках копирования.[/b]
ничего страшного не будет, все будет штатно, последовательно и вполне неторопливо[/em]
Ох, я в этом очень и очень сомневаюсь. Дело в том, что блоки (сектора) распределяет не контролер винта, как сказал товарисч выше, а непосредственно конкретная ФС.
Конечно, может быть какая нибудь линусовая ФС, при массовом копировании все правильно распределяет и дефрагментация там нафиг не нужна, а вот NTFS так не умеет. И все будет происходить так, как описано в 28.

[em]>> какая нибудь линусовая ФС, при массовом копировании все правильно распределяет и дефрагментация там нафиг не нужна[/em]
Хотя я в этом тоже сомневаюсь)

Чтобы там не говорили злые языки про Linux и его никчемность в больших и малых офисах - его можно уважать и юзать только за одно право - право выбора файловой системы "под задачу".
...
От изобилия ФС (как и от дистров самого линя) тошнит, но если погуглить, а потом и самому потестить - наступает просветление и желание таки выделить сервачок под некие задачи.

[em]ФС... все правильно распределяет[/em] - да, это есть и причем каким-то странным образом, в зависимости не только от кол-ва и объема файлов, но и, видимо, на основе неких указателей и оптимизационных алгоритмов при записи внутри одного большого файла. Однофайловых задач в жизни довольно много, те же архивы, простые и не очень СУБД типа Access, FireBird, SQLite, видеофайлы, мультитрековые файлы итд.

Вот к пример, классическое сжатие 2GB файлов особого различия между ФС не дает (его просто нет):
[img]http://www.phoronix.com/data/img/results/ext4_btrfs_nilfs2/1.png[/img]
От себя добавлю что NTFS ведет себя примерно также.

Но стоит уйти от синтетических. "чисто архивных" тестов к чему-то более интересному - картинка меняется. Все знают СУБД SQLite и что он вытворяе при разделенном файловом режиме в сетях Windows. Инсерт блокирует весь файл, читать из него в этот момент нельзя, и это довольно сильно грустит, т.к. блокировки SMB вещь загадочная и почти неуправляемая (так говорит мой сетевик). У меня в одну мега-базу SQLite льется все и отовсюду: из 1С-ок, MSSQL, PostGree, TSV и еще нескольких источников, и столкнувшись с неимоверными трудностями, уже было похоронил саму идею сделать систему, знающую ответы на все вопросы. Особенно после прочтения rtfm, что в сетях NFS юзать SQLite вообще не рекомендуется. Но тут попалась вот такая картинка:

[img]http://www.phoronix.com/data/img/results/ext4_btrfs_nilfs2/3.png[/img]

То есть одна пара ФС дает 20 секунд на запись, другие - тысячи секунд. Разница в 50(!) раз. Проверили - почти так и есть, +/-. Причем NTFS дает те же тысячи секунд. Если бы не лень - оформил бы статейку, но быстро понял что на уровне написать ее не смогу. Задачу слива данных по результатам проверки перенесли на Linux-сервер с допотопной убунтой и EXT3 и саташным массивом, где питоновские скрипты по импорту данных, перенесенные с Win-тачки заработали почти без правки (пути в основном и строки подключения). Теперь синхронизацию делаю не только ночью, но и 3 раза в день, блокировка возникает на 2-3 минуты вместо получаса. Система ожила, стала интересна людям, появилось у некоторых понимание - нахрена спешка и столько данных вводить ручками, поскольку результат виден быстро. Скоро попробую массив из SSD, хочется чуда.

[em]И все будет происходить так, как описано в 28[/em]
не будет, [u]куда[/u] писать принимает решение фс, [u]как[/u] писать решает контроллер

>> какая нибудь линусовая ФС, при массовом копировании все правильно распределяет и дефрагментация там нафиг не нужна
> Хотя я в этом тоже сомневаюсь)

в те времена когда я часто ходил в серверную и не использовал openvz приходилось часто наблюдать работу fsck при загрузки серверов (типа прошло xxx дней и пора провериться). Обычно в его отчетах фрагментация была 3-5%, редко до 10 и один раз больше 10% на ФС с кэшем активно работающего сквида.

Сейчас в виндах глянул диск С:, который иногда дефрагментируется, там 29%.

crazy_ik, вам наверное сгодится [url]http://freefilesync.sourceforge.net[/url] , как (всегда:) правильно заметил тов. droidman
а задрочить диск через дырку в 100Mbit, простым копированием у вас не получиться

[em]не будет, куда писать принимает решение фс, как писать решает контроллер[/em]
А если LVM используется? Какие он принимает решения?

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

Запись, чтение...
А копирование будет с заменой или новых?
Я, конечно, не знаю теории и не имею секундомера, но сдаёцца мне, что это разные задачи.
Кто грамотный, просвЯтите, плз...

64-ТОРМАЗ > ну удаляецо вседа на порядок быстрее чем записываецо) разишо еси куча маленьких файлегов - там время на удаление практически равно времени на создание/запись

кстати, вчера с пьяной рожей уронил вентиляцию, заметил только что, проверил температуру на всех 4-х, от 46 до 48