LINUX.ORG.RU

Влияние разметки диска на его износ

 ,


0

1

Есть обычный, т.е. с блинами, диск на 1 ТБ с ext4, на котором крутится Linux с базой, для которых отвел пятую часть объема - ~ 200 МБ.
Остальные 800 МБ отвел под файлопомойку, но она так ничем и не наполнилась, стоит себе без дела пустая.

Так оно себе и работало, пока сегодня не прискакала нехорошая мысль:
- ведь головки диска елозят только в этом ограниченном объеме 200 МБ, условно говоря, от 0 до 200 цилиндра, а область 201-1000 вообще не участвует в работе.

А раз так, то область 0-200 усиленно «изнашивется» многократным перемагничиванием, и выйдет из строя гораздо раньше, чем 201-1000?

Если это правильно, то может лучше растянуть рабочую область 200 МБ на весь диск - до 1000 ГБ, и срок службы диска увеличится условно в 5 раз?

★★★★

Влияние разметки диска на его износ

Не влияет.

vvn_black ★★★★★ ()
Ответ на: комментарий от vbr

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

chukcha ★★★★ ()

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

firkax ★★★ ()
Ответ на: комментарий от chukcha

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

pfg ★★★★★ ()
Ответ на: комментарий от pfg

скорее - деградация голов (налипание на них отслаивающихся частиц магнитного слоя) и собссно отрыв частиц магнитного слоя со временем/заводской брак/прочее.

NiTr0 ★★★★★ ()
Ответ на: комментарий от firkax

Даже если бы ты его разметил на весь терабайт, использовалось бы всё равно только начало.

Зловещие 4.2: ext4 будет раскидывать директории созданные непосредственно под рутом fs по разным block groups. Ещё я бы ожидал при меньшем disk usage (и прочих равных) меньшую fragmentation. Так что смысл есть, правда не тот который ТС вкладывал.

bugfixer ★★ ()

ПыСы к моей месаге выше:

растянуть рабочую область 200 МБ на весь диск

В контексте того что я написал resize не особо поможет - только полный backup / reformat / restore.

bugfixer ★★ ()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от NiTr0

Хорошо, но ведь внутри диска не вакуум, а азот или даже гелий?
Раз так, то вокруг головок вращающимися блинами возникают некоторые завихрения газа, которые - пусть даже чуть-чуть, самую малость! - воздействуют на поверхность блинов, прогибая их вниз, заодно сметая или перемещая по ним пыль.
Конечно, этот прогиб микроскопический, но в жестких дисках все такое, сплошь нанотехнологии на грани фантастики.
И вот это воздействие в активной зоне приведет к ее более быстрой деградации, чем в той, над которой головки появляются лишь изредка.
Все имхо.

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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

Какая бурная фантазия. Реальная опасность - «чиркнуть» головой по «блину» (при вибрациях, например), что приводит к появлению пыли, и после этого всё идёт «в разнос».

bugfixer ★★ ()

За износ не скажу, зато на скорость чтения подобная разметка влияет, исключительно положительно!

tiinn ★★★★★ ()
Ответ на: комментарий от chukcha

ну да, истирание трущихся поверхностей, как поверхность блина (описанное вами конечно полная фантастика, все прощееее) так и истирание механизма вращения блина, - естественный механический износ.

но не деградация магнитных свойств материала поверхности блина - она медленнее мех.износа, я конкрентно про усиленно «изнашивется» многократным перемагничиванием

pfg ★★★★★ ()
Последнее исправление: pfg (всего исправлений: 2)
Ответ на: комментарий от chukcha

Даже если идёт усиленный износ именно в этом месте - hdd наименее чувствительны к этому. Действительно, через лет 10-15 у некоторых хреновых экземпляров проявляется такой эффект, что бэды в области условной fat-таблицы/ суперблока/журнала.

kirill_rrr ★★★★★ ()

Кстати, конкретно в ext* есть опция - скармливаешь им список бэдов и они вроде как должны не использовать их. Ну или потом, через 10 лет переразметишь диск выключив первые 200Гб из обращения.

kirill_rrr ★★★★★ ()

Есть обычный, т.е. с блинами, диск на 1 ГБ с ext4, на котором крутится Linux с базой, для которых отвел пятую часть объема - ~ 200 МБ. Остальные 800 МБ

Fixed

DanilaZabiakaa ()
Ответ на: комментарий от chukcha

Когда все данные лежат в самом начале диска.

tiinn ★★★★★ ()
Ответ на: комментарий от superuser

1000 ГБ != 200 МБ + 800 МБ

Ладно уж, не прикалывайтесь, не привык еще к таким большим числам! :=)


Когда все данные лежат в самом начале диска.

Вот я и задумался, как лучше поступить со swap-разделом...

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

И какой же вариант лучше?

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

нет там гелия/азота (гелий разве что в 10+ТБ)

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от kirill_rrr

как повезет.

вероятность повреждения поверхности выше там, где летают головы - но повреждение обычно при сторонних внешних воздействиях (вибрация, удары).

ну а через 60-100 тыс.часов наработки обычно уже головы начинают деградировать…

NiTr0 ★★★★★ ()
Ответ на: комментарий от chukcha

Ладно, спрошу по-другому :=)
С давних времен при разметке диска всегда требовалось создание boot-раздела, который должен располагаться не далее 1024 цилиндра.

Теперь заметил, что современные дистрибутивы всегда работают и без этого раздела - значит, «Проблема-1024» решена, и boot-раздел необязателен?

chukcha ★★★★ ()

Через 15 лет 24/7/365 я продал старые диски по актуальной цене. Не еби себе мозг с HDD, да есть разница в скорости доступа к 0 и к последнему сектору, но если твой диск не сидит в перманентном кеше нагруженного вебсервера, то все без разницы.

soomrack ★★★ ()
Ответ на: комментарий от kirill_rrr

Лучше иметь своп на юсб2.0-ссд чем на сата хдд.

Вообще-то неплохая идея! Но только долговечность SSD в режиме перманентного свопа будет никакая.

И все таки, к сожалению, среди вам не нашлось знатоков, которые просветили бы насчет «Проблемы 1024 цилиндра», решена она уже или нет.

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

Это и коню понятно. Проблема в том, что заранее это неизвестно.

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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

Третий год как 120гб ссд превращает raspberry py 3 (1Гб оперативки) в десктоп. крайне редко когда в свопе меньше гига, файерфокс висит с аптаймами по 20 дней в среднем.

Я так понимаю если весь диск полностью отдан под своп, то ftl очень грамотно отбалансирует нагрузку и ресурса хватит очень надолго. А если выделить небольшой раздел и забить данными остальное - вот тогда песец подкрадётся быстро. У меня на ноуде с виндой (7,2гб рам) своп был 2гб и вот этот как раз выгорел. за 4 или 5 лет правда, но там интенсивность свопинга была на порядки ниже.

«Проблемы 1024 цилиндра», решена она уже или нет.

А откуда им взяться, если hdd уже минимум 20 лет как скрывают свою геометрию и все эти цилиндры чисто виртуальны? Я так понимаю с точки зрения ядра есть только номера блоков и их размер, и всё.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от chukcha

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

/dev/sdc:
  Type       = SATA
  Disk ID    = ata-INTEL_SSDSA2CW080G3_CVPR12250026080BGN
  Model      = INTEL SSDSA2CW080G3                     
  Firmware   = 4PC10362
  APM Level  = none/disabled
  Status     = active/idle
  TRIM       = supported
  Host       = host5
  Scheduler  = [mq-deadline] kyber bfq none (multi queue)

  Runtime PM:
    /sys/block/sdc/device/power/control = on, autosuspend_delay_ms = -1

  SMART info:
      4 Start_Stop_Count          =        0 
      5 Reallocated_Sector_Ct     =        0 
      9 Power_On_Hours            =    46307 [h]
     12 Power_Cycle_Count         =     1753 
    225 Host_Writes_32MiB         =   33.878 [TB]
    232 Available_Reservd_Space   =      100 [%]
    233 Media_Wearout_Indicator   =       90 [%]
    241 Host_Writes_32MiB         =   33.878 [TB]

На этом ssd в том числе и своп-раздел находится (наряду с разделом под образы виртуалок).

alex1101 ()
Ответ на: комментарий от chukcha

Просто не бери откровенно мусорные ssd и будет тебе счастье.

А то знатоки берут дешманский adata на 500 гб за 2 тыщи рублей, потом орут что ssd ненадёжные.

alex1101 ()
Ответ на: комментарий от kirill_rrr

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

А откуда им взяться, если hdd уже минимум 20 лет как скрывают свою геометрию и все эти цилиндры чисто виртуальны?

Дык какая разница, виртуальные они или нет. Речь идет о загрузчике, который видит эти виртуальные цилиндры, и если они >1024, то отказываются грузиться.
Такое было в lilo, и во времена grub-1, а вот сейчас вроде нет такого, возможно, это связано с новыми фичами сверхнавороченного grub-2.

И тогда возникает закономерный вопрос - зачем делать раздел /boot, если оно теперь и без него всегда работает?
Вот вы все как, до сих делаете /boot?

А то знатоки берут дешманский adata на 500 гб за 2 тыщи

У меня не дешманский, а Гнусмас 860 Pro MLC/300TB, такие имеют не только лишь все, не все могут их иметь :=)
Но когда он за 170 дней намотал 45 ТБ, т.е. 15% от ресурса, снял его нафиг и поставил обычный hdd.
Потому что такая корова мне самому нужна :=)

chukcha ★★★★ ()
Ответ на: комментарий от vbr

Нет никакого износа от перемагничивания.

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

LeadLed ()
Ответ на: комментарий от chukcha

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

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

И тогда возникает закономерный вопрос - зачем делать раздел /boot, если оно теперь и без него всегда работает? Вот вы все как, до сих делаете /boot?

Я даже не в курсе такого ограничения. В принципе считаю допустимым объединять /boot и /, но для себя стараюсь держать их отдельно. В основном потому что вручную копирую образы для загрузки и прописываю их.

Но когда он за 170 дней намотал 45 ТБ, т.е. 15% от ресурса, снял его нафиг и поставил обычный hdd.

Этовсего лишь значит, что свой гарантированый ресурс он отработает за 3,1 года. Но это гарантированный, а реальный у них просто обязан быть выше. Вот на 3dnews.ru пишут, что при гарантированном ресурсе в 300Тб и предполагаемом 6000 циклов или 1500Тб он выдерживает 2700Тб. А это даёт время службы от 15,5 до 27,9 лет в том же режиме.

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от chukcha

Если у тебя старое железо, лучше делать как деды завещали. /boot первым, потом swap, потом остальное.

Отдельный /boot вроде делали, т.к. bios не видел дальше 2 TB (или 2 GB?), а grub пользовался его средствами для загрузки ядра. Если у тебя современное железо, то не актуально, хотя откуда у тебя тогда вопросы про HDD.

vbr ()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от LeadLed

Можно подумать, они без перемагничивания вечные. У меня 3 года назад сломался один счетчик, год назад другой, без всяких магнитов.

vbr ()
Ответ на: комментарий от DumLemming

Бубунта пихает своп в динамический файл потому, что им так удобней. Вроде как пользователь видит больше свободного места - хорошо! Насчёт износа они скорее всего даже не задумывались.

kirill_rrr ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.