Soft Свободное место на системном диске Windows

Я в курсе. Это уже плоскость профессиональных задач, а не игр. Тут и серверы с массивами памяти и терабайты проф. ссд идут в дело по необходимости.

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

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

 

Что это за сценарий?

 

У человека 500Гб Samsung 860 EVO. Он выдаёт в районе 20Гб pSLC кэша, после чего сваливается в прямую запись (не перетасовывание флеша). Сваливаение получается примерно с 500Мб/с на примерно 300Мб/с. Т.е. даже проваливание работы сборщика мусора не приведёт к катастрофическому падению производительности. Далее, для поддержания такого кэша должно хватать в районе 80Гб зарезервированного места. Пускай 100Гб, с запасом. Но стоит помнить что у него 512Гб флеша, из которых 12Гб зарезервировано производителем. Итого, можно оставить 88Гб неразмеченного, но зачищенного пространства. Больше... Не знаю, будет ли это иметь хоть какой-то смысл. Перезапись при сборке мусора оно немного снизит, но тут уже пошли вопросы ресурса. А там хороший достаточно дубовый самсунговский TLC 3D Nand флеш. Дома задраконишься его протирать...

--- добавлено 22 окт 2024, предыдущее сообщение размещено: 22 окт 2024 ---

SSD не выполняет дефрагментацию, его сборщик мусора может подготавливать пустые страницы, но оно к реальным файлам отношения не имеет. Да и размер страниц относительно небольшой. Но в целом чем больше свободного места - тем легче ему работать и тем меньше он будет набирать паразитной перезаписи. Но и там обычно всё в пределах 10%.

--- добавлено 22 окт 2024 ---

Почти все SSD имеют недоступный пользователю резерв. Странные объёмы, не кратные степени двойки, именно так и появляются.
Про pSLC кэш - SATA SSD он бывает и не нужен. 860 Evo начиная с 1Тб в любой ситуации не упирается в скорость записи во флеш, упираясь в интерфейс. Если нужен - то может быть несколько стратегий его использования.
У дешмания обычно динамический кэш и вся запись через него, причём кэш почти на весь свободный объём. Т.е. TLC SSD может записать до 33% от своего свободного места быстро (если у него хороший сборщик мусора, который это место подготовил к такой работе), после чего производительность падает катастрофически на время разгребания и ужимания записанного ранее + запись нового в освобождаемое место. Если успевает разгрести, то производительность немного поднимается - и так до простоя, пока SSD всё не утрусит и не подготовит место под pSLC запись.
Может быть какой-то фиксированный объём относительно небольшого кэша до 10%, который после заполнения оставляется, SSD переходит на прямую запись и относительно быстро пишет дальше, позже при простое сгружая кэш в обычный формат записи. И ещё куча вариаций с разными последствиями. Причём это зависит не только от железа, но и от прошивки. И конкретные производственные партии одной модели могут иметь разное поведение.
Потому что-то узнать точно можно только лично погоняв конкретный SSD. Ну, или купив что-то дорогое от нормального бренда.

--- добавлено 22 окт 2024 ---

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

--- добавлено 22 окт 2024 ---

Не бывает таких кристаллов флеша, которыми ты наберёшь ровно 500 000 000 000 байт. Там свыше 12Гб зарезервировано. Его хоть на 100% забей - он не будет жёстко проваливаться до единиц процентов производительности.

--- добавлено 22 окт 2024 ---

Пускай кто хочет пользуется. Я считаю, что резервировать конкретно на этом диске 10% вполне достаточно. Если очень хочеться - то можно 20-25%. Будет гарантированно обеспечен pSLC кэш и там ещё будет более-менее значимое снижение перезаписи по графикам JEDEC. Но дальше улучшения будут совсем незначительными. Конкретно для 500Гб 860 Evo. И да, все эти 10%-25% отсчитывать надо от реальных 512Гб, а не от доступных пользователю 500 000 000 000 байт. Зачем дублировать заводской резерв?

 

А файловая система разве не выполняет дефрагментацию у ССД?

Брендовые - да. Китайские ССД с али есть без резерва.

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

А это разве не дефрагментация, под которую нужно свободное место?

