From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Lyakas Subject: vfs_writev() returns -EIO, although no errors are returned from the underlying device Date: Tue, 13 Mar 2012 22:09:22 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 To: linux-fsdevel@vger.kernel.org Return-path: Received: from mail-iy0-f174.google.com ([209.85.210.174]:49956 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752571Ab2CMUJX (ORCPT ); Tue, 13 Mar 2012 16:09:23 -0400 Received: by iagz16 with SMTP id z16so1217912iag.19 for ; Tue, 13 Mar 2012 13:09:22 -0700 (PDT) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. 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. Thanks, Alex.