On Sat, Nov 05 2016, Marc MERLIN wrote:
What's interesting is that it started exactly at 50%, which is also
likely where my reads were failing.
myth:/sys/block/md5/md# echo repair > sync_action
md5 : active raid5 sdg1[0] sdd1[5] sde1[3] sdf1[2] sdh1[6]
15627542528 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
[==========>..........] resync = 50.0% (1953925916/3906885632) finish=1899.1min speed=17138K/sec
bitmap: 0/30 pages [0KB], 65536KB chunk
Yep, that is weird.
You can cause that to happen by e.g
echo 7813771264 > /sys/block/md5/md/sync_min
but you are unlikely to have done that deliberately.
That said, as this resync is processing, I'd think/hope it would move
the error forward, but it does not seem to:
myth:/sys/block/md5/md# dd if=/dev/md5 of=/dev/null bs=1GiB skip=8190
dd: reading `/dev/md5': Invalid argument
2+0 records in
2+0 records out
2147483648 bytes (2.1 GB) copied, 27.8491 s, 77.1 MB/s
EINVAL from a read() system call is surprising in this context.....
do_generic_file_read can return it:
if (unlikely(*ppos >= inode->i_sb->s_maxbytes))
return -EINVAL;
s_maxbytes will be MAX_LFS_FILESIZE which, on a 32bit system, is
#define MAX_LFS_FILESIZE (((loff_t)PAGE_SIZE << (BITS_PER_LONG-1))-1)
That is 2^(12+31) or 2^43 or 8TB.
Is this a 32bit system you are using? Such systems can only support
buffered IO up to 8TB. If you use iflags=direct to avoid buffering, you
should get access to the whole device.
If this is a 64bit system, then the problem must be elsewhere.
NeilBrown