Re: Linux md and iscsi problems

Good morning.


Quoting Neil Brown [off-list ref]:

On Friday February 1, aristizb@ualberta.ca wrote:

quoted

Summarizing, I have two questions about the behavior of Linux md with
slow devices:

1. Is it possible to modify some kind of time-out parameter on the
mdadm tool so the slow device wouldn't be marked as faulty because of
its slow performance.

No.  md doesn't do timeouts at all.  The underlying device does.
So if you are getting time out errors from the iscsi initiator, then
you need to change the timeout value used by the iscsi initiator.  md
has no part to play in this.  It just sends a request and eventually
gets either 'success' or 'fail'.

1. What seems strange to me is that under the same conditions running  
the test only with iscsi, the initiator never fails. I had some  
problems with iscsi on the past and they  were solved changing the  
time-out parameters on  the initiator side, but now that I added the  
md layer I am getting errors with the slow device.

quoted

2. Is it possible to control the "buffer" size of the RAID?, in other
words, can I control the amount of data I can write to the local disc
before I receive an acknowledgment from the slow device when I am
using the write-behind option.

No.  md/raid1 simply calls 'kmalloc' to get space to buffer each write
as the write arrives.  If the allocation succeeds, it is used to
perform the write lazily.  If the allocation fails, the write is
performs synchronously.

What did you hope to achieve by such tuning?  It can probably be
added if it is generally useful.

NeilBrown

2. The idea here is to implement remote replication, by having a  
RAID-1 I can create a mirror of my local disk and use it for backup or  
for any other purposes on a centralized location.

Changing the buffer will allow me to improve performance on the  
writing, so a user will always experience local writing speed, while I  
am still sending data across the network to the mirror device.


Thanks a lot for your time.


Juan Aristizabal.