>>> Suresh Rajagopalan <[email protected]> schrieb am 06.11.2012 um 15:49 in Nachricht <[email protected]>: > I'd like to find out what SAM codes in Tgtd notify open-iscsi & block > layer to > retry a failed > I/O. > > To clarify, in the current tgtd backing store code (bs_rdwr.c), a > failed read or writes > sets the following: > static void set_medium_error(int *result, uint8_t *key, uint16_t *asc > { > *result = SAM_STAT_CHECK_CONDITION; > *key = MEDIUM_ERROR; > *asc = ASC_READ_ERROR; > } > > > While this retries failed reads, failed writes are not retried. Is
Hi! I think the logic is that current disk hardware transparently remaps bad sectors on write, if a write still fails then, it's quite likely that retrying won't succeed (maybe because the disk ran out of spare sectors). It's a matter of taste whether a failed write is less serious than a failed read. One could argue that for a failed write you still have the data in RAM, while for reads you definitely don't (for some reasonable application). Modern disks prefer to return a read error (if ECC-reconstruction failed) over retrying for an extended period of time (which seems to make sense performance-wise). Most likely for read errors (just as for write errors) it's time to replace the disk (or fix some other connectivity problem). For iSCSI, the "transparent" transport should retry transport issues, but not any command issues. (IMHO) Regards, Ulrich > there a > particular code that will notify the open-iscsi / client block layer > to retry the > I/O operation? > > Thanks > Suresh -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
