From: "Theodore Y. Ts'o" <firstname.lastname@example.org> To: Matthew Wilcox <email@example.com> Cc: Jeff Layton <firstname.lastname@example.org>, "Darrick J. Wong" <email@example.com>, firstname.lastname@example.org, email@example.com, xfs <firstname.lastname@example.org> Subject: Re: [PATCH] fs: clear writeback errors in inode_init_always Date: Sun, 20 May 2018 12:29:54 -0400 [thread overview] Message-ID: <20180520162954.GA5250@thunk.org> (raw) In-Reply-To: <20180520125843.GA25612@bombadil.infradead.org> On Sun, May 20, 2018 at 05:58:43AM -0700, Matthew Wilcox wrote: > On Sun, May 20, 2018 at 07:45:31AM -0400, Jeff Layton wrote: > > [PATCH] loop: clear wb_err in bd_inode when detaching backing file > > Is this the right thing to do? Putting the test-suite aside for the > moment, if I have a loop device on a file and I hit a real error on the > storage backing that file, I don't see why detaching the loop device > from the file should clear the error. > > I'm really tempted to say that we should fix the test-suite to consume > the error; once it's been read by at least one reader, it won't go back > to zero, but neither will it show up for new readers. You can't detach the backing store if there are any open file descriptors (or if there is another loop device keeping the loop device open, or if there is a file system mounted on it, etc.). If you can detach the backing store, once you detach the backing store, the loop device is *gone*. The user of /dev/loop0 will very likely be a completely different backing store, so returning an error simply doesn't make any sense. There is a very good chance it will be a completely different backing store, with potentially a different user, so returning a carried over error is just going confuse, annoy, and anger the user..... - Ted
next prev parent reply other threads:[~2018-05-20 16:30 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-18 22:50 commit b4678df184b causing xfstests regressions Theodore Y. Ts'o 2018-05-19 2:17 ` Matthew Wilcox 2018-05-19 13:09 ` Jeff Layton 2018-05-19 15:25 ` Darrick J. Wong 2018-05-19 15:27 ` [PATCH] fs: clear writeback errors in inode_init_always Darrick J. Wong 2018-05-19 15:36 ` Matthew Wilcox 2018-05-21 17:54 ` Darrick J. Wong 2018-05-22 10:30 ` Jeff Layton 2018-05-22 22:09 ` Dave Chinner 2018-05-23 10:56 ` Jeff Layton 2018-05-24 3:59 ` Dave Chinner 2018-05-19 23:19 ` Theodore Y. Ts'o 2018-05-20 11:45 ` Jeff Layton 2018-05-20 12:58 ` Matthew Wilcox 2018-05-20 13:18 ` Jeff Layton 2018-05-20 16:29 ` Theodore Y. Ts'o [this message] 2018-05-20 19:20 ` Matthew Wilcox 2018-05-20 19:41 ` Theodore Y. Ts'o 2018-05-21 11:20 ` Jeff Layton 2018-05-21 14:43 ` Theodore Y. Ts'o 2018-05-20 17:57 ` Theodore Y. Ts'o 2018-05-22 4:06 ` [PATCH v2] " Darrick J. Wong 2018-05-22 10:14 ` Jeff Layton 2018-05-22 12:14 ` Brian Foster 2018-05-22 14:37 ` Darrick J. Wong 2018-05-22 16:43 ` [PATCH v3] " Darrick J. Wong 2018-05-22 18:40 ` Brian Foster 2018-05-22 18:47 ` Darrick J. Wong 2018-05-22 22:05 ` Dave Chinner 2018-05-23 3:00 ` Darrick J. Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180520162954.GA5250@thunk.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] fs: clear writeback errors in inode_init_always' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).