From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: vfs_writev() returns -EIO, although no errors are returned from the underlying device Date: Fri, 16 Mar 2012 10:44:44 +0100 Message-ID: <20120316094444.GC24821@quack.suse.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Alexander Lyakas Return-path: Received: from cantor2.suse.de ([195.135.220.15]:60816 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754589Ab2CPJos (ORCPT ); Fri, 16 Mar 2012 05:44:48 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue 13-03-12 22:09:22, Alexander Lyakas wrote: > 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... > 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 SUSE Labs, CR