У меня жесткий диск с 4кБ секторами (на 1.5Тб), сделал один раздел, отформатировал - никаких проблем (и с reiserfs, и с ntfs работает нормально).

Не знаю, была ли там эмуляция, я просто вставил новый жесткий диск, запустил fdisk, а затем mkfs.reiserfs - и все...

У меня жесткий диск с 4кБ секторами (на 1.5Тб)

Подозреваю, что это Western Digital. У них специальная логика на контроллере, Read-Modify-Write. Внешне видятся как обычные, с 512-байтными секторами.

У меня такого нет, попытка записать блок размерами не кратным 4096 вызывает ошибку DMA.

Точно, WD. Тогда понятно...

А почему вы gpt даже не пытались сделать? А вдруг получится?

Там запятая была. Я использую GPT. Я даже не пытался делать msdos, так как это практически гарантированно приводит к невыровненным на 4096 байт разделам.

use eyes, Luke

>А конкретнее Toshiba MK1231GAL.

Спасибо, что указали на ошибку. Но мне не понятно, что имелось в виду? Просто указание на ошибку или призыв использовать google? Если второе, то всё, что я нашел, это отзывы о полной неработоспособности. Ситуаций, аналогичных моей я не встречал.

Если вы нашли решение просто вбив в поисковик ключевую фразу, прошу вас поделиться ею. Мои поиски окончились безрезультатно.

попробуй на него reiserfs-3.6

попробуй на него reiserfs-3.6

Пробовал форматировать в reiserfs с livecd ubuntu 10.04. Версия reiserfsprogs там - 3.6.21. Куча сообщений об ошибках, либо при создании, либо при монтировании, этого точно не помню.

В принципе, можно жить и на JFS, как сейчас, но мне привычнее семейство ext.

P.S. Кроме того, я пробовал fat16, fat32, ntfs, ext2, ext3, с тем же отрицательным результатом.

Какая версия ядра и util-linux-ng? fdisk до версии util-linux-ng 2.18 по умолчанию создавал невыровненную DOS таблицу разделов. Попробуйте всё же DOS таблицу вместо GPT, явно указав fdisk'у выравнивание разделов.

Кстати, у первых хардов WD с 4К сектором был баг — они рапортовали размер сектора 512 байт, ну и софт вел себя соответствующе. В вашей тошибе нет такой проблемы?

поищи здесь
http://forum.xda-developers.com/archive/index.php/t-377684.html
http://forum.thinkpads.com/viewtopic.php?f=3&t=83139
http://iaudiophile.net/forums/showthread.php?t=32420
http://www.anythingbutipod.com/forum/showthread.php?t=35196
http://www.anythingbutipod.com/forum/showpost.php?p=375681&postcount=20
http://www.experts-exchange.com/Apple/Operating_Systems/OS_X/Leopard_MAC_OS_1...

http://lwn.net/Articles/322777/

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sect...

util-linux     2.17.2-3.3
kernel         2.6.32-5-686 #1 SMP i686 GNU/Linux
debian squeze

Попробуйте всё же DOS таблицу вместо GPT

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

Кстати, у первых хардов WD с 4К сектором был баг — они рапортовали размер сектора 512 байт, ну и софт вел себя соответствующе. В вашей тошибе нет такой проблемы?

В моей Toshiba проблема в том, что она не понимает, когда от нее хотят 512-байтных секторов. Совсем. Только 4096-байтные. (Они вообще не были предназначены для ноутбуков, поэтому слоя эмуляции, как в WD просто нет). А в BIOS жестко закодирована работа только с 512. В GRUB2 тоже, я смотрел. В ядре не знаю, сложновато для меня, но в логах есть упоминание о 4096 physical, 512 logical, то есть ядро «считает», что хорошо бы писать блоками по 4096, но если припрёт, можно и 512 записать.

При попытке записи на раздел с помощью dd if=/dev/zero of=/dev/sda3 bs=4096 count=1 я получаю:

[ 1359.958545] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 1359.961519] ata2.00: BMDMA stat 0x5
[ 1359.964469] ata2.00: failed command: READ DMA
[ 1359.967388] ata2.00: cmd c8/00:06:c0:91:81/00:00:00:00:00/ed tag 0 dma 3072 in
[ 1359.967392]          res 51/10:06:c0:91:81/00:00:00:00:00/ed Emask 0x81 (invalid argument)
[ 1359.973254] ata2.00: status: { DRDY ERR }
[ 1359.976252] ata2.00: error: { IDNF }
[ 1360.000530] ata2.00: configured for UDMA/100
[ 1360.003431] ata2: EH complete

