Я не редактировал свое сообщение после появления вашего комментария.
Если прям все занято, то вам файловая система скажет «стопэ, тут некуда писать». Но как правило на диске всегда есть хотя бы парочка свободных секторов, о которых контроллер точно знает. Туда он и будет писать методом Copy-on-write. И зона записи все время будет сдвигаться. Просто это будет не очень быстро в плане производительности. Всего 512 килобайт свободного места достадочно для работы механизма выравнивания. И в крайнем случае их контроллер всегда может занять в резервной зоне
Вы невнимательно читали статью. TRIM нужна для ускорения работы, а не для защиты от физической деградации ячеек диска.
Диски дохли от того, что данные писались в некоторые яичейки чаще, чем в другие, или даже несколько раз подряд в одну и ту же. Эффект усиливался, если ОС постоянно теребила на запись один и тот же служебный файл. Теперь контроллеры постоянно (и независимо от наличия TRIM) пишут данные каждый раз в другую яичейку. Это механизм выравнивания износа.
TRIM помогает диску узнать об освобождающихся областях одновременно с файловой системой, а не тогда, когда от файловой системы придет прямое указание на стирание какой-то области, потому что нам уже сейчас нужно туда писать.
В этом у SSD принципиальная разница с HDD: на SSD нужно дополнительное время на стирание, а на HDD — нет. Поэтому SSD пытается стирать заранее, в минуты простоя, получая информацию от TRIM.
TRIM помогает бороться в первую очередь с деградацией производительности при фрагментации данных на SSD. А вот от износа отдельные ячейки предохраняет сам контроллер.
Если SSD современный, брендовый, а не китайский ноунейм, то его невозможно убить работой ОС, при условии что на нем всегда есть 30 или % свободного пространства на любом разделе.
Однако, TRIM в ReactOS пока не поддерживается. Но это не фатально.
Аппаратность OpenGL зависит напрямую от конкретного драйвера конкретной видеокарты, который надо ставить отдельно. :) встроенный OpenGL по-умолчанию тоже software.
Все остальные страшные слова только в планах. Наверное Vulkan будет проще всего.
Поддержка dx9 без аппаратного ускорения только, через трансляцию вызовов в OpenGL.
Поддержка приложений win8/10 только если это стандартные win32 или .NET2.0/4.0 приложения, скомпилированные без сильно специфических API от новейших версий Windows.
Без 30% свободного места выравнивание износа будет работать, но все будет очень медленно.
Не сломаются. Килобайт свободного места будет мигрировать по всему диску.
Если прям все занято, то вам файловая система скажет «стопэ, тут некуда писать». Но как правило на диске всегда есть хотя бы парочка свободных секторов, о которых контроллер точно знает. Туда он и будет писать методом Copy-on-write. И зона записи все время будет сдвигаться. Просто это будет не очень быстро в плане производительности. Всего 512 килобайт свободного места достадочно для работы механизма выравнивания. И в крайнем случае их контроллер всегда может занять в резервной зоне
Диски дохли от того, что данные писались в некоторые яичейки чаще, чем в другие, или даже несколько раз подряд в одну и ту же. Эффект усиливался, если ОС постоянно теребила на запись один и тот же служебный файл. Теперь контроллеры постоянно (и независимо от наличия TRIM) пишут данные каждый раз в другую яичейку. Это механизм выравнивания износа.
TRIM помогает диску узнать об освобождающихся областях одновременно с файловой системой, а не тогда, когда от файловой системы придет прямое указание на стирание какой-то области, потому что нам уже сейчас нужно туда писать.
В этом у SSD принципиальная разница с HDD: на SSD нужно дополнительное время на стирание, а на HDD — нет. Поэтому SSD пытается стирать заранее, в минуты простоя, получая информацию от TRIM.
interface31.ru/tech_it/2015/04/mozhno-li-effektivno-ispolzovat-ssd-bez-podderzhki-trim.html
Однако, TRIM в ReactOS пока не поддерживается. Но это не фатально.
64-битное железо обычно обратно совместимо с 32-битными ОС.
А есть возможность на ночных сборках? Там все очень сильно зависит от конкретной модели оборудования.
Тогда есть смысл подождать до выхода 0.4.13, там эта проблема будет частично решена.
Мышки и клавиатуры получат универсальную поддержку в версии 0.4.13, которая выйдет приблизительно через 2-3 месяца
Это нужно проверять, лучше на ночных сборках.
Аппаратность OpenGL зависит напрямую от конкретного драйвера конкретной видеокарты, который надо ставить отдельно. :) встроенный OpenGL по-умолчанию тоже software.
Все остальные страшные слова только в планах. Наверное Vulkan будет проще всего.
У нас на подходе Xbox Original и X64
Выравнивание/прилипание окон и метро-интерфейс с метро-приложениями — очень разные и далёкие друг от друга фичи вообще-то.
Поддержка dx9 без аппаратного ускорения только, через трансляцию вызовов в OpenGL.
Поддержка приложений win8/10 только если это стандартные win32 или .NET2.0/4.0 приложения, скомпилированные без сильно специфических API от новейших версий Windows.
Зато появилась полноценная поддержка BTRFS и EXT2/3
Там большинство глюков вызвано с несовершенством механизма управления питанием и PnP-менеджера.