The problems involve the Windows 11 24H2 update, KB5063878, which began rolling out last Tuesday, mainly to address an issue about sign-in delays on new devices. Since updating, some users have noticed major errors with SSD storage drives.
“Had my Samsung 980 PRO 2TB SSD disappear under normal operation today after this update,” wrote one user on Reddit. Others reports that the update caused their PC to freeze or crash.
“The drive is completely unresponsive, it shows up as unallocated space, but I can't initialize it to be able to do anything with it,” wrote another user.
Даже убунта не опускалась так низко- убунта в прошлом после апдейта пару раз в год могла словить чёрный экран с невидией, что лечилось магмческим пассом в терминале/или по ssh.
Убивание ssd (прошивки ssd?) апдейтом- песец.
Re: Windows update повредил файловую систему у части пользователей
Аё>Даже убунта не опускалась так низко- убунта в прошлом после апдейта пару раз в год могла словить чёрный экран с невидией, что лечилось магмческим пассом в терминале/или по ssh.
какую версию бунты ты используюешь ?
я сидел под 18-20-22 проблемы с видеократой были только один раз
нас на работе заставили перейти на win 11
far явно работает медленно и дисковые операции иногда подтормаживают
обнолвения у нас ставяться с задержкой поэтому описанные тобой случаи редки
Re[2]: Windows update повредил файловую систему у части пользователей
Здравствуйте, sergey2b, Вы писали:
S>какую версию бунты ты используюешь ?
Очень давно на федоре. В старом ящике hdd подключен 2-м, сохранился раздел убунты из 2013г.
Re[2]: Windows update повредил файловую систему у части пользователей
Здравствуйте, sergey2b, Вы писали:
S>какую версию бунты ты используюешь ? S>я сидел под 18-20-22 проблемы с видеократой были только один раз
Ну, они бывают, проблемы с видюхой. Особенно с проприетарными дровами.
S>нас на работе заставили перейти на win 11 S>far явно работает медленно и дисковые операции иногда подтормаживают
В венде файловая система работает ощутимо медленно, чем в линухе.
Я думаю, это связано с тем, что в UNIX традиционно используются шеловские скрипты в большом количестве, а шеловский скрипт — это на каждую строчку программу найти, открыть, загрузить, ее динамические либы найти, открыtь, загрузить,... А отработает каждая такая отдельно загруженная программа, делая что-то полезное, 10 миллисекунд.
Чтобы это работало сносно, операция открытия файла должна быть ОЧЕНЬ оптимизирована (включая резолвинг имени файла в inode, со всеми этими промежуточными директориями, символичеслими ссылками, точками монтирования и т.п.).
В венде такой потребности нет. Там типичный workflow состоит из редкого запуска больших долгоживущих програм, и не очень важно, как долко они запускаются.
Re: Windows update повредил файловую систему у части пользователей
Здравствуйте, Артём, Вы писали:
Аё>Даже убунта не опускалась так низко- убунта в прошлом после апдейта пару раз в год могла словить чёрный экран с невидией, что лечилось магмческим пассом в терминале/или по ssh.
По-моему нвидиявский sudo rm -rf / затрoнул и Ubuntu.
Не после этого ли внесли изменение в coreutils, который требует длинного подтверждающего флага?
Здравствуйте, Артём, Вы писали:
Аё>Даже убунта не опускалась так низко- убунта в прошлом после апдейта пару раз в год могла словить чёрный экран с невидией, что лечилось магмческим пассом в терминале/или по ssh.
Аё>Убивание ssd (прошивки ssd?) апдейтом- песец.
Зачем вы вбрасываете свои домыслы?
Убивается всего лишь файловая система, а не ссд или прошивка, при определенных условиях — конского размера файлы итд.
Re[2]: Windows update повредил файловую систему у части пользователей
Здравствуйте, Pauel, Вы писали:
P>Зачем вы вбрасываете свои домыслы? P>Убивается всего лишь файловая система, а не ссд или прошивка, при определенных условиях — конского размера файлы итд.
Если только FS,тогда почему определённые модели ssd а не поголовно все ssd и hdd?
Что такое "конский размер"? Когда венда засерает 100гб историей обновлений, это уже конский, или нет? А от архива размером 32гб — укакалась. Неудивлюсь, если это результат вайб-кодинга.
Re[3]: Windows update повредил файловую систему у части пользователей
Здравствуйте, Артём, Вы писали:
P>>Зачем вы вбрасываете свои домыслы? P>>Убивается всего лишь файловая система, а не ссд или прошивка, при определенных условиях — конского размера файлы итд.
Аё>Если только FS,тогда почему определённые модели ssd а не поголовно все ssd и hdd?
Это всегда так было, с начала времён
— часть девайсов более чувствительны к тем или иным ошибкам
— система с разными девайсами работает по разному — тайминги, буферы, протоколы итд
Re[2]: Windows update повредил файловую систему у части пользователей
Здравствуйте, Kocur, Вы писали:
K>компенсации Билли Гейтс будет платить?
1) Биллигейц уже больше десяти лет не имеет отношения к Микрософту.
2) В лицензии на Винду сказано, что они не несут ответственности ни за что, что дороже стоимости Винды.
Течёт вода Кубань-реки куда велят большевики.
Re[3]: Windows update повредил файловую систему у части пользователей
Здравствуйте, Pzz, Вы писали:
Pzz>Чтобы это работало сносно, операция открытия файла должна быть ОЧЕНЬ оптимизирована (включая резолвинг имени файла в inode, со всеми этими промежуточными директориями, символичеслими ссылками, точками монтирования и т.п.).
1) Обычно есть namei cache (не знаю, есть ли в винде).
2) В винде поиск от любой позиции в FS делается через сборку полного пути и разборку его обратно (ну по крайней мере так было в утекших исходниках, где самое позднее — XP; может, поменяли?) В юниксах всегда было возможно от текущего каталога, а сейчас через *at() ещё и от указанного каталога.
3) Я больше склонен думать, что вопрос в NTFS и её драйвере, где всё очень запутанно и медленно.
Pzz>В венде такой потребности нет. Там типичный workflow состоит из редкого запуска больших долгоживущих програм, и не очень важно, как долко они запускаются.
Это перегиб. Скрипты с большим количеством мелких вызовов делаются и в юниксах нечасто, в основном это старт/стоп, процедуры установки, компиляции и т.п., где и в винде тоже много вызовов чего-то отдельного.
The God is real, unless declared integer.
Re: Windows update повредил файловую систему у части пользователей
Здравствуйте, Артём, Вы писали:
Аё>Даже убунта не опускалась так низко- убунта в прошлом после апдейта пару раз в год могла словить чёрный экран с невидией, что лечилось магмческим пассом в терминале/или по ssh.
Я ещё помню Mandrake 7.2, кажется, Fedora версии не помню, и Red Hat 6.x
Кто-то ещё отметился. Когда они CD-дисководы перепрошивали (преимущественно LG
и ещё чьи-то в момент установки линукса. Перепрошивались насмерть.
Аё>Убивание ssd (прошивки ssd?) апдейтом- песец.
Ничего нового, сколько раз уже было...
Помню когда ещё XP была. Они PS/2 мышь отломали. Причём бесплатным обновлением.
А чинили уже только в платном (с лицензией). Вот это -- профессионализм.
Re[3]: Windows update повредил файловую систему у части пользователей
Здравствуйте, Pzz, Вы писали:
Pzz>В венде такой потребности нет. Там типичный workflow состоит из редкого запуска больших долгоживущих програм, и не очень важно, как долко они запускаются.
Ну конечно. Как вспомню билд-сервер (на виндах) на прошлой работе, ужасаюсь.
Билд длился час. Потом то же самое, ну почти, на линуксе собиралось за 5 минут.
На виндах мс-билдом и MSVC. На линуксе Make и gcc.
Re[4]: Windows update повредил файловую систему у части пользователей
Здравствуйте, netch80, Вы писали:
N>3) Я больше склонен думать, что вопрос в NTFS и её драйвере, где всё очень запутанно и медленно.
Причём они бьют себя пяткой в грудь, что у них там двоичные деревья прямо на диске,
а в убогом линуксе плоские списки. И ведь правы. Большой каталов в линуксе -- проблема.
Re[5]: Windows update повредил файловую систему у части пользователей
Здравствуйте, fk0, Вы писали:
N>>3) Я больше склонен думать, что вопрос в NTFS и её драйвере, где всё очень запутанно и медленно.
fk0> Причём они бьют себя пяткой в грудь, что у них там двоичные деревья прямо на диске, fk0>а в убогом линуксе плоские списки. И ведь правы. Большой каталов в линуксе -- проблема.
Не проблема.
В ext3, ext4 некие hash tree (раз, два), можно выключить, но сейчас включается по умолчанию; по ним выборка по имени O(1). Они рассматривали вариант с B-tree и отказались. Видно, возможность поиска по диапазону имён для них не имела смысла. Для моей личной шизы что как раз поиск по неточному имени или по диапазону без полного перебора это мастхэв, но, видимо, у них таки больше знания о реальных запросах.
В XFS, JFS, Reiser, ZFS, Btrfs используются варианты B-tree.