Счастье всем, даром и пусть никто не уйдёт обиженным!

Ну в случае с байтами, а не битами, все производители флешек используют «мега» и «гига» в правильном значении, то есть как степени десятки, а не как степени двойки и у тебя объем в 2Tb это реально 2TB, а не 2TiB

From:

В случае флешек объём накопителя доступного пользователю давно перестал быть степенью двойки и вообще каким-то производным числом.

From:

Вероятно имеется ввиду минимальный объем, который будет представлять тебе контроллер на флешке.

From:

Номинальный объем считается с десятичными приставками, что для хардов, что для флешек. В линуховых графических файл-менеджерах, кстати, лет 10 уже есть переключатель между десятичными и двоичными приставками из-за этого(по дефолту на двоичных, так как народ привык к ним)

From:

Я понял, понял. Но я про то, что накопитель давно не восемь бит по вертикали на восемь по горизонтали и получай 64 бита.

From:

Ну как оно там внутри нам, пользователям, не интересно :)
Я помню, как первый раз купив хард наткнулся на то, что объем в честных десятичных, как положено, смотрю, вроде не доложили объема, лезу в описание, а там специально звездочка и под ней «считается в десятичных приставках». С той поры уже привык, порой сам объясняю это тем, кто возмущается, что купил хард на 3 тера, а винда ему показывает 2.8(вроде так выйдет, лень считать)

From:

Винда тоже лукавит. Ведь мелкософт рекомендует диск не забивать более, чем на три четверти.

From:

Это уже из-за производительности, так-то все 2 с хуем ты забить можешь, что написаны, но если будет больше 3/4, то будет хуево по скорости

From:

Не только винда:)

SSD лучше не забивать чтобы у контроллера было "место для маневра" когда пишут новые данные. Иначе ему придется синхронно удалять старые и будет тормозить (особенно если ОС или шина не умеет TRIM).

Некторые вендоры даже советуют делать over provisioning: оставлять часть SSD не размеченной, для использования контроллером

В HDD такой проблемы нет, но и там самые дальние части части диска располагались на самых дальних дорожках, и работали медленно (бо скорость там ниже).

From:

"Некторые вендоры даже советуют делать over provisioning"

Скорее всего какой-то косяк старых версий, если контроллер не умеет перетаскивать не изменившиеся данные по секторам. Тогда если диск полностью забит, то оставшаяся часть будет очень быстро исчерпывать ресурс (что ещё усугубляется огромным размером сектора флешек, 65-128 к и если писать 100000 файликов по килобайту почаще, то указанные "объёмы записи" окажутся наглым обманом).

Я про особенность NTFS, что жутко фрагментируется, когда дисковое пространство исчерпывается (это косяк мелкософта).

From:

Я думаю что это защита от ситуации когда не работает TRIM/UNMAP (например SSD подключен через RAID или IDE или ОС не умеет трим (опенбздя например)) либо когда контроллер не успел еще удалить старые страницы.

1) ОС просит записать данные
2) Контроллер видит что свободных страниц нет
3) Если у него есть свободное место -- он его использует, а блоки страниц удаляет в фоновом режиме в рамках сборки мусора
4) А если свободного места нет -- он судорожно начинает чиститься и это замедляет запись,

>>перетаскивать не изменившиеся данные по секторам.
Обычно он растаскивает всё в фоновом режиме чтобы равномерно покрыть все блоки, но на это нужно время

>>если диск полностью забит, то оставшаяся часть будет очень быстро исчерпывать ресурс
Согласен. Если контроллер не будет перекладывать данные то да: одно место будет постоянно дрочиться и в итоге помрет. Для того и придумали wear leveling, чтобы равномерно юзать все блоки.

У SSD же варварский способ записи/стирания: электроны с кремниевой подложки пробивают диэлектрик, и он от этого изнашивается.

>>размером сектора флешек, 65-128 к
ЕМНИП сектор (блок) бывает там и до 512К. Записать можно страницу (4К) но стереть только целый блок, так что запись файла в килобайт может занять 4К (страницу) а может привести к работе по очистке целого блока.

>>NTFS, что жутко фрагментируется, когда дисковое пространство исчерпывается
В той или иной степени это проблемы всех файловых систем. NTFS с виндой хотя-бы официально поддерживают дефрагментацию:)

Для SSD это не очень существенно, хотя и там лишняя фрагментация приводит к лишним чтениям. Какие-то утилиты (MyDefrag например) даже пытаются дефрагментировать SSD, хотя это и уменьшает срок их жизни (который в домашних условиях все равно редко настает)

From:

Ну не настолько варварский. Всё же там туннелирование и всякие "горячие электроны" (залетающие с разгону на "приманку", бгг!), т.е. не необратимый процесс.

И вообще Дисплей, бросайте мне рассказывать как мелкосхемы работают (конечно речь не о технологиях маркетинга, здесь каждый день что-то хорошо забытое старое), это часть моей специальности ;) Сомневаюсь, что физики за последние лет 20 что-то радикально новое открыли в своих законах ;)))

Edited Date: 2018-12-09 01:22 pm (UTC)

From:

Геометрия устройства известна только контроллеру в самом устройстве:) С ним мы общаемся в терминах протокола той шины, к которой он подключен (USB mass storage, SATA итд, обычно это все ребрендинг SCSI).
Там мы адресуем последовательно расположенные блоки, и это одномерный массив без знаний о вертикали и горизонтали)

В случае NAND (флешек/SSD) контроллер делает сложную работу по wear leveling, выбирая куда что положить, так что при всем желании он бы не мог рассказать нам настоящую геометрию устройства.

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

Последняя не одномерная геометрия была во времена CHS (в конце 90х): когда софт реально указывал головку, циилиндр и сектор у HDD, но и там контроллеры могли врать.

Ну и кажется честная геометрия была у FDD, там драйвер привода дисковода мог ее знать, но это было очень давно.

Вероятно мы можем спросить геометрию у диска в SATA (во всяком случае в SATA, работающем в режиме IDE (aka "НЕ AHCI")) и он нам что-нибудь наврет, но это никогда не будет правдой.

From: