Re: get err 5

[Alireza Haghdoost <haghdoost@gmail.com>]

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

On Wed, Aug 1, 2018 at 1:51 AM Sitsofe Wheeler <sitsofe@gmail.com> wrote:

> On 1 August 2018 at 07:39, Alireza Haghdoost <haghdoost@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 2243 bytes --]