Комментарии 39
Я так понимаю, после шуточки "Кстати, по этой же причине стирание информации потребляет намного больше энергии, чем чтение и запись. Поэтому хотите сэкономить заряд, поменьше удаляйте файлы!" статью можно не читать?
(Мало кто не знает, что удаление файла – "лёгкая" операция, всё его содержимое не затирается).
Ну в смысле весь текст до и после примерно того же уровня достоверности?
Так что при удалении файла в системе он не затрётся нулями/единицами полностью — об этом и был предыдущий комментарий.
PS: Если не верите — покурите исходники имеющихся ФС (Ext, FAT, NTFS).
чтобы он их почистил
в общем случае — нет.
Конечно, так ли это на физ. уровне, уверенным быть нельзя, так как драйвер Samsung в ядре под Linux не поддерживает (скорее -вал) физическое монтирование per NVMe версии 1.4.
в общем случае "физические сектора" (которые контроллер представляет ОС) и физические ячейки флеша — две большие разницы
В sata это не так
Это так для практически любого флеш-накопителя с выделенным контроллером: хотя бы потому, что физический объем флеш-памяти как правило больше (или в случае китайских флешек на 100500GB — меньше), чем "объем накопителя".
разумеется, нужны спец SMART утилиты
ну мы здесь вроде как про штатную работу накопителя говорим, а не про диагностические/fronestic режимы
можно детали?
и про sata, и про nvme
Как это относится к "поменьше удаляйте файлы"?
Какие ячейки физически стирать во флеше решает контроллер, по одному ему ведомым алгоритмам.
Даже "стирание с перезаписью нулями" на уровне ОС совершенно не означает стирания физических ячеек во флеш-памяти, где была расположена исходная информация.
Команда trim так же ничего не удаляет сама по себе, а просто сообщает контроллеру, что те физические ячейки, которые отображались на данные адреса, полезной нагрузки не несут и их можно использовать в одному контроллеру ведомых алгоритмах
Андроид, как ни крути, построен на Java машине. И приложениях, которые при закрытии фактически остаются в памяти ддо тех пор, пока в системе ее не останется мало и не запустится сборщик мусора.
В iOS такого безобразия нет, отсюда и скорость работы выше.
Для сравнения — были такие телефоны Blackberry на своей Blackberry OS 10.x.x (последняя была 10.3.3), фактически это QNX 8.0.0. Там тоже нативные приложения работают безо всяких прослоек (есть подсистема андроид для установки и запуска андроид приложений).
Так вот. Даже на очень скромном по нынешним меркам железе (Snapdragon 826, 2 ядра по 1.7ГГц и 2Гб оперативки) работает очень шустро, плавно и абсолютно без лагов, присущих андроиду.
И что-то я сомневаюсь, что в модели 13-го года (Blackberry Z30, к примеру) или даже 15-го (Blackberry Leap) была NVM память…
Андроид, как ни крути, построен на Java машине.
Технически, там уже лет шесть AOT.
И приложениях, которые при закрытии фактически остаются в памяти ддо тех пор, пока в системе ее не останется мало и не запустится сборщик мусора.
Это просто RAM app cache или типа того. Я сам так думал пока не написал апп под андроид, они закрываются если их закрывать а не сворачивать. Классика — https://www.linuxatemyram.com/
И когда оно все начинает лагать и тормозить приходится руками принудительно все ненужное закрывать.
Так что все равно остается ощущение что источник тормозов андроида — джавамашина. Где ее нет (иос, симбиан, блекбери, там все работает существенно быстрее даже на более скромных ресурсах).
И когда оно все начинает лагать и тормозить приходится руками принудительно все ненужное закрывать.
гхм, у меня обратное впечатление: после запуска «жирного» приложения другие начинают открываться заметно медленнее (их «выбило» из памяти и они запускаются с нуля)
а вот такое (руками приложения закрывать) уже и не помню когда в последний раз делал.
Во-первых, в UFS последовательный интерфейс. А это значит, что можно одновременно и записывать и считывать. eMMC мог делать только что-то одно. Поэтому UFS работает быстрее!Чтобы одновременно записывать и считывать нужен не последовательный, а дуплексный интерфейс (в UFS он такой и есть — последовательный дуплексный, в eMMC — параллельный полудуплексный). Но быстрее он не только (и не столько) по этой причине — сам интерфейс гораздо быстрей пересовывает данные.
Redmi K 30 Pro
Poco F2 Pro
Так кто именно тестировался?
И скрины тестов CrystalDiskMark бредовые:
- Разные версии.
- 1 GB улетит в кэш SSD, надо хотя бы 32.
В первой же строчке нам обещают разобраться в скорости работы смартфона исходя из скорости работы «жёсткого диска»?
Но в типовом сценарии (сёрфинг в интернете или прохождение одного уровня игрушки) — это явно не первый фактор.
один из самых раздражающих моментов — фризы при запуске программ, и быстрый накопитель тут важен.
Покупайте нормальные телефоны, а не бюджетные и не будет никаких фризов.
А если ещё на разницу между ценой айфончега съездить отдохнуть, то и раздражать многое перестанет, не только телефоны.
Внезапно, на разницу между ценой айфончега и не фризящегося андроидного флагмана съездить отдохнуть можно будет разве что на дачу, и то скорее всего в одну сторону.
В итоге Нокия безбожно тормозит, а самсунг летает.
Логично предположить (и наверное несложно проверить) что SSD в смартфонах проигрывают 'взрослым' в том числе потому что больше заточены на энергоэффективность
то, о чём вы пишите — Storage (где-то встречал перевод «Хранилище»)
NVMe и UFS — не типы памяти. NVMe — протокол; а UFS — целый набор спецификаций и на протокол, и на SCSI-подобную «шину».
вы неправы.
память — это не только RAM, ОЗУ
Почему бы в сравнение не добавить pcie4 nvme ssd?
Результаты будут ещё более красивее ( 5 Гб/с чтение, 4.5Гб/с запись), но так же ничего значимого не покажут, кроме того факта, что производитель какую захочет память ( быструю и дорогую или подешевле и помедленнее), ту и поставит.
что XS по всем показателям лучше чем более новый 11Pro? А по произвольному чтению/записи практически в 1,5 раза. И уже получается, что не
Apple… по произвольной они подчистую сливают Android-смартфонам
а по произвольному чтению рвёт все Андроиды подчистую.
NVMe против UFS 3.1: Битва типов памяти в смартфонах. Разбор