Re: vfs_writev() returns -EIO, although no errors are returned from the underlying device

Jan,
thank you for your hint. I tried to look at this path and some other
code, and saw some places, in which PageError() macro is called, and
based on that -EIO may be returned.
To solve the issue I close the "struct file" handle and re-open. This
seems to get rid of stale cache entries (then, of course, I may be
wrong, but this solves the issue). It would be good if VFS provided
such API without closing the "struct file".

Thanks,
 Alex.

On Fri, Mar 16, 2012 at 11:44 AM, Jan Kara [off-list ref] wrote:

On Tue 13-03-12 22:09:22, Alexander Lyakas wrote:

quoted

Greetings all,
I apologize if my question should not have been posted to this list.

I am working with code that issues vfs_writev() to a fd, which was
opened using filp_open(). The pathname, which has been opened, is a
DeviceMapper devnode (like /dev/dm-1), which is a linear DeviceMapper
mapped to a local drive.

At some point, I switch the DeviceMapper to "error" table (using
"dmsetup reload" and then "dmsetup resume"). As expected,
vfs_writev() starts returning -EIO.

Then later, I switch the DeviceMapper back to "linear" table mapped to
the same local drive. However, the vfs_writev() still returns -EIO
several times, before it starts completing successfully. If do a
direct IO at this point to the DM device (like dd if=/dev/urandom
of=/dev/dm-1 oflag=direct), I don't hit any IO errors. I also added
some prints to dm-linear code, and verified that it does not return
any IO errors at this point. So it seems that the VFS layer somehow
"remembers" that previously there were IO errors from that device.

I started digging in the kernel code to get some clue on this, but at
this point I only saw functions like make_bad_inode() and
is_bad_inode(), which may be relevant somehow, but I was not able to
trace where the -EIO is returned from.

 Hmm, the only significant difference I can think of is that your buffered
writes (vfs_writev()) would go through blkdev_write_begin() ->
block_write_begin() which could return EIO if it's not able to read in rest
of the page (if you are not writing full page-sized blocks). So I'd have a
look at block_write_begin() and see what it returns...

quoted

Can someone pls point me which code I should look at to debug this
issue. I am running kernel 2.6.38-8 (stock ubuntu natty). Any clue is
appreciated.

                                                               Honza
--
Jan Kara [off-list ref]
SUSE Labs, CR

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html