[Просьба] тест патча ядра на Advanced Format дисках (4k sector)

>который не может писать/читать блоками менее, чем по 4k, хотя сообщает о логическом размере в 512 байт.

Непонятно, чем этот патч может помочь. Для суперблока в ext234 есть хак, позволяющий прочитать суперблок со смещением от раздела при любом размере блока, т.е. он тут у вас прочитает 4кб и прибавит, сколько надо. Но дальше-то все I/O по 1 кб все равно не пройдет.

Собственно чтение суперблока — это единственный ввод-вывод, который у меня происходил невыровненным и блоком менее 4кб. С этим патчем ы sb_set_blocksize передается размер 4096, где он заносится в s_blocksize структуры sb. Я не понимаю того, как работает ФС, но могу предположить, что если есть поле s_blocksize, то оно где-то используется.

Вопрос был не в том, поможет ли мне патч. Вопрос заключается в том, не ломает ли он работу ext4 на AF дисках с эмуляцией 512-байтных секторов.

С этим патчем ы sb_set_blocksize передается размер 4096, где он заносится в s_blocksize структуры sb.

static int ext3_fill_super (struct super_block *sb, void *data, int silent) {
...
        blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);

        if (blocksize < EXT3_MIN_BLOCK_SIZE ||
            blocksize > EXT3_MAX_BLOCK_SIZE) {
                printk(KERN_ERR 
                       "EXT3-fs: Unsupported filesystem blocksize %d on %s.\n",
                       blocksize, sb->s_id);
                goto failed_mount;
        }

        hblock = bdev_hardsect_size(sb->s_bdev);
        if (sb->s_blocksize != blocksize) {
...
                sb_set_blocksize(sb, blocksize);

В результате этой операции будет сделано сравнение if (4096 != 1024) и в sb_set_blocksize уйдет 1024. Потом это попадет в sb_blocksize и sb_blocksize_bits, а оттуда для inode в i_blkbits и будет использоваться для чтения и записи данных.

do_mpage_readpage сделает поблочный запрос на чтение. При полном отсутствии фрагментации запрос объединится в один запрос на 4 кб, но при наличии фрагментации уйдут отдельные запросы (и будет облом, если только драйвер сам не умеет обрабатывать эту ситуацию, но по вводным данным не умеет).

уйдут отдельные запросы (и будет облом, если только драйвер сам не умеет обрабатывать эту ситуацию, но по вводным данным не умеет).

Облом будет на моём диске, так как он не может обработать такие запросы.
AF 512e диски умеют читать и писать по 512 байт, но делают это медленно. Приведенный кусок кода не вызовет у них проблем с чтением-записью, просто скорость будет низкая. Собственно у них и на оригинальном ядре будут такие же скорости.

Похоже, нашел способ проверить без покупки AF диска.

diff -ur linux-2.6.38-rc4-orig/drivers/ata/libata-core.c linux-2.6.38-rc4/drivers/ata/libata-core.c
--- linux-2.6.38-rc4-orig/drivers/ata/libata-core.c	2011-02-08 00:03:55.000000000 +0000
+++ linux-2.6.38-rc4/drivers/ata/libata-core.c	2011-03-01 18:01:31.859956475 +0000
@@ -1907,6 +1907,8 @@
 	else
 		err_mask = ata_do_dev_read_id(dev, &tf, id);
 
+	id[106] = 0x6003; // 4kb imitation
+
 	if (err_mask) {
 		if (err_mask & AC_ERR_NODEV_HINT) {
 			ata_dev_printk(dev, KERN_DEBUG,

И все диски «становятся» Advanced Format с эмуляцией.

> do_mpage_readpage

Спасибо за информацию, теперь понятно, в каком направлении двигаться.