Насколько я понял, диск выдал ошибку при попытке записи блока из 3072 байт. В лог вываливается тонна таких ошибок, и во всех 1024, 2048 и 3072. И нигде 4096. Я так понимаю это косвенно говорит о том, что 4096 пишется успешно и диск не ругается.

Читается всегда успешно, без ошибок.

> Не вижу, почему msdos-вариант мне поможет, но я попробую.

Просто я не уверен, что gdisk (или чем вы создавали GPT таблицу разделов?) правильно выравнивает разделы на 4К. Кстати, тот же gdisk должен уметь распечатывать GPT аналогично fdisk'у. Что он говорит?

В моей Toshiba проблема в том, что она не понимает, когда от нее хотят 512-байтных секторов. Совсем. Только 4096-байтные. (Они вообще не были предназначены для ноутбуков, поэтому слоя эмуляции, как в WD просто нет). А в BIOS жестко закодирована работа только с 512. В GRUB2 тоже, я смотрел.

В таком случае вы не смогли бы с этого диска загрузиться.

Насколько я понял, диск выдал ошибку при попытке записи блока из 3072 байт. В лог вываливается тонна таких ошибок, и во всех 1024, 2048 и 3072. И нигде 4096. Я так понимаю это косвенно говорит о том, что 4096 пишется успешно и диск не ругается.

Скорее похоже на то, что партиция не выровнена на 4К. То есть запись на ФС 4КБ пересекает границу сектора, ядро пытается разбить операцию за 2 записи (1КБ + 3КБ или 2КБ + 2КБ), а девейс этого не понимает.

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

ниже — некоторые цитаты из приведенных ссылок:

http://forum.xda-developers.com/archive/index.php/t-377684.html

I can now confirm that the 1231gal wil not work with htc shift!!

but either the Acronis SWs do not Recognize the HDD (Toshiba MK1231GAL). The message is «Failed to read from the sector 0 of hard disk 0».

Just BIOS looks like recognized disk, showed correct type and capacity 160 GB as on label but not actual one and below that, «Hard Disk Error» and stop [...]

http://forum.thinkpads.com/viewtopic.php?f=3&t=83139

but there were several people having problems with the Toshiba MK1231GAL (I remembered this particular model as I was intending to by one) even using Win7 and the newest Linux Distros.

http://iaudiophile.net/forums/showthread.php?t=32420

Thx for you reply, I'll try that this evening... But I think it's kind of a compatibility issue there (IDE SATA3/4 vs IDE SATA 7) as windows won't even want to format it (i know it wouldn't be good but though it seems not be really recognized...) Maybe 1231 is not a good choice after all ^^'

So I have to find a 1231gal non-«apple prepared»

http://www.anythingbutipod.com/forum/showthread.php?t=35196

This hard drive will only work in an iPod. This hard drive will NOT work in a Creative Labs MP3 Player, Zune 30GB, laptop or computer. Compatibility with Zune 80GB/120GB is unknown

http://www.anythingbutipod.com/forum/showpost.php?p=375681&postcount=20

Заработал в Zen Vision M (плеер).

http://www.experts-exchange.com/Apple/Operating_Systems/OS_X/Leopard_MAC_OS_1...

According to Toshiba: Dear Mr. xxx, thank you for contacting the Toshiba Storage Device Division of Toshiba Europe. The MK1231GAH has a 4KB Block Size (physical) - not to be confused with the logical Block Size, which can be selected when formatting a HDD. The Block Size of the MK1231GAH is 4KB and physical, and it is unchangeable defined on the platter. This makes the HDD incompatible for the use in a Notebook or PC/Mac/Linux application. It is for the use in consumer electronic (CE) applications only.

http://lwn.net/Articles/322777/

Обсуждение общей проблемы. Упоминаемый патч уже в ядре, частично работает.

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sect...

Обсуждается Western Digital Caviar Green. Проблема состоит не в неработоспособности, а в пониженной производительности. Эти диски были специально укомплектованы логикой Read-Modify-Write для поддержки текущего оборудования.

