Операция файловой системы заняла больше времени чем ожидалось
Я запускаю Visual Studio 2012 на Windows 8 64bit. У меня есть 64-разрядный проект, который находится в исходном элементе управления, и я пытаюсь запустить его дома на своем компьютере под управлением Windows 8. Приложение успешно работает, однако удаленный отладчик не работает вообще.
В нем говорится: "Удаленная операция занимает больше времени, чем ожидалось". Я понимаю, почему его удаленный, будучи 32-битной Visual Studio, должен получить доступ к msvsmon.exe для отладки через 64-битные приложения, но я никогда не видел, чтобы это происходило на локальной машине, где был извлечен исходный код.
Я попытался переустановить Visual Studio 2012, играя с портами (4016), а также запуская как admin. Проверено, что VPN не является проблемой при удалении клиента.
Теперь у меня нет идей. Я попытался создать новый локальный проект для тестирования и установить его как 64 бит, но операция все равно не удалась.
Любые идеи или предложения? Это известная проблема с Visual Studio 2012 в Windows 8?
ОТВЕТЫ
Ответ 1
Думаю, вам стоит попробовать:
- Запустите cmd.exe как администратор.
- Введите и выполните следующие две строки:
netsh winsock reset catalog
netsh int ip reset reset.log hit
- Он может сказать, что требуется перезагрузка, но на самом деле это необязательно.
- Попробуйте снова отладить ваше приложение, проблема должна быть решена.
EDIT: Извините, что не объяснял это раньше. Ответ на самом деле пришел с китайского форума, и автор оригинала этого не объяснил. Но он сказал, что это потому, что Visual Studio представляет собой 32-битную программу, которая может иметь проблемы с доступом к сети под 64-разрядной Windows 7, и вышеупомянутое решение сбрасывает сетевое соединение, поэтому решает проблему. Надеюсь это поможет.
Ответ 2
Единственный ответ, который я получил для работы с VS2012, - это перейти в свойства Project > Compile > Target CPU и установить параметр "x86".
Это также похоже на этот вопрос: Не удается запустить отладчик в VS2012 RC Они также представили это в Microsoft Connect. Кажется, это проблема Visual Studio.
Ответ 3
Ответ 4
Только мои два цента,
Я уже дважды сталкивался с этой проблемой, и это оказалось после всех предложений, которые я пробовал, это был BitDefender на моей локальной машине, которая это делала. Поэтому я исправлю эту проблему, чтобы попробовать добавить исключения в локальное программное обеспечение и AV его частей. Скажите ему, чтобы игнорировать msvsmon.exe и devenv.exe в целом и посмотреть, какая разница.
В противном случае попробуйте полностью отключить его и посмотрите, позволяет ли он отлаживать ваше решение.
Я установил последнюю версию BitDefender, и все было в порядке для меня.
Ответ 5
Решение для меня в VS 2015. У меня была запись публичного DNS, сопоставленная с моей локальной iis и вкладкой веб-отладки проекта:
Просто нужно было добавить это в файл hosts как локальный хост:
Таким образом, VS больше не считает, что хост является удаленной машиной.
В этой статье рассказывается об устранении предупреждений о неполадок с ИД 1020 на файловом сервере.
Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4562940
Симптомы
На сервере Windows на сервере вы наблюдаете предупреждения event ID 1020 от SMB-Server в журнале событий Microsoft-Windows-SMBServer/Operational:
Вы также можете наблюдать:
- Проблемы с производительностью для клиентов, работающих с этим файл-сервером.
- Проблемы с подключением для клиентов, работающих с этим файл-сервером.
- Проблемы с производительностью для приложений или других компонентов, которые работают локально на этом файловом сервере.
- Кажется, что сервер файла перестает отвечать.
Причина
Эта проблема возникает из-за того, что файловая система занимает более 15 секунд (пороговое значение предупреждения по умолчанию) для завершения I/O с файлового сервера.
SMB Server столкнулся с застопоримой I/O. Это указывает на серьезные проблемы с подкладкой файловой системы вместо самой SMB.
Для хорошего выполнения файлового сервера мы ожидаем однозначные миллисекундные время отклика от его файловойсистемы.
Точную продолжительность задержки, а также командный код SMB, который столкнулся с задержкой, можно получить из события. Список командных кодов SMB2 можно найти на уровне 2.2.1.2 SMB2 Packet Header - SYNC.
Задержки файловой системы в размере нескольких секунд могут быть вызваны неправильно функционируют драйверами фильтра файловой системы.
Другие возможные причины включают серьезные проблемы с производительностью физического хранения, включая:
- перегрузка физических дисков
- длительные операции замораживания дисков, такие как операции, выполняемые VSS или другими решениями резервного копирования
- стек сети и хранилища наложенного гипервизора
- сетевые подключения к хранилище
- san/NAS/служба хранилища-appliance
Задержки файловой системы ниже 15-секундного порога не создают предупреждающих событий, но по-прежнему наносят ущерб производительности файлового сервера.
Сбор журналов трассировки
Для дальнейшей диагностики того, возникает ли проблема из операционной системы Windows (например, драйверов фильтрации) или извне (например, оборудования, гипервизора, сети, хранилища), возьмите след Storport и проверьте время отклика на диск с помощью таких средств, как StorPortPacman. Следы StorPort в нижней части Windows служба хранилища стеком, а файл или любое другое приложение сталкиваются с задержками в верхнем конце стека. Дополнительные сведения о средстве StorPortPacman см. в расшифровке следов Storport 101 и StorPortPacman.
Если вы наблюдаете максимальное время отклика на уровне StorPort, это указывает на то, что причина проблем с производительностью находится за пределами операционной системы. Чтобы узнать, какие задержки система сталкивается с логическими дисками на уровне приложения (файлового сервера), можно включить трассировку Perfmon или WPR. Это также показывает задержки ниже 15-секундного порога предупреждения. Дополнительные сведения см. в этой ссылке Измерение задержки диска с Windows монитором производительности (Perfmon).
Сбор свалки ядра
При крайних задержках (10 или более минут) и при некоторых других условиях файл сервер будет пытаться создать живую свалку ядра для устранения неполадок.
Создание сброса регистрируется двумя событиями в Microsoft-Windows-SMBServer/Operational Eventlog:
- Событие 1031. Сервер обнаружил проблему и запечатлел живую свалку ядра для сбора отлаживаемой информации.
- Событие 1032. Сервер обнаружил проблему, но не смог захватить живую свалку ядра для сбора отлаживаемой информации.
Если свалка была успешно создана, ее можно найти под %SystemRoot%\LiveKernelReports и она чрезвычайно ценна для устранения неполадок.
Дополнительная информация
Задержки отдельных операций могут накапливаться до огромных времен ожидания для клиентских приложений из-за нескольких операций, которые выполняются последовательно.
Кроме того, длительное время отклика на I/O может привести к проблемам с доступом к акциям и к остановке ответа на файловом сервере.
Другие приложения и компоненты, которые работают на этом сервере и имеют доступ к одной и той же файловой системе, также могут отрицательно повлиять на длительное время отклика. Эти приложения и компоненты могут не обладать собственными журналами или мониторингом для высокой скорости отклика на запросы.
WINDOWS 10 ЗАНИМАЕТ НЕМНОГО БОЛЬШЕ ВРЕМЕНИ, ЧЕМ ОЖИДАЛОСЬ ПРИ ОБНОВЛЕНИИ - ИСПРАВЛЯТЬ - 2021
Видео: Решение проблемы с кодировкой символов на сайте (UTF-8). Отображает иероглифы или знаки вопроса 2021.
Установка обновлений Windows по беспроводной сети может быть утомительной и настойчивой, но в большинстве случаев это быстрый и надежный опыт. Однако иногда, и особенно при крупных обновлениях (с Windows 7 или 8 до Windows 10), пользователи сталкиваются с различными критическими проблемами. Иногда возникают ошибки, а иногда возникают проблемы с бесконечными запросами на загрузку. « Это займет немного больше времени, чем ожидалось » - это место, где застряло множество пользователей.
Существуют различные способы решения этой проблемы. Если вы не можете пройти мимо экрана после нескольких попыток, мы обязательно предоставим вам решения и инструкции ниже.
Как устранить ошибку обновления «Это займет немного больше времени, чем ожидалось» в Windows 10
- Проверьте место для хранения и подключение
- Запустите средство устранения неполадок
- Удалите сторонний антивирус и отключите периферийные устройства
- Обновите систему с помощью Ассистента обновлений
- Обновите систему с помощью внешнего установочного носителя
- Выполните чистую переустановку
1: Проверьте место для хранения и подключение
Прежде чем перейти к решению, мы предлагаем подождать некоторое время. Многим пользователям удалось заставить обновления / обновления работать через некоторое время. Само собой разумеется, что это заняло часы. Это зависит от вашей пропускной способности и скорости жесткого диска, соответственно. Конечно, если после 2 часов ничего не произойдет, мы рекомендуем медленно перемещаться по списку. Кроме того, перезагрузка вашего ПК не нарушит процедуру, и, по словам некоторых затронутых пользователей, это может помочь.
- ЧИТАЙТЕ ТАКЖЕ: Как обновить до 10 апреля Windows Update на устройствах с ограниченным объемом
По сравнению с небольшими, частыми обновлениями, крупные обновления требуют много места. Сначала обновления загружаются в специальный каталог, а затем начинается установка. Убедитесь, что у вас есть как минимум 6-10 ГБ свободного места в системном разделе. Кроме того, мы рекомендуем проверить соединение. Даже после безопасной загрузки установочных файлов для некоторых последовательностей требуется подключение к Интернету.
После того, как вы подтвердите, что все в порядке, но задержка сохраняется, продолжайте с шагами ниже.
2. Запустите средство устранения неполадок обновления.
Следующий очевидный шаг - попытаться запустить средство устранения неполадок Центра обновления Windows, которое можно найти среди других инструментов в меню устранения неполадок. Если это не устранит ошибку, это, по крайней мере, даст вам лучшее представление о том, что вызывает проблему под рукой. После запуска инструмента он должен перезапустить службы обновлений и перезапустить загрузку файлов обновлений.
Вот как запустить средство устранения неполадок обновления в Windows 10:
- Нажмите клавишу Windows + I, чтобы открыть приложение « Настройки» .
- Выберите « Обновление и безопасность» .
Если вы все еще застряли на том же экране, переходите к следующим шагам.
3: удалить сторонний антивирус и отключить периферийные устройства
Следующее, что вы можете попробовать, касается сторонних приложений, которые чаще всего мешают процессу обновления / обновления. И это антивирусные решения. Они могут блокировать обновления системы или вызывать всевозможные проблемы во время вышеупомянутых процедур. Сообщество особенно относится к McAfee и Norton Antivirus, но, тем не менее, все остальные могут вызвать ошибки.
Кроме того, мы также предлагаем отключать периферийные устройства, такие как принтеры, сканеры или что-либо еще, кроме предметов первой необходимости. Основные обновления системы также имеют тенденцию устанавливать драйверы во время перехода. Это может быть проблемой, тем более что универсальные драйверы не всегда соответствуют рамке.
4. Обновление системы через помощника по обновлению
Поскольку стандартный метод обновления далеко не безупречен, мы можем посмотреть в другом направлении. Есть и другие способы обновить или обновить вашу систему до последней основной сборки. Первый в очереди - отличный инструмент, который, по крайней мере для меня, всегда работал хорошо. Во-первых, он позволяет получать обновления быстрее, чем обычно. Второй и более важный момент - он редко застревает. Более того, он проверяет возможные несоответствия совместимости, поэтому вы будете знать, пригодится ли доступное пространство для хранения.
Если вы не уверены, как загрузить и использовать этот инструмент, мы предоставили пошаговые инструкции. Проверьте их ниже:
5. Обновите систему с установочного носителя USB
Если предыдущий подход по какой-то причине подвел вас, есть еще альтернатива. Помимо Ассистента обновлений, Microsoft использует Media Creation Tool для распространения программного обеспечения. Вы можете использовать эту утилиту для обновления сразу или, что еще лучше, для создания установочного носителя. Для последнего вы можете использовать либо файл ISO и записать его на DVD, либо создать загрузочный флэш-накопитель USB. А затем обновить Windows 10. Это почти полностью устраняет системные ошибки, поскольку источник обновлений является внешним.
Это не такая большая проблема, и вы получите установочный носитель на случай, если что-то пойдет не так в будущем. Вот как создать установочный носитель и таким образом обновить вашу систему:
- Загрузите инструмент для создания медиа здесь.
- Подключите USB-накопитель объемом не менее 6 ГБ.
- Запустите Media Creation Tool и примите условия лицензии .
6: выполнить чистую переустановку
Наконец, если ни одно из предыдущих решений не принесло такого решения, мы боимся, что вам следует пересмотреть вопрос о чистой переустановке в качестве следующего шага. Это не самый предпочтительный результат, но если вы ничего не можете сделать, это должно помочь. Большинство проблем возникает, когда Windows 10 - это просто обновление по сравнению с Windows 7 или Windows 8, так что начинать с нуля может вам помочь.
- ЧИТАЙТЕ ТАКЖЕ: Обновление Windows 10 April сломало ваш компьютер? Вот как откатиться
Мы обязательно объяснили, как выполнить чистую переустановку. Также не забудьте сделать резервную копию ваших данных перед форматированием системного диска.
Это подведение итогов. Не забудьте поделиться своим опытом с этой ошибкой или предложить альтернативные решения, чтобы помочь делу. Вы можете оставить свой отзыв в разделе комментариев ниже.
Решено: расчет времени, необходимого для копирования файлов, занимает слишком много времени
Копирование файлов из одного раздела в другой или с внешнего носителя в локальное хранилище должно быть прогулкой в парке. Однако даже самые простые из всех операций могут иногда оказаться сложными. В некоторых отчетах пользователя Windows 10 утверждается, что экран «Расчет времени, необходимого для копирования файлов» занимает много времени или…
Windows 10 arm телефоны могут стать реальностью раньше, чем ожидалось
Новые приключения Windows 10 Mobile продолжаются, даже если он все еще находится в режиме обслуживания, и это было так уже довольно давно. Эта ситуация заставила многих пользователей Windows-телефонов задуматься о том, чтобы превратить свои телефоны в мобильные ПК, и вот что сработало. Пионером этой идеи является технический хакер Tmsix, который был .
Корпоративные миграции на Microsoft Windows 10 быстрее, чем ожидалось
Опрос, касающийся усилий по переносу корпоративных настольных и портативных систем на Microsoft Windows 10, показал, что эти миграции выполняются намного быстрее, чем предполагалось ранее. Еще в 2016 году другое исследование показало, что значительное большинство респондентов указали, что они только начали развертывать Windows 10. Эта конкретная группа .
ОС Windows долгое время попрекали за медлительность её файловых операций и медленное создание процессов. А почему бы не попробовать сделать их ещё более медленными? Эта статья покажет способы замедления файловых операций в Windows примерно в 10 раз от их нормальной скорости (или даже больше), причём способы эти практически не поддаются отслеживанию обычным пользователем.
А ещё, конечно же, мы научимся подобные ситуации обнаруживать и исправлять. Весь текст написан на основе проблемы, с которой я столкнулся пару месяцев назад, так что всё, написанное ниже, полностью реально.
Что-то пошло не так
Иногда наиболее ценной информацией, которая у вас есть при попытке что-то ускорить, есть само знание того, что это точно можно ускорить. Ну, знаете, как в школе — задача решается потому, что это задача, а значит у неё точно должно быть решение.
Когда дело касается кода, который находится полностью под вашим контролем — здесь проще. Можно сравнить быстродействие различных версий, покопаться, поговорить с его авторами, с какого-то этапа также начинает работать ведомая опытом интуиция.
Когда же речь идёт о «чёрном ящике», каким, например, является реализация файловой системы NTFS от Microsoft, становится сложнее. Но и здесь можно найти кое-какие подсказки:
- Вы замечаете, что некоторые файловые операции, которые раньше работали быстро, вдруг стали работать медленно. Вероятно, их можно снова заставить работать быстро.
- Одни и те же файловые операции иногда работают быстро, а иногда — медленно. Возможно, их можно заставить работать быстро всегда.
- При профилировании своего приложения вы видите хорошую производительность файловых операций в большинстве случаев, кроме нескольких «горячих» мест, где всё почему-то работает значительно хуже среднего. Возможно, вы можете изменить свой код так, чтобы избежать данной проблемы.
Медленное удаление файлов
Снова и снова собирая из исходников Chromium, я заметил, что очистка директории с результатами сборки стала занимать несколько минут — это довольно значительная часть цикла сборки. Я был уверен, что это должно происходить быстрее. Я также заметил, что данной проблемы не случается, если в момент удаления данных файлов не запущена Visual Studio.
Профилирование с помощью ETW не показало явного виновника происходящего, но дало несколько подсказок, которые привели меня к мысли, что дело может быть в VsChromium — расширении для Visual Studio, которое делает работу над проектом Chromium в Visual Studio несколько удобнее. Одной из важных его фич является загрузка всего исходного кода проекта в оперативную память (для дальнейшего быстрого поиска). В случае Chromium это несколько гигабайт RAM, но зато поиск работает за милисекунды. Мне это расширение очень помогает в работе, но десятикратное замедление файловых операций — не та цена, которую я готов за это платить.
Воспроизведение проблемы
Для написания данной статьи я сэмулировал проблему, написав скрипт на Python, который создаёт и удаляет тысячи файлов в папке, которая находится под наблюдением VsChromium. Запустив данный скрипт, я собрал трейс событий с помощью ETW. Вот график использования процессора в WPA (Windows Performance Analyzer) и таблица с временем (в милисекундах). Всего скрипт работал около 5 секунд:
Кажется обоснованным, что процесс python.exe, который выполняет мой скрипт, использует значительную часть ресурсов CPU. Также понятно, что процесс System тоже будет занят кое-какой работой, поскольку мы занимаемся добавлением и удалением файлов. Кроме того, мы видим в таблице работу расширения VsChromium, поскольку оно наблюдает за той самой папкой, в которой мы создаём и удаляем файлы, а значит должно реагировать на это (добавлять и удалять файлы из индекса). Ну и, наконец, SearchIndexer.exe использует немного ресурсов для индексации новых файлов. Вроде бы всё выглядит неплохо. И всё же — мы знаем, что код работает слишком медленно.
Вот, для контраста, график использования процессора в случае создания и удаления файлов в директории, которая не находится под наблюдением VsChromium. Производительность поднялась почти в 10 раз! Понятное дело, что загрузка от VsChromium.Server.exe и devenv.exe исчезла полностью, но на этом всё не заканчивается. Сам python, выполняющий мой скрипт, также стал работать намного быстрее (время выполнения скрипта упало с 4888 мс до 561 мс). Процесс System вообще ускорился с 2604 мс до 42 мс. Что же здесь происходит?
График CPU Usage (Precise), который основывается на информации о переключении контекстов, даёт хорошую возможность сказать, сколько именно процессорных ресурсов использует тот или иной процесс. Но чтобы понять, на что именно процесс тратит время, нужно воспользоваться графиком CPU Usage (Sampled). Он основан на «снимках» стека вызовов функций (по-умолчанию, сделанным с частотой 1000 раз в секунду).
Этот вид представления данных группирует данные по процессам, затем по потокам, затем по модулям и, наконец, по функциям. В данном случае для процесса python.exe мы видим, что в 4637 снимках из 4904 какая-то работа происходила в модуле ntoskrnl.exe. Это намного больше, чем время выполнения кода в python27.dll (им вообще можно пренебречь).
Углубляясь в исследование того, что делал ntoskrnl.exe, мы видим какие именно функции в нём вызывались:
Чаще всего вызывалась функция выделения памяти MiAllocatePagedPoolPages и функции очистки памяти memset, MiCompletePrivateZeroFault, а также ассоциированные с ними отказы страниц. Кажется немного странным, что в тесте работы файловой системы больше всего ресурсов занимают задачи выделения и очистки памяти, правда? Но подождите, это ещё не всё. Вторым по занятости в системе является процесс System, и занят он (чем бы вы думали?) обнулением только что освобождённых страниц памяти. Что же, всё-таки, происходит?
Вернувшись к анализу снимков колстека процесса python.exe, я поискал функцию memset и нашел её где-то на 70 уровней ниже по колстеку (не удивительно, что раньше я её пропустил). Правый клик на ней, выбираем View Callers-> By Function и видим, что общие затраты на её вызов (включая время выполнения «дочерних функций») составляют примерно половину всей загрузки процессора — 2971 снимок из 4904 сделанных.
Вызывающей функцией практически всегда была FsRtlNotifyFilterReportChangeLiteEx. Правый клик на ней, View Callees-> By Function. Это показало мне, что данная функция выделяла память, вызывала memset для неё и потребляла около 83% процессорного времени в процессе python.exe.
В поисках проблемы
В этом месте моего исследования у меня было несколько, как позже оказалось, неверных догадок. Одна из них касалась частых вызовов wcifs.sys!WcGenerateFileName — я подумал, что генерация имён файлов в формате «8.3» работает слишком медленно, но её отключение ничего не изменило. В конце-концов я остановил свои попытки постичь непостижимые колстеки и вместо этого задумался о том, как работает расширение VsChromium. При загрузке оно просто должно прочесть и загрузить в память всё содержимое файлов в контролируемой папке. Но после этого ему нужно всего лишь отслеживать изменения и я предположил, что оно имеет что-то типа монитора изменений файловой системы. Я знал, что расширение недавно получило обновление и в нём автор увеличил буфер, в котором хранились нотификации об изменениях файлов, с 16 KB до 2 MiB. И почему-то операционной системе это очень не понравилось. Я попробовал откатиться к предыдущей версии расширения (с меньшим буфером) — и это действительно исправило проблему.
Данный буфер выделялся с помощью функции ExAllocatePoolWithTag, а затем заполнялся информацией об изменениях в файловой системе. Для избежания утечки данных из ядра ОС, вся неиспользуемая часть буфера обнулялась. Если буфер достаточно большой, а объём пересылаемой информации относительно мал — обнуление будет занимать большую часть времени. Я добавил провайдер данных ALL_FAULTS (который я нашел, просматривая результат вызова “xperf -providers k”) к моей ETW-сессии чтобы увидеть как часто случались отказы страниц. И это было впечатляюще! Случилось 2,544,578 отказов страниц при попытках обнуления данных, что соответствует 9.7 GiB данных или около 4970 раз по буферу в 2 MiB. Это 4.97 буфера на каждую тысячу созданных и удалённых файлов. Мне подсказали, что VsChromium должен создавать около 5 событий на каждый созданный и удалённый файл, а значит большинство буферов с нотификациями будут содержать лишь одну запись. Вот отказы страниц по процессам и типам:
Зачем такой большой буфер?
Документация для FileSystemWatcher рекомендует не использовать большой буфер, но не вдаётся в подробности о том, чем это грозит. На машинах разработчиков Chrome достаточно много оперативной памяти, так что когда однажды очень частые файловые операции (баг в ядре Windows, о котором я писал ранее) привели к переполнению ранее использованного буфера в 16 КВ, его просто значительно увеличили. И это, на первый взгляд, помогло. По крайней мере тогда, для решения той проблемы. Хотя и замедлило файловые операции во много раз.
Когда автор расширения VsChromium узнал о проблеме, он решил уменьшить буфер обратно и обрабатывать ошибки его переполнения более изящно (временно приостанавливая мониторинг).
Ирония данной ситуации состоит в том, что большинство затрат ресурсов здесь (вызовы memset, отказы страниц, обнуление) случаются потому, что две разных части ядра ОС не достаточно хорошо общаются друг с другом. Система нотификаций запрашивает память, получает её (уже обнулённую) и снова пытается её обнулить. Если бы она знала, что память уже обнулена — то не пыталась бы сделать это во второй раз, и не было бы лишних отказов страниц, и жизнь была бы куда лучше. Эй, Microsoft, у меня есть классная идея о том, как сделать систему нотификаций об изменениях файловой системы лучше!
Вооружимся этим знанием
ETW-трейсы позволяют достаточно просто понять, что буферы для нотификаций являются проблемой — каждый процесс, выполняющий какие-то файловые операции будет показывать крайне много времени, потраченного в ntoskrnl.exe!FsRtlNotifyFilterReportChangeLiteEx. Это показывает, что кто-то использует очень большой буфер для нотификаций, но как нам найти процесса-виновника? Очень просто — поскольку память в нашем случае выделялась с помощью ntoskrnl.exe!ExAllocatePoolWithTag, то освобождаться она будет с помощью ntoskrnl.exe!ExFreePoolWithTag. Мы можем поискать вызовы этой функции в имеющихся у нас коллстеках и найти тот, где их много.
Другие полезные ссылки
Увеличение размера буфера в VsChromium случилось вот в этом коммите, который вошел в билд 0.9.26. Обратное уменьшение случилось вот в этом комите, который вошел в версию 0.9.27.
Я рекомендую всем пользователям VsChromium обновиться до последней версии.
ETW-трейсы и упомянутый в статье скрипт на Python можно скачать вот здесь. Он создаёт и удаляет файлы дважды, один раз в директории под наблюдением VsChromium, и второй раз в ненаблюдаемой директории, с полусекундной паузой. Для воспроизведения эксперимента из статьи вам, конечно, понадобиться соответствующая версия VsChromium, настроенная на мониторинг нужной папки.
А в следующей статье я расскажу о том, как Microsoft позволяет вам иногда случайно создать N процессов за O(N^2) времени.
Всем снова здравствуйте! Недавно (похоже, в связи с неожиданным отсоединением внешнего жёсткого диска) произошло, похоже, повреждение файловой системы. Теперь любые действия с подмонтированной ФС приводят к зависанию программы, проводившей выполнение действия, список файлов также подгружается бесконечно долго. Когда подмонтирование прописано в /etc/fstab, после запуска системы почти никакие файловые операции не работают, и работать невозможно. Попробовал проверить через fsck, но она зависает при попытке работы с этим диском, развисая и прекращая работу только при отсоединении диска. Не подскажите, что могло произойти, в чём может быть причина и что делать?
PS Файловая система — ext4.
Могло произойти физическое повреждение диска.
Это звучит как физическое повреждение, он не щёлкает ещё при этом? Сигейт щёлкал бы, WD по-моему менее зрелищно агонизируют. Хотя если логика сдохла то и щёлкать не должен, но ты не упоминаешь про то крутится ли он и производит ли интересные шумы.
Смарт посмотри если он определяется в системе. Без монтирования.
Если было падение диска, то от удара магнитные головки могли коснуться некоторой области диска.
При чём остальная область диска осталась неповреждённой.
Когда происходит обращение к повреждённой области будут происходить сбои чтения с этого места магнитных пластин диска. Диск будет долго пытаться прочитать эту область и всё будет тормозить.
Есть вероятность, что через некоторое время произойдёт переназначение секторов повреждённой области на секторы резервной области.
Но в целом диск уже повреждён.
Попробуй прочитать диск dd.
2 диска такого же размера теоретически хватит, но лучше 4х, если ты планируешь восстанаваливать данные.
Падений диска не было точно. Ещё вчера диск нормально читался, за прошедшее время диск лежал на столе. Если повреждённые области действительно есть, то можно ли как-нибудь прочитать диск без них? И как узнать, сколько именно повреждено? Можно ли как-нибудь работать, просто пропуская повреждённые области?
Вроде этот диск у меня чуть больше двух лет. А зачем два или даже четыре терабайта? У меня денег может быть не так много. На двухтерабайтник, возможно, хватит, но однотерабайтник всё же дешевле.
smartctl -a /dev/sdx
раз это внешний диск, то возможно придутся указать дополнительные параметры (вроде -d usbmicron ) и он возможно покажет смарт, но лучше подключить к сата порту компьютера напрямую. Место понадобится когда восстанавливаешь raw-данные с диска - сначала спасаешь их, потом восстанавливаешь из образа и тебе понадобится где-то хранить все эти терабайты.
Теоретически можно конечно восстанавливать прямо на устройство большее по размеру, но. Всё равно понадобится ещё диск на который данные будут потом восстанавливаться из того устройства (часть данных ведь утрачена, нельзя скопировать, что скопируется, и сделать вид что ничего не было). А это ещё столько же или даже больше. 2х это реалистичная оценка в принципе, если есть ещё диски, и побольше. А ещё может пригодиться резервная копия пока ты восстанавливаешь данные, у меня были ситуации когда моя предусмотрительность в этом вопросе себя оправдала.
Кстати это всё оооочень медленно даже при подключении через SATA3, стоит предусмотреть что этот процесс может занять с неделю и его очень не стоит прерывать.
если винт не ssd то нихера ему не будет от неожиданых отсоединений - в gparted создай на нем заново таблицу разделов и форматни в родной ntfs.
Ну насчёт ничего не будет ты погорячился. А так у меня такой потом ещё полгода после форматирования с бэдами проработал нормально, ага. Очень похожие симптомы были. И часть данных утеряна навсегда (нет, ничего важного, но в интернете есть не всё).
На четырёхтерабайтник денег на данный момент нет вообще, только на 2тб. Этого же будет достаточно?
PS Сейчас покупать ничего не буду, подожду, когда дадут стипендию.
И когда куплю, какая последовательность действий? Если я всё правильно понимаю, dd с пропуском ошибок на новый диск, и затем восстановление данных с копии.
Почитал тред. Да, смарт это хорошо. Наверное. Если бы я ещё когда нибудь увидел его в рабочем состоянии. А то или всё PRE-FAILURE на бодрых рабочих дисках, или всё в порядке на полутрупах.
Не увидел самые базовые советы:
Потом полезно смотреть лог ядра. Вызывается командой dmesg, Ошибки обычно даже подсвечивает красным и сбои дисков и файловых систем там показаны.
И наконец, если диск не работает и не ясно почему, его всегда можно немного проверить. badblocks может просто прочитать диск и скажет какие блоки не читаются. Или можно сделать бэкап диска и провести более надёжную (деструктивную для данных) проверку badblocks -wvv (-w это тест перезаписи данных, -v это показывать подробности, -vv это показывать все подробности).
И это по сути только базовые инструменты, а ведь есть ещё специализированные штуки для проверки и восстановления файловых систем и дисков.
Купил новый жёсткий диск, восстанавливаю при помощи GNU ddrescue, в файл на новом терабайтнике (уже отформатирован). У меня есть пара вопросов: 1. Сколько времени это теоретически может занять? 2. Можно ли приостановить восстановление, и снова потом запустить?
Читайте также: