Что означают значения Start и End в fdisk при взгляде на компактную флэш-память
Most Ironclad way & maximize uptime...
Я думаю, что вопрос в целом хороший, но ответить на него будет проблематично, учитывая текущее состояние всего, из чего состоит Linux, и аппаратного обеспечения. Может быть более одного правильного ответа, и тогда это все еще можно рационально аргументировать. Лучшим ответом на этот вопрос может быть ответ на вопрос, чего не следует делать...
- понимать ваше оборудование и использовать хорошее оборудование
- аппаратный RAID лучше, чем программный RAID (mdadm)
- Я столкнулся с повреждением данных с программным RAID (mdadm )на устройствах хранения JBOD из-за отключения питания, поэтому я всегда выбираю проверенное аппаратное оборудование RAID, когда это возможно, иначе вы рискуете. Не используйте программный рейд, если вы настроены серьезно
- иметь какой-либо источник бесперебойного питания (ИБП )для работы в случае отключения электроэнергии и понижения напряжения -нужно только поддерживать работу достаточно долго, чтобы выполнить корректное отключение для сохранения данных
- понять RAID :избыточный массив независимых дисков = это может быть решение «установи и забудь», если оно сделано на аппаратном уровне и сделано правильно. Если вам не нужно более 2 дисков для увеличения емкости хранилища, придерживайтесь простого RAID -1. один диск выходит из строя, вы все еще работаете, как будто ничего не произошло, в противном случае используйте 3 диска в качестве RAID -6 с отказоустойчивостью 2 дисков если вы параноик.
- понимаете, что RAID не является резервным. Таким образом, используйте 2 или 3 диска в виде RAID -1 или RAID -6, поскольку ваш корневой раздел, загрузчик BIOS или efi загружает этот один диск(томом рейда ). Имейте отдельный диск... где-нибудь в другом месте, это зеркальная копия того, что находится на активном томе RAID с двумя или тремя дисками. Когда это повреждается (, независимо от рейда ), вы прибегаете к восстановлению из любой резервной копии.
- иметь некоторое представление о аварийном восстановлении и о том, какой контекст это означает для вашего сценария;иметь возможность исправлять и восстанавливать любую возникшую проблему и знать, сколько времени это займет у вас.
- Возможно НЕ использовать революционно новую файловую систему, которая коренным образом меняет способ администрирования файловых систем , что является описанием ZFS. Я бы порекомендовал придерживаться чего-то проверенного, такого как EXT3, EXT4 или XFS, и, возможно, BTRFS, но только если дистрибутив Linux хорошо его поддерживает. Проблемы часто связаны с ошибками в файловой системе, которые можно исправить... если вы понимаете инструменты, доступные для этой файловой системы.
- Практически каждый дистрибутив Linux поддерживает EXT3 и XFS, EXT4 и BTRFS могут быть не во всех дистрибутивах, если только не используется их последняя версия, и используется хороший дистрибутив Linux. Для наиболее прочных я бы рекомендовал склоняться к одному из корпоративных Linux... RHEL, SLES, CentOS, где есть хорошая поддержка.
CentOS 6 fdiskпо-прежнему по умолчанию использует цилиндры в качестве единиц измерения по умолчанию при отображении таблицы разделов. Как прокомментировал zevzek, это устарело, и вы должны использовать fdisk -u=sectors -l, чтобы лучше соответствовать реальности современных устройств хранения, а также тому, как более поздние версии fdiskотображают его по умолчанию.
Значения CHS в фактической таблице разделов имеют довольно ограниченные максимальные значения:
- поле цилиндров имеет ширину всего 10 бит (= значения 0 -1023)
- поле заголовков имеет ширину 8 бит (= значения 0 -255)
- поле секторов имеет ширину 6 бит (= значения 0 -63)
Таким образом, из вашей таблицы разделов начальный CHS (3 байта )начинается с адреса 0x1bf, с началом H = 1, S = 3 и C = 1. Это выглядит неправильно.
Расположение 0x1c2 — это тип раздела (0x83 ), а сразу после него — конечное значение CHS (3 байта )в расположении 0x1c3 и далее.
Второй красный кадр в вашем шестнадцатеричном дампе указывает не на правильное место :значение в 0x1c3 является конечным значением H (0x14 = 20 ).
Значение по адресу 0x1c4 определяет значение конечного сектора в нижних 6 битах и два старших бита значения конечного цилиндра в верхних 2 битах. Таким образом, 0xe8 = 11 101000 в двоичном формате, поэтому конец S будет равен 40. Два старших бита конечного значения C представляют собой шестнадцатеричную цифру 3.
Значение в 0x1c5 определяет младший байт конечного значения C :вместе с двумя старшими битами из предыдущего байта, значение конечного цилиндра равно 0x3b4 = 948.
(Эти значения будут представлять раздел размером всего около 378 МБ, поэтому по сравнению со значением размера раздела в 4 -байта после таблицы разделов конечное значение CHS в таблице разделов явно является полной чепухой.)
Но независимо от того, как вы его нарезаете, это создает ограничение в 7,87 ГиБ / 8,45 ГБ, при котором битовые значения полей CHS в таблице разделов становятся все -единицами, и эти поля не могут представлять никаких значений. больше, чем это.
Это было дополнительно осложнено тем, что спецификация контроллера диска IDE имела другой набор пределов CHS :контроллер IDE мог принимать значения CHS до 65536 цилиндров (0 -65535 )и 255 (1 -255 )секторов, но только до 16 (0 -15 )головок. Если вы просто используете значения CHS, как -, то вместе с ограничениями MBR это приведет к ограничению всего 504 МБ / 528,4 МБ.
По этой причине с июля 1994 г. существует соглашение о преобразовании геометрии для адаптации значений CHS к текущему варианту использования. Таким образом, 2242 цилиндра, 21 головка и 40 секторов — это то, что аппаратное обеспечение называет реальной геометрией, а значения, используемые в таблице разделов, основаны на переведенной, фальшивой геометрии, чтобы значения соответствовали геометрии. поля таблицы разделов и самые старые системные вызовы BIOS. Этот перевод обычно включает выбор числа N, деление физического значения C на N и умножение физического значения H на N. Значение N часто бывает 2, 4, 8 или 15. (Да, 15 вместо 16, чтобы обойти ошибку в MS -DOS, старых версиях Windows и некоторых старых BIOS.)
И при выходе за пределы 8,45 ГБ значения CHS в любом случае бесполезны, поэтому любая современная ОС обычно прямо игнорирует значения CHS и вместо этого использует 4 -байтовых значения LBA. номер первого блока раздела и общее количество блоков в разделе, чтобы фактически определить местоположение и размер раздела. Эти 4 -байтовых значения всегда должны быть точными и однозначными.
При использовании классического размера сектора в 512 -байт этих значений в 4 -байт будет достаточно для дисков размером до (2^32 -1 )блоков или в других слов, чуть менее 2 ТиБ или 2,19 ТБ.
В случае вашего раздела,ваш второй красный кадр в шестнадцатеричном дампе на самом деле указывает на 0x1c6 и далее, что является LBA #первого блока раздела :, поскольку он представлен в формате с маленьким -порядком байтов, значение равно 0x800 в шестнадцатеричном формате или 2048 в десятичной системе. Это соответствует современному стандартному соглашению о том, что первый раздел начинается ровно на 1 МБ от начала диска.
Длина раздела указывается начиная со смещения 0x1ca и составляет 0x1cb000 = 1 880 064 блока или 918 МБ / 940 МБ.
Вы можете видеть, что даже аппаратная -сообщенная геометрия CHS 21 heads, 40 sectors/track, 2242 cylindersдает всего 2242 *40 *21 = 1 883 280 секторов, или 1883280 *512 = 964 249 360 байт, в то время как фактическая емкость диска сообщается как 964 583 424 байт.
Это еще одно указание на то, что «геометрия» CHS является лишь приближением для устаревших устройств и операционных систем, в то время как точная емкость отличается.
Думаю, fdiskпросто делает все, используя представление LBA, и при запросе на отображение начального и конечного значений раздела в виде цилиндров просто вычисляет их на основе значений положения и размера LBA, полностью игнорируя начальные/конечные значения CHS в таблице разделов. Точно так же столбец Blocks, по-видимому, фактически отображает размер раздела в базовых -2 килобайтах.