Я вот не изучал вопрос: даёт ли встроенная в ссд оперативка какие-то преимущества кроме скорости записи до её заполнения?

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

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

Вот именно. При том что резерв там уже не маленький. Ещё была мысль, чтобы не контролировать вручную свободное место на диске, довести размер резервных блоков в ext4 до 10%. Но не тестировал, как диск поведёт себя в таком сценарии.

 

"В общем в гузно файл подкачки."
Все покупают себе технику домой для игрищ и прочих развлечений. Поэтому лучший способ отказа от файла подкачки - линукс или плойка, оно само там разберётся :-)

 

Нет. ФС вообще ничего не делает ни на SSD, ни на HDD. Это отдельный софт, запускаемый по расписанию, который современные ОС уже не используют, если видят, что это SSD, или HDD с SMR.

--- добавлено 22 окт 2024, предыдущее сообщение размещено: 22 окт 2024 ---

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

Ни у кого нет отдельного чипа под SLC флеш, все используют pSLC режим работы основного массива TLC/QLC флеша.
Не путать с DRAM кэшем. Он про другое и на скоростную линейную запись не влияет. Он про хранение некоторой служебной информации и мелкие операций (каких много во время сборки мусора). В целом будет лучше с ним, чем без него. Но из-за него, кстати, можно огрести проблем при внезапном выключении питания. Вплоть до окирпичивания SSD. В серверных SSD стоят батареи кондёров, чтобы успеть сбросить кэш на флеш. DC500, PM883, 893, SM883 и т.д.

Нет, процесс отдалённо схожий с дефрагментацией свободного места, но не более того. Это про другое.

Можешь попробовать работу почти напрямую - скорости на запись будут уровня USB 2.0 на один кристалл. SSD не просто так имеет несколько каналов, CE, раздельные планы, относительно независимые страницы и не самый слабый, часто многоядерный, контроллер, который распараллеливает работу на всё это хозяйство. Это нифига не простое устройство, почти компьютер в компьютере.

Не мешай железу работать, контроллеру куда яснее, чем тебе, видно, что и как у него должно быть организовано. Потому максимум - оставляешь ему неразмеченное место, на которое не велась ранее запись без TRIM (можно на резервном месте создать раздел, прогнать на нём TRIM и удалить его). И всё. Не трогай его.

 

А можно было эту белиберду не писать.

Ты прав, туплю. Мне почему-то всегда казалось что ехт сама занимается дефрагментацией после записи. На самом деле ядро и файловая система борются с фрагментацией правильно организованной записью и рядом других решений по организации ФС. Также резерв в 5% пространства помогает избежать фрагментированной записи. Но в ext4, по словам Теодора Тсо требование 5% свободного места не абсолютно, зависит от сценария использования.
Reserved block count for Large Filesystem

Это ясен пень.

На али не только отбраковка, но и вполне нормальные ССД бывают и даже флешки с SLC памятью. Просто то что у нас в магазинах продаётся почти всё с уже зарезервированной за пользователя областью диска. Видимо брендовые производители посчитали что так износ памяти меньше у пользователей которые любят весь иск забивать под завязку.

Так я и предполагал. Жаль что нельзя купить TLC диск и перешить хотя бы в MLC.

Угу, в том числе почему стараюсь покупать ССД без встроенной памяти, так как мне высокие скорости всё равно не нужны. Хотя шанс огрести потерю данных при неожиданном выключении стремится к нулю при наличии бэкапов. Вот про окирпичивание при отключении питания не знал. Оно перманентное, или можно вылечить перезаписью прошивки/с использованием спец оборудовании по восстановлению данных с ССД?

Не, это понятно что масса ухищрений вроде SLC кэша используются для улучшения скорости работы на самом деле порядком медленной флеш-памяти. Я про то, как из неё сделали продукт. Тогда как на заре становления можно было бы управление памятью сделать софтварным в ядре и работать напрямую с чипами памяти, которые можно было бы легко заменять.

А есть ли на самом деле разница между неразмеченным местом и свободным местом на разделе, обработанном тем же trim? Ведь реальная адресация так и так совершается внутри устройства и недоступна фс. Мне думается что неразмеченное место было нужно только ранним ССД. Ведь адресация пустого пространства в фс это просто запись в суперблоке.

