Имеет ли смысл разбивать HDD с TRIM на быстрый и медленный разделы?

как же нагибают адептов hdd

На HDD не может быть быстрых разделов, не стоит заморачиваться.

TRIM работает только для SSD и не зависит от разделов.Для HDD можно делать дефрагментацию (что не имеет смысла для SSD).

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

TRIM работает только для SSD

Это устаревшая информация.

блоки с меньшими адресами располагались в начале диска и потому линейная скорость была выше. Скорость в конце диска могла упасть в несколько раз. Был смысл делить диск на два раздела: с относительно быстро доступными данными и с более медленными.

Это было действительно заметно на дисках конца прошлого века. Уже в этом веке смысл заморачиваться с этим исчез, во первых кеширование стало умнее, сами кэши стали больше, ну и всякие алгоритмы упреждающего чтения\отложенной записи появились. На практических задачах никакой ощутимой разницы в чтении уже не было, равно как и возможности угадать где на диске физически находится эта цепочка секторов и цепочка ли это вообще. Контроллер диска с кешами уже давно изолирует «физику» от «логики» практически полностью. Так что не заморачивайся, просто прими «специфику» дисков с SMR\TRIM и используй их по назначению.

Не имеет смысла пердолиться с разделами. Наоборот даже когда у тебя физически два отдельных диска их лучше объединить в один на уровне ФС. Чтобы не считать сколько свободно осталось здесь, а сколько там. Просто льёшь данные куда хочешь. Это и есть прогресс.

TRIM работает только для SSD и не зависит от разделов.Для HDD можно делать дефрагментацию (что не имеет смысла для SSD).

Категорично, но неверно. Диски с SMR используют TRIM, и более того, нуждаются в нём. Иначе скорость чтения\записи со временем очень сильно деградирует. У них есть автотрим, но он срабатывает при определённых условиях, которые могут и не сложиться. Поэтому разумно делать трим как на SSD, либо сразу при удалении через опцию монтирования ФС, либо по расписанию с помощью fstrim.

TRIM работает только для SSD

И на HDD с черепицей, это один из параметров, по которому можно предположить, что диск SMR.

P.S. Долго писал, опередили :)

TRIM работает только для SSD

DISCARD бывает даже у виртуальных дисков, чтобы освобождать неиспользуемое гостем место. Это часть SCSI, и она не привязана к SSD.

Не имеет смысла пердолиться с разделами.

Ты это местным одептам LVMа скажи и скастуй туда одептов btrfs... я пока за попкорном схожу

Ух ты ж епт, в консумерские винты завезли дискард, потому что иначе тормозят? Мдааа…

Это и есть прогресс.

Тонко. Советовать всем вариации на тему RAID0 как «прогресс». За такое в приличном обществе бьют по лицу, причем сразу ногами.

Как раз сижу на raid0 встроенный в btrfs. Два ssd, один на два года старше другого. Что может пойти не так?

Не, lvm не котируется. А вот btrfs это база. Сам использую, так что не теоретик.

Это было действительно заметно на дисках конца прошлого века.

В конце прошлого века разницы как раз и не было, т.к. при адресации CHS объем данных не зависел от положения дорожки. Позже догадались размещать данные пропорционально длине дорожки. Благодаря этому произошло значительное ускорение последовательных операций с первыми блоками, но последние блоки остались таким же медленными.

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

Кеширование почти не играет роли в последовательных операциях. Но именно они меня интересуют в первую очередь.

просто прими «специфику» дисков с SMR\TRIM и используй их по назначению.

А каково их назначение? HDD с SMR я рассматриваю в качестве хранилища полных бэкапов в виде файлов на сотни ГБ. В быстрый раздел можно писать недельные бэкапы, а в медленный — квартальные. 1.5-2-кратная разница в масштабе десятков минут не критична, но приятна.

уррра SMR и долгую пересборку тоже TRIM называют, а так по теме чем больше раздел на SMR hdd и больше свободного места тем быстрее всё шевелится

а так по теме чем больше раздел на SMR hdd и больше свободного места тем быстрее всё шевелится

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

Раньше этот трюк позволял экономить немного времени. Но TRIM, скорее всего, делает его бессмысленным, и тогда более практичным будет один раздел на весь диск. Собственно, это я и хочу выяснить, не прибегая пока к экспериментам.

А каково их назначение?

Ну вот примерно таково и есть. Мультимедиапомойка и хранилище бэкапов, в дополнение к основному SSD. Для непрерывной записи (системы видеонаблюдения например) они не особо годятся, потому что у них времени не найдётся «сделать магию» и запись будет сильно проседать. Для кучи мелких файлов с рандомным доступом\записью они тоже не особо подходят, тут SSD рулит. Так что вот такой как у тебя сценарий как раз для них — хранение многих длинных гигабайт архивов или мультимедии, с периодической записью, удалением, и промежутками простоя, во время которых винт успеет «сделать магию» и физически распихать всё то что он желает распихать туда куда он желает распихать.