Забавное наблюдение — многие считают, что эта модель «запаролена» Apple или специально для них подготовлена, имеет специальную прошивку.

чем вы создавали GPT таблицу разделов?

Создавал с помощью parted.

# parted /dev/sda
parted> unit MiB
parted> mklabel gpt
parted> mkpart ...
parted> mkpart ...
...

В таком случае вы не смогли бы с этого диска загрузиться.

Да, я знаю. Поэтому я впаял usb-флешку в нетбук и теперь у меня на ней /boot. GRUB этот диск видит, только если загрузить модуль ata.mod . Но это все равно бесполезно, так как BIOS не может загрузить GRUB с этого диска (делает вид, что диска у меня нет).

Вот таблица разделов

(parted) unit B                                                           
(parted) print                                                            
Model: ATA TOSHIBA MK1231GA (scsi)
Disk /dev/sda: 120034123776B
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start          End            Size           File system  Name    Flags
 1      1048576B       16777215B      15728640B                   grub-0  bios_grub
 2      16777216B      115016777727B  115000000512B  jfs

Выравнивание, вроде бы, в порядке.

Насчёт reiserfs я ошибся, reiserfs работает нормально. Я протестировал все файловые системы, до которых смог добраться в LiveCD Ubuntu 10.04.1:
ext2 создаётся, не монтируется
ext3 создаётся, не монтируется
ext4 создаётся, не монтируется
bfs создаётся, не монтируется
jfs создаётся, монтируется, работает
reiserfs создаётся, монтируется, работает (и format3.5, и format3.6)
ntfs не создаётся
minix создаётся, не монтируется
vfat (32) создаётся, не монтируется
xfs не создаётся
btrfs создаётся, монтируется, работает

Переход на msdos label ничего не дал, результаты те же.

Я покопался в libata. В ядре (2.6.36.1) ужасно мало комментариев, видимо все должно быть понятно из кода. Осознал, наконец, почему все диски стали вместо hdX — sdX.

В процессе созерцания выяснилось, что libata считает, что у всех дисков логические сектора по 512 байт (других дисков на декстопах пока и не было), а размер физического сектора сообщает сам диск, в 106-м слове ATA ID.

Из спецификации ATA-8 выяснилось, что диск вообще-то обязан не только указывать, какой у него размер физического сектора (желаемый размер io), но и какой у него размер логического блока (минимальный размер io) — в словах 118:117. Размер указывается тоже в словах (u16).

В общем, я осознал, что добавить такую функциональность я не смогу. Но к счастью, с помощью поиска по теперь известным ключевым словам, выяснилось, что нужный мне код был уже написан и вошёл в 2.6.37-rc1. А 2.6.37-rc5 как раз вчера попал в experimental ветку debian.

Уверовав в чудо и знак свыше, я попробовал поставить, но чуда не произошло. В dmesg по прежнему логический блок — 512 байт. Toshiba MK1231GAL рапортует о размере блока в 256 слов. Но работать может только с блоками в 2048 слов. Облом.

Попробовал в функцию blk_queue_update_dma_alignment принудительно передавать выравнивание на 4096 байт. Опять ничего не вышло. Видимо выравнивание используется только для начала блока dma.

Надо попробовать подменить данные ATA ID.

P.S. Это превращается в мой личный блог.

Попробуй задать вопрос в LKML. Думаю достаточно шарящие в устройстве дисковой подсистемы ядра люди есть только там.

Попробуй задать вопрос в LKML

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

А на bugzilla.kernel.org баги без подробных описаний и попыток самостоятельного решения висят годами.

Так что у меня два пути - либо забить, либо копать самому, пока не станет ясно, что именно надо поменять в ядре.

Думаю, лучшее, что случится - меня проигнорируют.

Если правильно задашь вопрос - не должны проигнорировать. Тем более тебя за письмо никто не покусает, ведь так? =)

Вот кстати интересная информация на тему: https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues.

As of v2.6.33, Linux ATA drivers do not support drives with 4KiB logical sector size although there is a development branch containing experimental support[11]. For ATA drives connected via bridges to different buses - USB and IEEE 1394, as long as the bridges support 4KiB logical sector size correctly, the SCSI disk driver can handle them.

[11] git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git sectsize

Если правильно задашь вопрос - не должны проигнорировать. Тем более тебя за письмо никто не покусает, ведь так? =)

Твоя правда. Только я не умею правильно вопросы задавать.

Вот кстати интересная информация на тему: https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues.

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

Надо попробовать подменить данные ATA ID.

Уравнял логический блок с физическим, поставил 1:1 и 4096.

Читить с ID блоком была изначально плохая идея. Жесткий диск ожидает, что смещения и размеры будут передаваться в единицах логических секторов. Я не потерял данные, но и загрузиться не смог.

В ошибках были сообщения о невозможности прочитать блок размером в 4096. Если ядро считает, что логический сектор 4096 байт, оно пошлет запрос на чтение одного блока, который для диска равен 512 байтам. Похоже, что ошибки возникают как при некратном чтении, так и при записи. Возможно, что на уровне пользователя все работает нормально благодаря тому что minimum_io_size равен 4096.

Попробовал покопать с другой стороны и убрать внешние проявления ошибок. Ошибка происходит при чтении суперблока (unable to read superblock). Читать ядро его пытается блоком в 1024 байта.

За десяток строк до вызова sb_bread вычисляется размер блока (похоже на размер блока блочного устройства) с помощью вызова sb_min_blocksize. А в нём, в свою очередь, вызывается bdev_logical_block_size, откуда вызывается queue_logical_block_size, которое берёт logical_block_size из limits устройства, то есть 512. А, и ещё — у sb_bread есть ещё и второй параметр, она возвращает максимальное из него и того, что вычислили более глубокие функции, которые в ней вызывались. Для ext4 передается константа, равная 1024. Похоже, причина в этом.

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

Сломался или код, обеспечивающий чтение GPT, или код, который определяет вид таблицы разделов.

Сломался fs/partitions/efi.c . В нём bdev_logical_block_size используется, чтобы получить lba секторов. Код таблицы разделов менять уж точно не стоит, ведь он и так работал.

Первый успех.

Для блочного устройства можно установить размер блока. Для ext4 размер блока устанавливается через цепочку вызовов sb_min_blocksize -> sb_set_blocksize -> set_blocksize. Все определены в fs/block_dev.c.

sb_min_blocksize — это по сути способ договориться с блочным устройством о размере, она возвращает максимальное значение из передаваемого ей параметра и размера логического сектора. Дальше полученное от этой функции значение запоминается и используется везде в драйвере ext4. Подсунув ей в качестве параметра 4096, я получил работающую ext4.

Поменяв в sb_min_blocksize вызов bdev_logical_block_size на bdev_physical_block_size, я похоже, решу проблему для ext2, ext3 и ext4. И похоже, это будет правильно, так как по сути sb_min_blocksize — это поиск не самого минимального, а минимально приемлемого размера блока, наподобие /sys/block/sda/queue/minimum_io_size.

diff -ur vanilla/linux-2.6.37-rc5/fs/block_dev.c linux-2.6.37-rc5/fs/block_dev.c
--- vanilla/linux-2.6.37-rc5/fs/block_dev.c	2010-12-07 04:09:04.000000000 +0000
+++ linux-2.6.37-rc5/fs/block_dev.c	2010-12-15 20:11:19.311387630 +0000
@@ -121,7 +121,7 @@
 
 int sb_min_blocksize(struct super_block *sb, int size)
 {
-	int minsize = bdev_logical_block_size(sb->s_bdev);
+	int minsize = bdev_physical_block_size(sb->s_bdev);
 	if (size < minsize)
 		size = minsize;
 	return sb_set_blocksize(sb, size);

Что интересно, с измененным ядром mkfs.ext4 отказывается создавать ФС с размером блока, меньшим 4096.

Но с другими ФС дело глухо, многие из них игнорируют результат sb_min_blocksize.

Заработали ext2, ext4, hfs, hfsplus и msdos (только если создать с -S 4096). На целостность и сохранность данных не проверял.

Не подскажете, чем проверяют ФС?

Можно проверять руками:

Залить файлов, для которых посчитаны MD5. Проверить их. Поудалять, поперемещать, покопировать. Проверить. Пройтись fsck. Ну и так далее, пока не надоест.

Забил раздел файлами с данными из /dev/urandom, контрольные суммы сошлись. Погонял fileop из iozone3, ошибок не было.

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