software raid тормозит

f в мане и f в статье на Википедии - просто совпадение.

Нет, не совпадение. Специально заглянул в код ядра: «distance between far copies. This is size / far_copies».

/usr/src/linux/drivers/md/raid10.h

#ifndef _RAID10_H
#define _RAID10_H

typedef struct mirror_info mirror_info_t;

struct mirror_info {
	mdk_rdev_t	*rdev;
	sector_t	head_position;
};

typedef struct r10bio_s r10bio_t;

struct r10_private_data_s {
	mddev_t			*mddev;
	mirror_info_t		*mirrors;
	int			raid_disks;
	spinlock_t		device_lock;

	/* geometry */
	int			near_copies;  /* number of copies laid out raid0 style */
	int 			far_copies;   /* number of copies laid out
					       * at large strides across drives
					       */
	int			far_offset;   /* far_copies are offset by 1 stripe
					       * instead of many
					       */
	int			copies;	      /* near_copies * far_copies.
					       * must be <= raid_disks
					       */
	sector_t		stride;	      /* distance between far copies.
					       * This is size / far_copies unless
					       * far_offset, in which case it is
					       * 1 stripe.
					       */

	sector_t		dev_sectors;  /* temp copy of mddev->dev_sectors */

	int chunk_shift; /* shift from chunks to sectors */
	sector_t chunk_mask;

	struct list_head	retry_list;
	/* queue pending writes and submit them on unplug */
	struct bio_list		pending_bio_list;


	spinlock_t		resync_lock;
	int nr_pending;
	int nr_waiting;
	int nr_queued;
	int barrier;
	sector_t		next_resync;
	int			fullsync;  /* set to 1 if a full sync is needed,
					    * (fresh device added).
					    * Cleared when a sync completes.
					    */

	wait_queue_head_t	wait_barrier;

	mempool_t *r10bio_pool;
	mempool_t *r10buf_pool;
	struct page		*tmppage;

	/* When taking over an array from a different personality, we store
	 * the new thread here until we fully activate the array.
	 */
	struct mdk_thread_s	*thread;
};

typedef struct r10_private_data_s conf_t;

/*
 * this is our 'private' RAID10 bio.
 *
 * it contains information about what kind of IO operations were started
 * for this RAID10 operation, and about their status:
 */

struct r10bio_s {
	atomic_t		remaining; /* 'have we finished' count,
					    * used from IRQ handlers
					    */
	sector_t		sector;	/* virtual sector number */
	int			sectors;
	unsigned long		state;
	mddev_t			*mddev;
	/*
	 * original bio going to /dev/mdx
	 */
	struct bio		*master_bio;
	/*
	 * if the IO is in READ direction, then this is where we read
	 */
	int			read_slot;

	struct list_head	retry_list;
	/*
	 * if the IO is in WRITE direction, then multiple bios are used,
	 * one for each copy.
	 * When resyncing we also use one for each copy.
	 * When reconstructing, we use 2 bios, one for read, one for write.
	 * We choose the number when they are allocated.
	 */
	struct {
		struct bio		*bio;
		sector_t addr;
		int devnum;
	} devs[0];
};

/* when we get a read error on a read-only array, we redirect to another
 * device without failing the first device, or trying to over-write to
 * correct the read error.  To keep track of bad blocks on a per-bio
 * level, we store IO_BLOCKED in the appropriate 'bios' pointer
 */
#define IO_BLOCKED ((struct bio*)1)

/* bits for r10bio.state */
#define	R10BIO_Uptodate	0
#define	R10BIO_IsSync	1
#define	R10BIO_IsRecover 2
#define	R10BIO_Degraded 3
#endif

В самом коде тоже можно убедится в правильности этого:

/usr/src/linux/drivers/md/raid10.с

Специально заглянул в код ядра: «distance between far copies. This is size / far_copies».

"...unless far_offset. in which case it is 1 stripe." (с)

"...unless far_offset. in which case it is 1 stripe." (с)

ну да. в случае создания raid без указания offset (-p o), в точности и получается «This is size / far_copies».

без указания offset (-p o)

Так. -p - ключ для указания layout'a. Его аргумент - ключевое слово; в этом твоем посте - «о» (офсетный layout), в первоначальной строчке - «f» - far layout. Число - как дополнительный аргумент.

При чем тут это все к переменной в коде? Точнее, как согласуется «без указания offset» и указание layout'a ключом -p?

Так. -p - ключ для указания layout'a. Его аргумент - ключевое слово; в этом твоем посте - «о» (офсетный layout), в первоначальной строчке - «f» - far layout. Число - как дополнительный аргумент.

