On Mon, 2014-02-24 at 21:26 +0100, Henrik Goldman wrote: > > > > So AFAICT the -EINVAL error on READs is most likely coming some where > > from within the underlying file-system, and not the underlying storage > > (eg: we'd typically see a HBA failure if this was the case). > > > > Anything special about the file-system here..? > > Ok so I think I found the reason. > > The truth is that we used to have a set of both SSD + HDD's in the > machine until we pulled the HDD's out last week. Targetcli was still > recording the HDD's as active even though the real filesystem does not > exist anymore. Essentially old references to non-existent hardware. > > After removing this reference from targetcli the errors magically also > disappeared. > Not sure what you mean here.. Does this mean the filesystem that the FILEIO file is referencing was offline when the -EINVAL error was generated..? > However the reason why I started noticing this to begin with was that > I saw disk write errors within one vmware virtual machine running on > the actual datastore. > The problem that I had was that it kept saying "Write same failed. > Manually zeroing". > Strange, FILEIO does support WRITE_SAME (VAAI BlockZero) emulation and there is no reason why it should be failing.. > So assuming that this error -22 was a false alarm due to > misconfiguration then I am still trying to find out why the other > error actually happened. > > Could this be some feature not properly implemented in the target driver? > > - Nope. WRITE_SAME emulation for IBLOCK and FILEIO backends has been around for a while now. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
