Re: Bad sequential performance of RAID5 with a lot of disk seeks

[Robin Hill <robin@robinhill.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Tue Oct 07, 2014 at 12:36:19PM +0200, P. Gautschi wrote:

> > What does the SMART info show for the drives - are there any reallocated
> > blocks? A large number of those scattered over the disk would certainly
> > cause seeking for both reads and writes.
> 
> I will check the SMART this evening but I don't think that this is causing
> the seek. The sound is very constant and for the whole time of syncing  
> the array.
> I will also run a dd on the disk to compare.
> 
> > It's also worth checking whether there's anything else that would be
> > accessing the disks in the background (monitoring/indexing/etc).
> 
> Unlikely because I have not yet created a filesystem after setting up  
> the RAID4.
> 
> > I can't think of anything else that would be causing reads to seek - SMR
> > disks or write-intent bitmaps would only affect writes.
> 
> Exactly
> 
> Is there any way or tool to monitor all disk read/write commands - not only
> the count or amount but every access with LBA and length?
> 
You can do:
    echo 1 > /proc/sys/vm/block_dump

That will write out all disk IO to the kernel log (process ID,
read/write and block offset only though). It can be very verbose,
especially if you have a lot of other things running on the system, but
you should be able to grep out the necessary lines. Echoing 0 will
switch it back off again.

Otherwise there's probably ways to get more specific results via the
kernel auditing system, but that's nothing I've played with.

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]