Также как резерв 5% пространства условная величина, которая была задана ещё в 90ых годах. И реальный размер места под резерв должен определяться в зависимости от общего размера диска и сценариев использования диска. Если диск на терабайт и больше он прекрасно будет работать с резервом меньше 5%.

 

Всё не на столько плохо, чтобы при наличии бэкапа об этом думать. Я взял PM883 вместо 870Evo/MX500/KC600 не потому, что мне важны эти кондёры, а просто потому, что узнал о этом и мне стало очень интересно попользоваться. Предыдущий системный SSD был с DRAM кэшем и за всё время я не столкнулся не только с окирпичиванием от внезапного отключения (очень редкие случаи, но возможные), но и с потерями данных.
А перед ним я огрёб внезапное окирпичивание как раз на безкэшевом SSD, без отключения питания, прямо во время работы, ЕМНИП.

--- добавлено 22 окт 2024, предыдущее сообщение размещено: 22 окт 2024 ---

Ты сейчас говоришь что-то в духе "можно было управление головками сделать софтварным в ядре и работать напрямую с пластинами HDD, которые можно было бы легко заменить."
Флеш много раз сильно менялся, менялись способы работы с ним, добавлялись новые возможности, изменялись старые. Под каждый вариант контроллер+флеш (не просто xLC, а конкретные кристаллы, у которых своя организация, плотность и ещё куча всякого, не раскрытого вне производства) своя прошивка. И самое главное, в простых вариантах изначально он был ЖУТКО медленным. Потому более-менее вменяемые SSD появились на 8-канальных контроллерах с резервированием от 4 NAND устройств на канал. Короче, не вышло бы оно "просто, дёшево, удобно", в таком открытом пользователю виде. Не та технология.

 

Да понятно. Я беру ССД без DRAM кэша при прочих равных, когда есть такой вариант но дешевле. Просто потому что мне высокие скорости на практике не важны.

Интересно именно, лечится ли окирпичивание при потере питания, или оно безвозвратно.

Не согласен. Механика и магнитные диски из другой оперы. А флеш память как изделие та же микросхема, что и оперативная память. На заре становления дисков на флеш памяти именно так и делали: подключали плашки памяти, и софтварно контролировали запись на них. Пока майкрософт не сделал так как он сделал. Отказавшись создавать отдельную подсистему или ФС под флеш-диски.

--- добавлено 22 окт 2024, предыдущее сообщение размещено: 22 окт 2024 ---

Ну это обычная кухня готовых устройств. Как скомпоновать, как прошить, как продать. Хорошо хоть патентных войн за способы реализации нету. А вот с разъёмами в итоге жизнь подортили, запихнув ненужную абстракцию M.2 в ПК материнки. Хотя прекрасно можно было обойтись PCI-E платами.

 

Доооо. Exploring the Relationship Between Spare Area and Performance Consistency in Modern SSDs

Ответ не зависит от использования линукса или чего-то ещё. Я бы выделил 4-8 Гб для swap раздела, а всё остальное в виде одной партиции для всего. 160 Гб - не тот объём, когда можно выдумывать. Ну ещё целесообразно сделать отдельный efi раздел на минимальный объём (у меня - 260 Мб). И да, swap раздел, разумеется, нужен независимо от имеющегося объёма ОЗУ.

 

Абсолютно бесполезный расход места и ресурса диска. Своп нужен только если хочется гибернации или нехватает оперативной памяти.

Если диск разбит с одним разделом на всё можно довести размер резервных блоков в tune2fs до 10% и успокоиться. Или же подрезать конец раздела и оставить неразбитыми 10-16 Гб.

Хотя, скорее всего, реально доступный объём диска и так каких-нибудь 148 гб, меньше паспортного на 8-10%, т.е. место уже зарезервировано производителем. Плюс дефолтные 5% резерва ФС. В таком случае реальной необходимости делать что-то дополнительно нету.

Можно прописать в опциях монтирования ноутбучного ССД discard,noatime,errors=remount-ro. И освоить регулярное резервное копирование ценной информации. Вот от этого будет реальная польза.

 