Так то у меня давно SMR диски в ходу, не жалуюсь, главное как системные их не использовать, для этого SSD есть. Ну и в RAID их не пихать, они для этого «шибко умные». Ну и не пугаться их внезапной активности в момент когда на них никакого записи\чтения не происходит.

Как раз сижу на raid0 встроенный в btrfs. Два ssd, один на два года старше другого. Что может пойти не так?

В одно прекрасное утро полезешь за бэкапами. Если они есть. А если нет - жизнь с нуля :-D

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

Возможно, это будет проблемой, но у меня диски с бэкапами внешние, они в основном лежат на полке, делать магию им некогда. Как их правильно отключать? Я обычно нажимаю кнопку извлечения в файловом менеджере и отключаю USB-разъем. Теперь меня смущают два момента:

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

2. Существуют ли дополнительные правила при отключении внешних HDD с SMR? Что будет, если я оборву его на полумагии? Не останутся ли на диске полубэкапы?

Для непрерывной записи (системы видеонаблюдения например) они не особо годятся

А это, возможно, идея. Правильно ли я понимаю, что диски для видеонаблюдения не имеют SMR? Учитывая их предназначение для максимально быстрой записи, они могут оказаться хорошим решением и для бэкапов.

Это же не устаканившаяся технология, как и прошивки SSD. Кто же заранее знает, что будет в том или ином накопителе.

В простейшем случае у SMR есть большая не SMR-область на блинах, которая используется для кеширования/перезаписи зоны. А TRIM просто позволяет «сказать» что в этой зоне данных дальше какой-то точки нет и можно не переписывать всю зону. То есть все сектора (кроме кеша) на своих фиксированых местах. Разбрасывание соседних по LBA секторов по разным концам блина не выгодно с точки зрения скорости линейного чтения. А все любят большие цифры. Но, может действительной, будет НЖМД с TRIM'ом и ремапом больших областей.

Ну, очевидно что не успеет. «Магия» там прерываемая, если ты кнопку извлечения нажал - он буферы сбросил. Свой внутренний кэш он спасает на токах индукции выбега ЕМНИП. Так что просто не будет никакой магии. Думаю ближе к концу свободного места скорость записи существенно деградирует в таком случае. И вообще деградация будет, при удалении файлов он дискард сделает, если ФС с ним смонтирована, а вот перераспределить не успеет, внутренняя фрагментация будет от этого расти. Но это всё IMHO, как там реально я ХЗ. Возможно поможет fstrim ручками пускать, перед извлечением.

Это же не устаканившаяся технология, как и прошивки SSD. Кто же заранее знает, что будет в том или ином накопителе.

Видимо, надо экспериментировать или согласиться с тем, что старый трюк себя исчерпал.

Разбрасывание соседних по LBA секторов по разным концам блина не выгодно с точки зрения скорости линейного чтения.

А насколько сильное значение имеет фрагментация, учитывая размер ленты в 1/4 ГБ? А если фрагментировать не лентами, а кластерами из лент, то фрагментацией можно и вовсе пренебречь.

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

Что может пойти не так?

При наличии регулярных бэкапов - ничего. Тоже считаю что вся дисковая память удобнее одним куском,а не порезанная на части. Когда-то лет двадцать назад было аж из четырех дисков «один кусок» собирал. Сейчас давно уже хватает объема одного ssd.

Что будет, если я оборву его на полумагии?

Если этот вопрос беспокоит то можно перед отключением отдать команду диску остановить мотор. Тогда он уж точно поймет что с магией пора заканчивать. Я правда не пробовал отдавать команду остановки мотора дискам,подключенным через usb. Через IDE и SATA эту команду использовал очень активно до перехода на SSD - в целях экономии энергии. Проблем от многократных пусков-остановок не имел ни разу за два десятка лет(девяностые-нулевые).

Думаю ближе к концу свободного места скорость записи существенно деградирует в таком случае.

Понял. Похоже, даже в моем случае есть смысл избегать дисков с SMR.

А насколько для меня будут хороши диски, предназначенные для систем видеонаблюдения? По идее в них должна быть минимизирована магия перетасовки записанных данных. Какие у них есть недостатки, при использовании в таком режиме: раз в неделю включил минут на 40, удалил самый старый архив, записал новый, протестировал его, выключил.

диски, предназначенные для систем видеонаблюдения?

А что,есть какие-то именно «специально предназначенные»? Мне приходилось залезать в ящики-видеорегистраторы - видел там обычные «компьютерные» диски. Правда регистраторы были китайские недорогие.

есть какие-то именно «специально предназначенные»?

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

Жесткий диск для систем наблюдения; предназначен для круглосуточной работы в комплексах, содержащих до 64 камер высокой четкости и до 8 HDD.

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

