public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Bellon <mbellon@mvista.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH]  disk quotas fail when /etc/mtab is symlinked to /proc/mounts
Date: Thu, 28 Jul 2005 17:46:53 -0700	[thread overview]
Message-ID: <42E97C7D.9040804@mvista.com> (raw)
In-Reply-To: <42E9787D.2020700@mvista.com>

Mark Bellon wrote:

> Andrew Morton wrote:
>
>> Mark Bellon <mbellon@mvista.com> wrote:
>>  
>>
>>> If /etc/mtab is a regular file all of the mount options (of a file 
>>> system) are written to /etc/mtab by the mount command. The quota 
>>> tools look there for the quota strings for their operation. If, 
>>> however, /etc/mtab is a symlink to /proc/mounts (a "good thing" in 
>>> some environments)  the tools don't write anything - they assume the 
>>> kernel will take care of things.
>>>
>>> While the quota options are sent down to the kernel via the mount 
>>> system call and the file system codes handle them properly 
>>> unfortunately there is no code to echo the quota strings into 
>>> /proc/mounts and the quota tools fail in the symlink case.
>>>   
>>
>>
>> hm.  Perhaps others with operational experience in that area can 
>> comment.
>>  
>>
> OK.
>
>>  
>>
>>> The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the 
>>> necessary hooks. The show_options function of each file system in 
>>> these patches currently deal with only those things that seemed 
>>> related to quotas; especially in the EXT3 case more can be done 
>>> (later?).
>>>   
>>
>>
>> It seems sad to do it in each filesystem.  Is there no way in which 
>> we can
>> do this for all filesystems, in a single place in the VFS?
>>  
>>
> Each file system must be able to echo it's own FS specific options, 
> hence the show_options hook (XFS is a good example). EXT3 has it's own 
> form of journalled quota file options, hence the need for the specific 
> hook.
>
> The "older style" (e.g. "usrquota", "grpquota", "quota") could be done 
> generically but a FS might want any number of quota options. The few 
> lines of code in each file system didn't seem so bad especially if the 
> show_function start echoing more.

Followup comment/through...

If we want /proc/mounts to really replace /etc/mtab in the general case, 
always using it as a symlink, the file system codes will all need the 
show_options hook - they will need to echo all of their private options 
duplicating, as closely as possible, what would have been written to the 
/etc/mtab regular file.

mark

mark


  reply	other threads:[~2005-07-29  0:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-29  0:03 [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts Mark Bellon
2005-07-29  0:13 ` Nathan Scott
2005-07-29  0:15   ` Mark Bellon
2005-07-29  0:19 ` Mark Bellon
2005-07-29  0:23 ` Andrew Morton
2005-07-29  0:29   ` Mark Bellon
2005-07-29  0:46     ` Mark Bellon [this message]
2005-07-29 13:46 ` Jan Kara
2005-07-29 15:47   ` Mark Bellon
2005-07-29 17:21 ` [PATCH] (REPOST/REVISION) " Mark Bellon
2005-07-29 22:03   ` [PATCH] (TAKE 3) " Mark Bellon
2005-08-02 21:27     ` [PATCH] IDE disks show invalid geometries in /proc/ide/hd*/geometry Mark Bellon
2005-08-03  7:19       ` Andre Hedrick
2005-08-03 16:54         ` Mark Bellon
2005-08-03 17:19         ` Bartlomiej Zolnierkiewicz
2005-08-03 17:37           ` Mark Bellon
2005-08-03 18:05             ` Bartlomiej Zolnierkiewicz
2005-08-03 18:32               ` Mark Bellon
2005-08-03 18:51                 ` Bartlomiej Zolnierkiewicz
2005-08-04  6:03                   ` Jan Engelhardt
2005-08-04 16:44                     ` Mark Bellon
2005-08-04 23:45                     ` Eric D. Mudama
2005-08-08 16:02     ` [PATCH] (TAKE 3) disk quotas fail when /etc/mtab is symlinked to /proc/mounts Jan Kara
2005-08-08 17:55   ` [PATCH] PPC64: large INITRD causes kernel not to boot Mark Bellon

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=42E97C7D.9040804@mvista.com \
    --to=mbellon@mvista.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox