From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Lyakas Subject: Re: vfs_writev() returns -EIO, although no errors are returned from the underlying device Date: Wed, 21 Mar 2012 11:17:21 +0200 Message-ID: References: <20120316094444.GC24821@quack.suse.cz> <20120319093410.GB4359@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: Jan Kara Return-path: Received: from mail-iy0-f174.google.com ([209.85.210.174]:41246 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932066Ab2CUJRV convert rfc822-to-8bit (ORCPT ); Wed, 21 Mar 2012 05:17:21 -0400 Received: by iagz16 with SMTP id z16so1319482iag.19 for ; Wed, 21 Mar 2012 02:17:21 -0700 (PDT) In-Reply-To: <20120319093410.GB4359@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Jan, Thanks! This also solves the issue and it's easier, since I can issue that from user mode. Alex. On Mon, Mar 19, 2012 at 11:34 AM, Jan Kara wrote: > =A0Hi, > > On Sun 18-03-12 17:35:45, Alexander Lyakas wrote: >> 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. Thi= s >> 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". > =A0Ah, I had to think for a while why that works. It's because when l= ast > file reference to a device is closed, the whole device cache is evict= ed. So > in particular closing the device won't solve your problem if someone = else > has the device open as well. But what should be more reliable is call= ing > BLKFLSBUF ioctl on the device to flush caches. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Honza > >> On Fri, Mar 16, 2012 at 11:44 AM, Jan Kara wrote: >> > 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 li= st. >> >> >> >> I am working with code that issues vfs_writev() to a fd, which wa= s >> >> opened using filp_open(). The pathname, which has been opened, is= a >> >> DeviceMapper devnode (like /dev/dm-1), which is a linear DeviceMa= pper >> >> 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 mapp= ed to >> >> the same local drive. However, the vfs_writev() still returns -EI= O >> >> several times, before it starts completing successfully. If do a >> >> direct IO at this point to the DM device (like dd if=3D/dev/urand= om >> >> of=3D/dev/dm-1 oflag=3Ddirect), I don't hit any IO errors. I also= added >> >> some prints to dm-linear code, and verified that it does not retu= rn >> >> any IO errors at this point. So it seems that the VFS layer someh= ow >> >> "remembers" that previously there were IO errors from that device= =2E >> >> >> >> I started digging in the kernel code to get some clue on this, bu= t 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. >> > =A0Hmm, the only significant difference I can think of is that you= r buffered >> > writes (vfs_writev()) would go through blkdev_write_begin() -> >> > block_write_begin() which could return EIO if it's not able to rea= d 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 thi= s >> >> issue. I am running kernel 2.6.38-8 (stock ubuntu natty). Any clu= e is >> >> appreciated. >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Honza >> > -- >> > Jan Kara >> > SUSE Labs, CR > -- > Jan Kara > 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