lkml.org 
[lkml]   [2018]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10]
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.

\
 
 \ /
  Last update: 2018-07-31 02:00    [W:0.127 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site