xfs
[Top] [All Lists]

Re: mount options...

To: linux-xfs@xxxxxxxxxxx
Subject: Re: mount options...
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Tue, 11 Mar 2003 23:21:30 -0900
In-reply-to: <000001c2e834$abd32480$1403a8c0@sc.tlinx.org>
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <1047421073.17614.18.camel@porter> <000001c2e834$abd32480$1403a8c0@sc.tlinx.org>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Tue, Mar 11, 2003 at 05:14:03PM -0800, l.a walsh wrote:
> 
> 
> > -----Original Message-----
> > From: Eric Sandeen [mailto:sandeen@xxxxxxx]
> > Sent: Tue, Mar 11, 2003 2:18p
> > To: l.a walsh
> > Cc: linux-xfs@xxxxxxxxxxx
> > Subject: Re: mount options...
> >
> >
> > Mount almost always gives you a generic message on failure; I always
> > make a habit of looking at the syslogs to see what went wrong.
> >
> > also, FWIW, all xfs mount options are documented in
> > Documentation/filesystems/xfs.txt
> ---
>       That's nice.
> 
>       Are you saying it wouldn't be helpful to have a more clear
> error message or that it wouldn't be useful to have all the options
> documented in the manpages?

not at all.

the problem with mount is its just a wrapper around mount() (the
system call), /bin/mount itself doesn't have any idea why the mount
failed past mount()'s return value and the contents of errno, from the
mount(2) man page:

RETURN VALUE
       On success, zero is returned.  On error, -1  is  returned,
       and errno is set appropriately.

ERRORS
       The  error  values given below result from filesystem type
       independent errors. Each filesystem type may have its  own
       special errors and its own special behavior.  See the ker-
       nel source code for details.


       EPERM  The user is not the super-user.

       ENODEV Filesystemtype not configured in the kernel.

       ENOTBLK
              Specialfile is not a block device (if a device  was
              required).

       EBUSY  Specialfile  is  already  mounted. Or, it cannot be
              remounted read-only, because it still  holds  files
              open  for writing.  Or, it cannot be mounted on dir
              because dir is still busy (it is the working direc-
              tory  of  some  task,  the  mount  point of another
              device, has open files, etc.).

       EINVAL Specialfile  had  an  invalid  superblock.   Or,  a
              remount  was  attempted,  while specialfile was not
              already  mounted  on  dir.   Or,  an   umount   was
              attempted, while dir was not a mount point.

       EFAULT One  of  the  pointer  arguments points outside the
              user address space.

       ENOMEM The kernel could not allocate a free page  to  copy
              filenames or data into.

       ENAMETOOLONG
              A pathname was longer than MAXPATHLEN.

       ENOENT A  pathname  was  empty or had a nonexistent compo-
              nent.

       ENOTDIR
              The second argument, or a prefix of the first argu-
              ment, is not a directory.

       EACCES A component of a path was not searchable.
              Or,  mounting  a read-only filesystem was attempted
              without giving the MS_RDONLY flag.
              Or, the block device Specialfile is  located  on  a
              filesystem mounted with the MS_NODEV option.

       ENXIO  The major number of the block device specialfile is
              out of range.

       EMFILE (In case no block device  is  required:)  Table  of
              dummy devices is full.


In general there isn't going to be an errno for all the various ways
specific filesystems can fail, so mount is probably just going to end
up getting ENODEV most of the time, thus it can't tell you much about
what went wrong.  you could fix this by adding new errno values to
accomidate all the various filesystem mount failure conditions, then
make sure /bin/mount just uses perror() to inform the user of
failure.  this however requires both kernel and glibc modification,
and thus will likly be difficult politically (and there are perhaps
portability issues, though thats not so important with something like
mount() which is never portable anyway).

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpiveGraV6Q7.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>