Работа с гигантскими файлами в Windows 7, загадка

В общем задачка не тривиальная вылезла, условия таковы:
Для восстановления информации с поврежденного HDD произвожу вычитывание этого диска в бинарник. С целью потом этот бинарник копать, а железяку отправить в утиль.
Размер диска 1.5 TB, соответственно бинарник получается размером 1.5Тб.
Поскольку разделов и дисков у меня больше 1Тб нет я взял парочку дисков по терабайту, загнал их в RAID0 под Win 7 x64. Получил раздел 2Тб.
Вычитал примерно 80% инфы и тут начались странности. На каком то этапе система и программы отказываются писать в бинарник размером более 1TB.
Вешается софт или вылетает.
Что пробовал
1. Пробовал читать напрямую из под винды, результат при определенном этапе вешается софтина, причем 100% вешается не по причине читаемого диска, проблема именно на уровне софта.
2. Пробовал поднять виртуалку, прокинуть диск туда, запустить читалку и писать на примапленный из винды раздел, та же картина.
3. Расшарил папку с требуемым файлом, собрал второй комп, поднял там убунту, примонтировал шару запустил слив раздела в папку по сети. Только что выбило с ошибкой записи дескать проверьте может диск полный. Записало 1.1 TB
4. Подозревая что может рэйдовый раздел ошибки имеет пробовал читать разные зоны диска, соответственно писать в разные места файла, ситуация аналогичная.

В общем перепробовал все, напрашивается мысль, что проблема связана именно с SMB протоколом размерами файла и файловой системой.
Диск куда пишу с разделом NTFS.

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

Это сообщение отредактировал MPR - 13.04.2017 - 21:57

Может это из-за диска похеренного? Он не может больше данные отдавать?

Не бейте меня по голове сильно, но попробуй liveCD линуксовый. Есть дистры заточенные для бэкапов (гугль помощь).

Было подозрение, что битый диск уходит в стук или в аут и вешает прогу, стал мониторить диск, диск читабелен, а прога висит или вылетает. Прог использовал несколько, как под виндой так и под линуксом, новые советовать не надо, тут проблема сугубо не в программах, проблема в размерах файла и особенностями работы с ним.
Скажем если файловая система поддерживает хранение файла 2Тб это еще не значит, что винда может дописывать в этот файл, это немного разные вещи.

Ну размер файла для НТФС понятно что до 16Тб.
Майкрософт вроде явных ограничений на размеры фалов не указывает для операционок (хотя, как вариант можно попробовать серверную ОС воткнуть)

Рэйд программный или аппаратный ? может в этом дело (сменить программный на железный или наоборот).

Еще хорошо бы нагрузку на железо мониторить во время работы с файлом.
Если диски тупят при обращении к ним программа может недождаться данных и выпасть с ошибкой. Может дискам плохеет, может кэширование, ОЗУ, драйверы на мамку в конце концов.

немного не в тему:
Помнится, что при скачивании торрентов по 50+ Гб через пару минут после начала закачки тормоза бывают - связано с 100% загрузкой диска... тупить может полчаса потом нормально. лечится комплексно - наращиваем озу, увеличифаем файл подкачки, включаем кэширование на дисках, перед закачкой пустой файл с таким же именем создаём.

ядро что у серверной что у обычной одинаковое имхо

рейдов мешка у меня нету, программный ессна

нагрузки нет, ошибок рейда нет по монитору, в логах чисто

вываливается там где читаемый диск не тупит, проверял

при чем тут драйверы если логика страдает по симптомаматике

MPR, чего именно ошибка - оно тебе надо? Копать можно до усёру.
Скорее всего "тупит" программный райд. Он в сою очередь зависит как от ядра, так и от оперативы, файла подкачки и т.д.
Если ты поднимешь райд на другом железе, будь то нас или просто комп отдельный, то пройдёт такой слив.
А в пределах одной железки нужно рулить оперативой, что муторно и не стоит того, кроме как для диссертации.
Если уж так сильно хочется, то делай побитовое копирование в архив частями. Потом архив на райде соберёшь в кучу.

Ооох, ну тут то вам чего надо? Я уже все понял, на роль нострадамуса вы не сгодитесь.
Копаю я именно потому, что теоретически предполагаю возможность в критическом случае заюзать диски виртуальных машин по SMB, так вот эта особенность (если она вообще имеет место быть) может сэкономить нескольок дней эпли.
Программный рейд от чего бы не зависел, использует он ресурсы весьма скромно если он стрипит или зеркалит, более того он ничего знать не знает про файловую систему и соответственно про размеры файлов в рамках этой файловой системы.
То есть уровень на котором драйвер рэйда функционирует, не оперирует понятиями файл и каталог, он оперирует логическими блоками и секторами. Соответственно неисправность рэйда (если она имеет место быть) не будет зависеть от размеров файла.
И я не спрашиваю как мне скопировать, все это отлажено и решаемо, вопрос стоит как создать файл размерами больше терабайта и почему читается он без проблем, а писаться при размере выше терабайта толком не хочет.

MPR, ишь, как у тебя гонору-то поубавилось за сутки.
Советую почитать сначала, как работают программные райды. А так же про SATA.
Хотя... ты же и сам всё знаешь))

Программный рейд, еще и страйп... верх оптимизма!

Хм... Что за "софтина", во-первых, во вторых - явно что-то не то с образом
проблемного диска, и -

Это сообщение отредактировал Zwieback - 18.04.2017 - 01:51

удалил, невнимательно прочитал первый пост, версия не катит

Это сообщение отредактировал ТриТанкиста - 18.04.2017 - 01:59

ниасилил

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

вместо RAID 0 нужно было JOBD поднимать
программно он работает лучше

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

Это сообщение отредактировал Hexuss - 18.04.2017 - 01:58

Еще версия (не моя)
Возможно, в пуле памяти ядра не стало хватать места для обеспечения операции копирования. Лечится это, к сожалению, только перезагрузкой.
Для профилактики следует проследить за изменением размеров пулов памяти ядра (с помощью счетчиков производительности в Системном мониторе или через вкладку Быстродействие Диспетчера задач). Если имеет место постепенное неуклонное увеличение одного из пулов памяти, следует искать, в каком драйвере происходит утечка, с помощью утилиты poolmon (если ее нет в самой системе - ищите ее в Support Tools).

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

ТС, читай на линуксовой машине, dd тебе в помощь и bs поставь равным размеру кеша. Ну или dd_rescue, если хочешь видеть прогресс.
Потом расшаришь образ по сети и натравишь на него хоть р-студию, хоть еще кого. Блдее того - если диск не проблемный, то можно будет примонтировать разделы прямо из образа:

Хм, может действительно бэд завелся на одном из рэйдовских винтов, надо смарт глянуть.
Что вспомнил, если заливал по сети из под линуха в сетевую шару семерки, то линь как раз ругался на невозможность записи. При этом сразу после сбоя можно писать файлы туда, все пишет не ругается. А как начинаешь дописывать именно в большой файл, как будто ограничение какое то, сразу вылет с ошибкой "не могу записать проверьте права"

О как! Ну тут я хз, у меня файлопомойка тож под линухом. Чего и вам советую))

На компе с шарой загляни в журнал системы, обычно input/output error пишутся в лог. Да и сама ОС тебе бы сматерилась на ошибку ввода/вывода на устройстве ХХХ, хоть и винда

Это сообщение отредактировал MadNigra - 18.04.2017 - 02:37

MadNigra, вряд-ли он знает что такое кеш и архитектура.
Может и слышал, конечно.

MPR а если сетевую шару сделать в ext4 и на линухе, и копировать тоже из линуха?

Это сообщение отредактировал ТриТанкиста - 18.04.2017 - 02:41

Вы я вижу человек вменяемый, поэтому не понтов ради, а в качестве дружеского совета или обмена опытом:
dd хорош когда винт не сыплется, если же есть запилы со стуком в нескольких местах dd дойдет до этих мест и начнет насиловать винт, время вычитывания резко вырастет, после суток стучания бошками винт убьет себе головы, завалит G-list бэдами и ничего вычитать не получится.
Для задач связанных с именно вычиткой даты с поврежденного накопителя под линем существует ddrescue.
Главное отличие программы от dd в том, что алгоритм готов к вышеуказанной проблеме. Логика работа примерно такая
Натравливаем на винт с которого читаем, указываем куда сливать и где писать лог. Далее софт начинает читать то что читается, плюет на таймауты и прыгает на N секторов в случае ошибки чтения, задача слить то, что читается быстро и устойчиво. Все пропуски летят в лог.
После прохода по диску до конца закрывает лог и выпадает в консоль(если где то сорвались в стук и зависли перегружаем комп и стартуем прогу заново указав те же параметры, она по логу продолжит)
После первого прохода, правим ключи и натравливаем на вычитку остатков и пропусков, она их сама может в обратку пройти если случаи не сложные, если сложные то я обычно викторией выясняю размеры дыр и корректирую лог.
После двух проходов обычно больше с винта не вычитать, при этом 90% инфы получаешь очень быстро.
Как то так. логику работы описал весьма кратко, там есть нюансы и весьма толковый man.

Там еще и реверсивное чтение есть ;)
В общем удачи тебе, а я спать пойду, бо 6-й час утра уже.

Что-то не так с биосом мамки или биосом райд-контроллера. Обнови их.
Старенький пенёк-4 на 478-м сокете запросто работал с NTFS-винчом на 2Tb, и прописывал на него непрерывные файлы по 1,8 Tb. Без райдов, в-одиночку!
Другое дело, если винч объёмом более 2Tb, тогда на 478-м он не хочет работать вообще, ограничение биоса и нового взять неоткуда. Зато работает вторым винчом под форточкой (от ХР начиная и новее) в режиме GPT. Размеченным по сей технологии.
На более новых матплатах GPT можно устроить "прям из биоса", чем и стоит воспользоваться.

В качестве тэста, используй на райде некую прогу, записывающую всю ёмкость диска. Типа - затирание старой инфы. Такая функция есть, например, в проге ccleaner, а я когда-то писал собственную, ещё во времена DOS-а. Смысл этих прог: они создают ОДИН большой файл, куда пишут тестовый паттерн, пока не исчерпают всё свободное место на диске. Это позволит протестировать целостность записи на твой райд.
Да, заранее отключи в форточках всякую индексацию райдового диска, всякую мусоросборку с него и прочие службы форточек, занимающие разом до 20% пространства носителя.

Если один из винчей райда имеет сбойный участок - райд будет спотыкаться на нём! Включи логирование райда и погляди отчёт. Возможно, диск придётся заменить.