URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 63902
[ Назад ]

Исходное сообщение
"Оценка поддержки в Linux жестких дисков с размером сектора 4..."

Отправлено opennews , 15-Фев-10 18:32 
В связи с использованием в новых моделях жестких дисков Western Digital Caviar Green нестандартного размера сектора, увеличенного с 512 байт до 4 Кб, предпринята попытка (http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_f...) оценки степени поддержки таких дисков в Linux. В итоге были получены удручающие результаты: из-за отсутствия выравнивания записываемого кластера данных по границе физического сектора размером 4096 байт (выравнивание производится по 512-байтовым логическим секторам), наблюдается (http://bugs.gentoo.org/show_bug.cgi?id=304727) падение производительности более чем в три раза. Кроме того, при разбивке диска наблюдаются проблемы с вычислением оптимального смещения для первичного дискового раздела, который по умолчанию создается начиная с позиции LBA 63, оставаясь не выравненным по границе цилиндров.

URL: http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_f...
Новость: http://www.opennet.me/opennews/art.shtml?num=25428


Содержание

Сообщения в этом обсуждении
"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Damon , 15-Фев-10 18:32 
Ну чтож, ждем реакции разработчиков ядра. Не думаю, что сей насущный вопрос надолго останется без внимания...

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено dry , 15-Фев-10 19:46 
Много "крутых" слов ни о чем.
Если бы сэр удосужился прочитать статью, а не лепил херь по принципу "первый нах",
то стало бы очевидно, что ядро тут как раз не при чем. Проблема в программах нарезки разделов, которые не учитывают физический размер сектора.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Султан , 15-Фев-10 20:13 
Просвещайтесь:
http://www.fcenter.ru/online.shtml?articles/hardware/hdd/28121



"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Damon , 15-Фев-10 20:53 
>Просвещайтесь:
>http://www.fcenter.ru/online.shtml?articles/hardware/hdd/28121

Спасибо, обязательно просвячусь...


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено kay , 16-Фев-10 08:47 
Опаньки... Может поэтому у меня винт 1.5T тормозит? При форматировании тормоза начинаются на 80 секторе при создании inodes...

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Аноним , 17-Фев-10 12:28 
почему то уверен, что соответствующие патчи радикально все улучшающие будут уже в следующем релизе

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено ddsa , 15-Фев-10 18:33 

я совсем не в теме, поэтому спрашиваю, логическое взаимодействие с диском осуществляется только драйвером ОС или BIOS материнской платы/контроллера тоже должен поддерживать работу с сектором нестандартного размера?

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено dalco , 15-Фев-10 19:16 
BIOS большинству операционок нужен только для того, чтобы начать загрузку, дальше уже работают драйвера. Это хорошая новость.
"Умные" контроллеры со своим BIOS`ом и процессором (а ля RAID-контроллеры e.t.c.) скорее всего не учитывают существование "неправильных" дисков, т.е. будут тормозить или глючить до смены прошивки (если таковая возможна). Это плохая новость.

P.S. Вообще, стандарт на 4К сектора еще чуть ли не в 2003 году был принят, так что это, по идее, не проблемы дисков WD :)


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Аноним , 15-Фев-10 19:03 
Интересно, у freebsd те же проблемы?

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено xxx , 15-Фев-10 20:58 
http://lists.freebsd.org/pipermail/freebsd-arch/2009-Decembe...

Да, схожие с описанными здесь. Разработчики уже думают над решением этих проблем.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Ян Злобин , 16-Фев-10 04:35 
>Да, схожие с описанными здесь. Разработчики уже думают над решением этих проблем.

Нет.  Если верить этому: http://lists.freebsd.org/pipermail/freebsd-arch/2009-Decembe...

UFS runs incredibly well on 4k blocks, and we should exploit that
to the fullest extent, and if we really want to jerk chains, we should
push RAID3 in 4+2 and 8+3 configs aggressively, it performs great,
both under read and write, and Windows cannot do it.

то все отлично.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено xxx , 16-Фев-10 15:04 
Ну там довольно длинное обсуждение было, и судя по всему всё поддерживается, но не совсем так как хотелось бы. Надо в ркопашку ФС выравнивать и т. д.  Поэтому насколько я помню дополнительные телодвижения от разработчиков всё таки потребуются.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено svchost , 15-Фев-10 20:38 
А в чем преимущество 4096 сектора?

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено anonymous , 15-Фев-10 21:11 
1. Увеличение объема жесткого диска за счет того, что меньше места расходуется на служебные нужды.
2. Увеличение шансов на восстановление неправильно считавшихся битов за счет того, что под контрольную сумму отводится больше места.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено аноним , 15-Фев-10 21:45 
Linux, равно как и FreeBSD, отлично поддерживают сектора любого размера. Проблема в другом - их не поддерживает "другая ось", и ориентируясь на нее, производители жестких дисков над 4kb секторами сделали костыльную прослойку из-за которой ОС видны 8 512байтовыех секторов. Дальше - закон дырявых абстракций в действии. Под FreeBSD я никогда не выравнивал разделы по 63 секторам, во многом потому что никогда не использовал yблюдскую MBR разметку - это и без 4кб секторов было актуально на стрипах, иначе получался заметный оверхед.
А все что нужно сделать разработчикам - поменять дефолты на человеческие, и выковырять любые сообщения о "неверной геометрии" чтобы не смущать пользователей. Для FreeBSD это актуально - постоянно жалуются что sysinstall ругается на геометрию, когда никакой геометрии уже лет 5 как не существует.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено cvsup , 15-Фев-10 23:15 
Целиком поддерживаю. Кроме того, в freebsd-arch есть длинное обсуждение по этой теме:
http://lists.freebsd.org/pipermail/freebsd-arch/2009-Decembe...

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено letsmac , 16-Фев-10 10:39 
"Другая ось" их таки поддерживает. Молчком, но поддерживает. Вместо MBR давно можно использоваться EFI.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено крф , 20-Апр-10 09:01 
>"Другая ось" их таки поддерживает. Молчком, но поддерживает. Вместо MBR давно можно
>использоваться EFI.

самая свежая и перед этим - да.
а самая популярная - нет.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Michael Shigorin , 16-Фев-10 23:01 
>это и без 4кб секторов было актуально на стрипах

См. тж. http://www.pythian.com/blogs/411/aligning-asm-disks-on-linux и другие ссылки внизу http://freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID (гругря "пропускаем первый мегабайт, если уж надо dos partition table").


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено pavlinux , 16-Фев-10 00:12 
Э-э-э-э , типа

# mkfs.reiserfs -b 4096
# mkfs.ext[234] -b 4096 -I 4096
# mkfs.btrfs -s 4096
# mkfs.cramfs -b 4096  
...
XFS только 2k понимает.



"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Yuriy , 16-Фев-10 02:18 
man mkfs.xfs
-s sector_size
The default sector_size is 512 bytes. The minimum value for  sector  size  is 512; the maximum is 32768 (32 KiB).


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено pavlinux , 16-Фев-10 03:30 
>man mkfs.xfs
>-s sector_size
>The default sector_size is 512 bytes. The minimum value for  sector
> size  is 512; the maximum is 32768 (32 KiB).
>

-i ?


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Yuriy , 16-Фев-10 03:40 
-i inode_options
это размер индексного дескриптора

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено pavlinux , 16-Фев-10 03:53 
>-i inode_options
>это размер индексного дескриптора

Ну... для Линя минимальная лог. ед. это же инода.
Чудесно начинают работать харды, когда inode = sector = block (ака BLK_SIZE || PAGE_SIZE)


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено sceptic , 16-Фев-10 10:31 
Итак? На чём сошлись?
/me как раз собирался взять такой диск от WD

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено letsmac , 16-Фев-10 10:42 
>Итак? На чём сошлись?
>/me как раз собирался взять такой диск от WD

/me мацал и такой и от самсунга. Опыт показал, что самсунг холоднее на боллее чем 10 градусов (два месяца аптайм), и на 10-20%  производительнее в режиме NAS / динамические диски. Корейцы одерживают Win.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено sceptic , 16-Фев-10 11:02 
>>Итак? На чём сошлись?
>>/me как раз собирался взять такой диск от WD
>
>/me мацал и такой и от самсунга. Опыт показал, что самсунг холоднее
>на боллее чем 10 градусов (два месяца аптайм), и на 10-20%
> производительнее в режиме NAS / динамические диски. Корейцы одерживают Win.
>

Что за модель? :) я хочу 1-1.5tb


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено hate , 16-Фев-10 11:05 
>>Итак? На чём сошлись?
>>/me как раз собирался взять такой диск от WD
>
>/me мацал и такой и от самсунга. Опыт показал, что самсунг холоднее
>на боллее чем 10 градусов (два месяца аптайм), и на 10-20%
> производительнее в режиме NAS / динамические диски. Корейцы одерживают Win.
>

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


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено letsmac , 16-Фев-10 16:00 
>>осему любая ошибка которая лечится такой тулзой заставляет эти диски, по причинине отсутствия оной, выкидывать на помойку.

Samsung, не Seagate - у них багов с переполнением логов и необходимости перепрошиваться пока не было. Вообще самые надёжные винты - проверено сервисом. Ручное вмешательство в их работу не требуется.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Michael Shigorin , 16-Фев-10 23:13 
>Samsung, не Seagate - у них багов с переполнением логов и необходимости
>перепрошиваться пока не было. Вообще самые надёжные винты - проверено сервисом.

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

У Seagate ES.2 объёмами ~500--1000Gb были проблемы с задранной плотностью адаптивного форматирования первых треков -- поставщик советовал отбить первый гиг и не трогать.  7200.9 (200/400Gb как минимум) сыпались чуть ли не от прикосновения к верхней крышке, про терабайтники тоже много страшных отзывов -- решил не экспериментировать.

Так что кто как, а я из SATA предпочитаю Hitachi/WD.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено аноним , 18-Фев-10 20:09 
> Hitachi

Ну Hitachi - гно. В массиве из 6 дисков на 3 постоянно есть сектора, которые не читаются, но и не реаллокейтятся - выявляются ZFS scrub'ом. Т.е. по сути, не в составе RAID с избыточностью это г-но использовать нельзя. Просто курам на смех.

Я вот думаю что купить из 2TB - явно не хитачи, тем более у них 2TB убогие пятипластинчатые. Самсунги это х* с горы, к ним никакого доверия (тем более ecogreen F2 показывали падение скорости в 10 раз при многопоточном чтении. 2TB у них F3, но все же) - значит seagate или вестерны, третьего не дано.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Michael Shigorin , 20-Фев-10 13:19 
>[...] Т.е. по сути, не в составе RAID с избыточностью
>это г-но использовать нельзя. Просто курам на смех. [...]
>Я вот думаю что купить из 2TB - явно не хитачи, тем
>более у них 2TB убогие пятипластинчатые.

Вы, как бы это сказать помягче, "воинствующий чайник". :(

Во-первых -- есть проблемы, замените поштучно запасным и тащите по гарантии.  Вне зависимости от производителя конкретного диска.

Во-вторых -- много пластин => много головок и треков под ними, что хуже по части механики, но повышает шанс попадания нужных данных без сика.

В-третьих, у hitachi унаследован ibm'овский микрокод -- и как раз у пятиблинников поведение на многопоточной нагрузке (или Ваш страйп хранит кэш /dev/random для одного пользователя?) обычно схожее на Ultrastar или вообще на SAS:
http://www.fcenter.ru/online.shtml?articles/hardware/hdd/278...

JFYI, на ftp.linux.kiev.ua четыре диска из восьми (это уже третья пачка хитачей) -- как раз пятиблинные HDS721010KLA330, безупречно себя ведущие уже год под постоянной нагрузкой.

>значит seagate или вестерны, третьего не дано.

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

У меня на хозяйстве в разные годы бывали и те, и те, и те -- и сейчас есть разные; Seagate последние лет пять предпочитаю избегать, слишком проблемные, а сейчас ещё и ничем полезным не выдающиеся.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Yuriy , 16-Фев-10 12:42 
>Ну... для Линя минимальная лог. ед. это же инода.

inode это не данные и даже не метаданные и тем паче не лог. ед. Это только дескриптор данных. Ко всему прочему в xfs inodes сгрупированы по 64 айнода. Плюс ко всему в описании xfs от sgi не двусмысленно записано
sb_inodesize
Size of the inode in bytes. The default is 256 (2 inodes per standard sector) but can be made as large as 2048 bytes when creating the filesystem.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено pavlinux , 16-Фев-10 00:20 
Честно говоря не фкурю зависимость :)


[512][512][512][512][512][512][512][512][512][512][512][512][512][512][512][512]
[                 4096                 ][                 4096                 ]

Если у меня фаил 4Mb + 256 бaйт  - какая мне х... разница,
что  диск за одно обращение впишет 256 + 3768 нулей, что 256 + 256 нулей.
Обращение-то одно? И пипец, с сектором в 4K, 3 кило с лишним потеряем.

  


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено pavlinux , 16-Фев-10 01:18 
> И пипец, с сектором в 4K, 3 кило с лишним потеряем.

Всё, вурил, - народ перестал покупать диски,
теперь у населения 1G картинок будет занимать 4Gb.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено sergej , 16-Фев-10 03:15 
нормальные ФС заполняют остатки блоков совмещая хвосты нескольких файлов в одном блоке. А так да - конечно же это опять мировой заговор производителей железа.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено pavlinux , 16-Фев-10 03:47 
>нормальные ФС заполняют остатки блоков совмещая хвосты нескольких файлов в одном блоке.

Только не ясно как работает диск при этом??? Ведь для него же одна логическая ед. это 1 сектор.

Можно, наверно как-то так...


[  512  ][  512  ][  512  ][  512  ][  512  ][  512  ][  512  ][  512 ]
[                         4096                                        ]
[sdfr00000000000000000000000000000000000000000000000000000000000000000]

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

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено denis111 , 16-Фев-10 04:24 
Они своим смартом занимаются, куда им ещё журналировать :)

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Michael Shigorin , 17-Фев-10 00:29 
>нормальные ФС заполняют остатки блоков совмещая хвосты нескольких файлов в одном блоке.

Не знаю как "нормальные", а конкретно для reiserfs 3.6 рекомендуется -o notail.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено azure , 16-Фев-10 10:56 
А размер блока файловой системы у тебя тоже 512? :) Обычно больше. Зато тысяча четырехкилобайтных блока займет _физически_ на блине меньше места чем 8 тысяч 512-байтных блоков, поэтому и быстрее считается при прочих равных.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Frank , 16-Фев-10 10:35 
Как сказали знающие люди, parted уже умеет правильно работать с 4к сектором, шумиха высосана из пальца.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено sceptic , 16-Фев-10 10:47 
>Как сказали знающие люди, parted уже умеет правильно работать с 4к сектором,
>шумиха высосана из пальца.

пруфф? ещё лучше если на релизченджлог, или на коммит мессадж.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Frank , 16-Фев-10 10:59 
Читаем каменты к статье по первой ссылке в новости.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Frank , 16-Фев-10 11:06 
или читаем на первоисточнике, http://www.gnu.org/software/parted/features.shtml :
Support for logical sector sizes not equal to 512

А вот и цитата из FAQ (http://www.gnu.org/software/parted/faq.shtml):

Does GNU Parted support physical sector sizes not equal to 512?
    Starting from 1.7, GNU Parted will automatically align partitions to the physical sector size reported by an ATAPI-compliant drive.


"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено Frank , 16-Фев-10 11:08 
Замечу так же, что parted 1.7.1 лежит на ФТП с 27.05.2006, т.е. проблемы нет уже более двух с половиной лет. Но слоупоки, юзающие fdisk, такие слоупоки :)

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено RedRat , 17-Фев-10 14:01 
Мне пару дней назад подарили такой 2Тб винт WD20EARS с 4Кб секторами. Жалко, что WD не оставила возможности выключить в своих винтах ублюдочный режим эмуляции 512-байтных секторов. Я бы предпочёл ручками выровнять разделы и создать ФС с 4Кб блоками, чем наблюдать падение производительности при записи мелких файлов.

"Оценка поддержки в Linux жестких дисков с размером сектора 4..."
Отправлено аноним , 18-Фев-10 20:11 
>Мне пару дней назад подарили такой 2Тб винт WD20EARS с 4Кб секторами.
>Жалко, что WD не оставила возможности выключить в своих винтах yблюдочный
>режим эмуляции 512-байтных секторов. Я бы предпочёл ручками выровнять разделы и
>создать ФС с 4Кб блоками, чем наблюдать падение производительности при записи
>мелких файлов.

Противоречия тут не находите?