On Wed, Aug 1, 2018 at 1:51 AM Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote:
On 1 August 2018 at 07:39, Alireza Haghdoost <haghdoost@xxxxxxxxx> wrote:
> Your jobs step on the foot of each other. You can’t write with multiple
> process on the same LBA of a LUN on the same time. That is why you get error
> 5 because one thread is writting an LBA and another thread modify if at the
> same time. In this case either one can get unknown result.
I agree with part of this statement (unknown result in the LBA) but
I'm doubtful it would cause an error message of "I/O error". Disks
definitely do accept simultaneous write I/Os against the same LBA but
the problem becomes that in most cases the end result as to which data
the LBA will contain is undefined. It's not illegal (in the sense that
nothing prevents and nothing will error) it's just bad from a data
integrity perspective (and since this wasn't a verify job...).
I agree that it is not is not a felony two write on the same lba with multiple threads.
Not sure what kind of storage device is used in this experience but some storage devices *do* Lock a sector/chunk while it is being written. It means the second in-inflight write hitting the same LBA/chunk will wait for the first one.
Do the math to find out in this job file how many of these big in-flight write the system can handle before it times-out the last one in the queue.
Now, does it cause err 5? I don’t know for sure. However. This is yet another reason that might cause it.
