From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:35374 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731995AbeGaBgY (ORCPT ); Mon, 30 Jul 2018 21:36:24 -0400 Date: Mon, 30 Jul 2018 16:58:49 -0700 From: Matthew Wilcox To: "Theodore Y. Ts'o" , Linus Torvalds , Pavel Machek , David Howells , Al Viro , linux-fsdevel , Linux Kernel Mailing List Subject: Re: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10] Message-ID: <20180730235849.GA19692@bombadil.infradead.org> References: <153271267980.9458.7640156373438016898.stgit@warthog.procyon.org.uk> <153271292330.9458.14583488053811372222.stgit@warthog.procyon.org.uk> <25489.1532953411@warthog.procyon.org.uk> <20180730143104.GB24051@amd> <20180730180842.GA5544@bombadil.infradead.org> <20180730183847.GB5544@bombadil.infradead.org> <20180730194938.GA12962@bombadil.infradead.org> <20180730210209.GY21725@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180730210209.GY21725@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Jul 30, 2018 at 05:02:09PM -0400, Theodore Y. Ts'o wrote: > On Mon, Jul 30, 2018 at 12:49:38PM -0700, Matthew Wilcox wrote: > > > That said, people have wanted these kinds of extended error > > > descriptors forever, and the reason we haven't added them is that it > > > generally is more pain than it is necessarily worth. I'm not actually > > > at all convinced that has magically changed with the mount > > > configuration thing. > > > > I'm not convinced we want to do this either, but if there's anywhere we > > do want to do it then mount seems like one of the few places it might be > > worth doing. The reasons that a mount failed are many, and it doesn't > > seem like a good idea to introduce a new errno every time a network > > filesystem finds a new failure mode. > > We've lived without VMS-style error reporting for a long time, and it > *that* much of a real problem. Even with network file systems, I > don't think it's been that hard of a problem. Way to poison the well by calling it VMS-style error reporting! As I understand it though, VMS reported errors in English with an error code that could be looked up in The Wall of documentation. I'd see David's proposal as closer to plan9-style error reporting. But I think it has been a real problem. I mean, look at ext4. if (test_opt2(sb, EXPLICIT_DELALLOC)) { ext4_msg(sb, KERN_ERR, "can't mount with " "both data=journal and delalloc"); goto failed_mount; ... ext4_msg(sb, KERN_ERR, "can't mount with " "both data=journal and dioread_nolock"); ext4_msg(sb, KERN_ERR, "can't mount with " "both data=journal and dax"); "The Hurd can't support 64-bit file systems"); "ea_inode feature is not supported for Hurd"); ext4_msg(sb, KERN_ERR, "couldn't mount as ext2 due " "to feature incompatibilities"); ext4_msg(sb, KERN_ERR, "couldn't mount as ext3 due " "to feature incompatibilities"); "Unsupported filesystem blocksize %d (%d log_block_size)", "Invalid log block size: %u", "Number of reserved GDT blocks insanely large: %d", ext4_msg(sb, KERN_ERR, "Unsupported encryption level %d", The list goes on, but there're 11 reasons we'd ideally like to report to the user from mount(8) without forcing the user to grovel through dmesg.