@rusty_dragon, нет, и тебе уже объяснили в треде (и про другие вещи, вроде дефрагментации, которая отродясь на SSD не нужна). У меня 64 Гб ОЗУ и всё равно имеется swap раздел. Про оптимальный свободный объём SSD я дал ссылку - хочешь, почитай. Про резервирование речи не было - это имхо вообще не нужно.

 

@Ulysses, нет, мне ничего не "объяснили" про swap. Утверждения что все так делают и почему так делают не отменяет факта что можно так не делать и при этом прекрасно жить. Я думаю, ты согласишься, что цель аргументированной дискуссии не набросать и "победить" оппонента, а познание и нахождение истины.

 

Поспешу разочаровать

И такое поведение началось ещё с восьмёрки.

 

@igor_pavlov, а говорят заложенное устаревание это байки..

 

@Ulysses, оно даже при 128гб создаёт своп. Под линукс это отдельный разговор, у дебиана 1гб по умолчанию под раздел не взираю на ) А под вынь тоже, нечто среднемелкое предлагается.

 

Этот подход не работает для простых вариантов, когда ты сам можешь определять конфигурацию. Будет или здоровенная плата с кучей разъёмов, или что-то само по себе уже достаточно сложное и дорогое, что-то очень ограниченно кастомизируемое/обновляемое/расширяемое. И тогда зачем лишняя морока с экономией на контроллере и перелаживанием его не самой маленькой специализируемой нагрузки на менее эффективный процессор общего назначения?

 

Спойлер: В курсе

Я в курсе, хотя тут меня переклинило, ибо "с оверпровиженингом" на автомате считаю модели на 480/960 и т.п.

У вас сарказмометр сломался.

И у вас - тоже.

Вам обоим: ориентироватся тупо на проценты - глупо. В помянутой выше статье 12% у 840 Pro полностью устраняет провалы ниже 1000 IOPS, при этом это 31Гб для 256Гб модели. Для диска на 512Гб 10-12%% будут уже в районе 52Гб+, и если мы не играем в бенчмарки, то средний Вася никогда не встретится с ситуацией, что ему вот прям всегда нужно больше 1000 IOPS и при этом он постоянно (т.е. почти каждый день, даже не неделю) пишет более 50Гб последовательно или рандомно.
При этом, мы видим по тестам что и без доп. махинаций диск OP'а даёт 8000 IOPS либо 300Мб/с записи при забитом кеше. Отрывать от сердца полезного пространства 50Гб имеет только ради морального успокоения и карго-культа.
Для совсем дешмана без оверпровиженга "от вендора" отрезать кусок можно, но опять-таки при 512Гб диске нет никакого смысла отрывать 10%|50Гб+, 10-16-24Гб будет более чем достаточно в 99% домашне-рабочих случаев.

Спойлер: Ну а комментировать про своп я даже не буду

ITT: "я один умный и своп отключил, а вот вооооообще все остальные лохи и ничего непонимают, и вообще эта миравой загавор M$ и била гейца лична для увиличения прадаж SSD "

 

Не знаю, чего нужно рандомному Васе, но в статье показано, что при 50% IOPS намного больше, чем при 12%, а сами они делают однозначный вывод об использовании не более 75% от объема SSD диска в сценарии домашнего использования. Остальные измышления без комментариев.

Не надо ничего отрывать. Купил такой объём, какой предполагается использовать, и всё. У меня на всех SSD (на разных компах) сейчас держится 30-35% свободного пространства, и я доволен. Нужный объём я прикидывал при покупке (и исходя из финансовых возможностей).

 

Я и говорю - карго-культ.
"Намного больше" - ну, во-первых, не "намного больше", а "меньше просадок по IOPS".
Во-вторых для домашнего использования 1000 IOPS более чем достаточно. Или гоняние бенчмарков ради синтетических циферок - и есть домашнее использование?
Ну а в-третьих, при штатном использовании подразумевается, что на диске, особенно системном, всегда есть свободное место.
Про проценты к объёму и абсолютному количеству ГБ от процентов - проигнорировано. Ну что ж.