Я бы настолько не заморачивался и искал бы любой диск без SMR. Можно raid edition, он и сам по себе прекрасно работает, без райда, возможно будет шумноват, но тебе же без разницы. Можно даже какой нибудь бытовой, типа зелёных от WD. Ну да, он не рассчитан на круглосуточную эксплуатацию в отличие от «профессионально заточенных», но ты и не будешь его использовать круглосуточно. Главное чтобы в нём SMR не было. К сожалению у многих моделей нет в спецификациях инфы, SMR они или нет, нужно гуглить форумы... Ну и я бы гелия в банках избегал, у меня есть сомнения насчёт продолжительности хранения дисков с гелием в банках.

Экспериментировть, конечно, хорошо, но одиночный экземпляр мало что даст. Я как-то давно купил дешман SSD и fio показал нормальное линейное чтение и совсем низкое RND. Я долго пытался понять, что поковырять, там AHCI, прерывания. А потом купил другую модель, и на том же железе, ЕМНИП, в 5-8 раз скорость случайного чтения больше. Вот такое вот «везение».

Сложно сказать, насколько фрагментация повлияет, у SMR может быть больше время позиционирования головок, там ведь нужно прицеливаться в дорожки меньшей ширины, чем у CMR. Лента 1/4 Гбайт, а типичный тест в CrystalDiskMark 1 Гбайт, то это три лишних «дальних» позиционирования, если ленты разбросаны.

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

Купил с SMR - ССЗБ

Слишком много движений, чтобы выбрать диск для бекапов. На сыкономленное время можно еще один диск взять. Кратко:
- не брать smr и гелий
- на разделы не разбивать, один диск - один раздел
- можно взять, конечно, «дорогой» (red, purple (Surveillance), gold), но в режиме подключиться, скинуть бэкап, отключится будет жить любой, можно на гринах\синих\барракудах остановиться. А на сэкономленные взять еще один диск, выйдет кратно надежней.

SMR-диски не годятся ни для каких(!!!) сценариев использования (расписывать каждый долго, но это так). 3 iops и повывшеный износ механизма позиционирования головок.

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

Очевидно же, что даже 25% прирост по объему никак не стоит падения производительности на 2 десятичных поряка.

Просто купите нормальный диск CMR.

Ты это местным одептам LVMа скажи и скастуй туда одептов btrfs

Обе группы лиц не любят лишние разделы. Но первые плодят убогие LVM-тома, которые иногда надо потом ресайзить.

У тошиб хорошая инфа, SMR или CMR

А что,есть какие-то именно «специально предназначенные»?

есть. как минимум у них ускоренная обработка ошибок чтения - не долбятся по 40-60 секунд, не смогли прочитать за секунду (или меньше) - и фиг с ним.

Экспериментировть, конечно, хорошо, но одиночный экземпляр мало что даст.

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

ИМХО, нет, не имеет никакого смысла.

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

HDD

TRIM

Ужас! Злые корпорации портят великий HDD!

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

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

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

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

Возможно, имеет смысл сделать отдельный мини-сервер для дублирующих бэкапов? Но это еще одна система, требующая настройки и мониторинга. Боюсь получить не экономию времени, а трату.

просто так делать смысла нет, потому что чем проще все организовано, тем легче поддерживать и ремонтировать.

А что было сложного? Подключаем диск, запускаем скрипт. Он сам разберется, в какой раздел писать архив, и что следует удалить. В это время можно заняться другими делами. Но когда приходится спешить, выигрыш 10-20 минут очень радует.

Ну, может оказаться, что даже не конкретная модель, а конкретная ревизия/прошивка.

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

Наверное для бекапов лучше host management (HM-SMR), но там отдельный блудняк.

Скажем так, RAID0 — это действительно специфическая вещь.

man smr

Ну почему, если покупал специально для хранения порнухи, то норм. Проблема только в том, что ни для чего, кроме порнухи такие диски не подходят

Наверное для бекапов лучше host management (HM-SMR)

Перечисли все полторы доступные на рынке модели, где это есть. И насколько они дороже ширпотребного SMR-говна

Про SMR я знаю, а вот про TRIM на нем меня тут и просветили :-D

Сейчас я не просто диск выбираю, а полностью пересматриваю устоявшийся подход.

Отличный повод перейти на SSD, хотя бы SATA. Поверь, тебе понравится. Давно уже основной (то есть авто по расписанию) бэкап у меня делается на NVME SSD. Все операции проверок (restic check, rclone check, btrfs scrub) работают очень быстро. То же с удалением устаревших данных из репозитория. Репа синхронизируется с облаком. Размер сейчас небольшой, около 600 Гб, но это всё ещё оправдывает использование SSD. Про 1+ Тб и говорить не стоит.

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

https://www.backblaze.com/blog/the-3-2-1-backup-strategy/

Я дополнительно использую ещё один SSD через USB, недавно это был HDD, но медленно очень. Там просто rsync на Btrfs+LUKS. Итого получается 4-3-1.

Возможно, имеет смысл сделать отдельный мини-сервер для дублирующих бэкапов? Но это еще одна система, требующая настройки и мониторинга. Боюсь получить не экономию времени, а трату.

Хороший вариант, настроил и забыл. А пока ты потратил уйму времени на исследование бесполезного говна.