layout вычисляется по этому ключу.

"-p f2" это не far offset, а количество копий.

"-p o1000" это far offset в чанках

код mdadm-3.1.4

файл unit.c

int parse_layout_10(char *layout)
{
	int copies, rv;
	char *cp;
	/* Parse the layout string for raid10 */
	/* 'f', 'o' or 'n' followed by a number <= raid_disks */
	if ((layout[0] !=  'n' && layout[0] != 'f' && layout[0] != 'o') ||
	    (copies = strtoul(layout+1, &cp, 10)) < 1 ||
	    copies > 200 ||
	    *cp)
		return -1;
	if (layout[0] == 'n')
		rv = 256 + copies;
	else if (layout[0] == 'o')
		rv = 0x10000 + (copies<<8) + 1;
	else
		rv = 1 + (copies<<8);
	return rv;
}

layout вычисляется по этому ключу.

Вроде как про это же говорил

"-p f2" это не far offset,

Аналогично

"-p o1000" это far offset в чанках

Опять-таки отсылка к man'у:

The number is the number of copies of each datablock.

Т.е., оно в любом случае число копий, вне зависимости от типа layout'a - Near, Offset или Far.

// Мне сложно ориентироваться в C'шном коде, я не программер, так что больше ориентируюсь на документацию и комментарии.

Ну и вдогонку - экспериментальный путь: http://rghost.ru/36778587

созданы 2 файла, на которых был сделан RAID, на котором сделана файловая система, на которую записан файлик с последовательностью чисел (вывод seq). Если бы оно было так, как ты рассказываешь - то эта последовательность чисел встретилась бы не на 1% второго файла, а на 50

dd if=/dev/zero of=0.txt bs=1M count=100
dd if=/dev/zero of=1.txt bs=1M count=100
losetup /dev/loop0 0.txt
losetup /dev/loop1 1.txt
mdadm --create /dev/md1 --level 10 -p f2 --raid-devices=2 /dev/loop[01]
sleep 3
mkfs.ext2 /dev/md1
echo 123456789 > info.txt
mount /dev/md1 /mnt/usb0
cp info.txt /mnt/usb0
sync
umount /dev/md1

Поиск (в mc viewer через f7) «1234» нашел в первом файле после просмотра 50%, во втором около 1%.

mdadm-3.1.4

Опять-таки отсылка к man'у: The number is the number of copies of each datablock. Т.е., оно в любом случае число копий, вне зависимости от типа layout'a - Near, Offset или Far.

ХЗ почему так в мане написано, но в коде указано, что offset сделан чтобы поправить скорость записи в far.

Смысле в сдвиге меньше чем на полдиска — чтобы не было падения в скорости записи возникающей на внутренних дорожках. Но, тут появляется доп. (редкие) позизионирования головки диска... ИМХО, это все фигня, и просто нужно правильно разбивать диск. Ибо все равно в конце диска скорость будет медленной, как не прыгай.

Повторил опыт на файлах большего размера - таки да, теперь сдвинулось к середине

Смысле в сдвиге меньше чем на полдиска — чтобы не было падения в скорости записи возникающей на внутренних дорожках. Но, тут появляется доп. (редкие) позизионирования головки диска... ИМХО, это все фигня, и просто нужно правильно разбивать диск. Ибо все равно в конце диска скорость будет медленной, как не прыгай.

Да, странный способ выравнивать скорость, гробля ее в начале массива :)

Эпичный тред получился. Жаль последние несколько лет на лоре уже детально ничего не разбирают.

Эпичный тред получился

Да ладно, 2 страницы всего :)

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

С raid1, созданный через mdamd, есть подобный эффект. Скорость записи на raid1 меньше, чем скорость записи на одиночный диск. Условия теста: диски Seagate «Barracuda ST1000DM003», на диске (или /dev/md0) создаётся том lvm размером в 500Гб, фс XFS. Скорости записи: одиночный диск 130 мб/сек, raid1 70 мб/сек, raid5 (stripe_cache_size=8192) 215 Мб/сек. Что интересно, на raid5 создание qcow2 с преалокейшеном размером 50Гб занимает меньше секунды, на raid1 примерно 7 минут.

софт-рейд1 это по-сути только multipath, с контролем целостности

это как? Софт-рейд1 это полноценный рейд1, данные пишутся и читаются с обоих дисков. Контроль целостности... Нету у него контроля целостности, он не хранит контрольных сумм. Если при verify будут разногласия в показаниях винтов то он тупо синкнет их не задумываеясь где более актуальная информация.