All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <willy@w.ods.org>
To: Senior Goat <senior_goat@hotmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: ramfs reports 0 free
Date: Sat, 29 Apr 2006 22:50:45 +0200	[thread overview]
Message-ID: <20060429205045.GJ13027@w.ods.org> (raw)
In-Reply-To: <BAY101-F3554D73ACD8CD3AFCF5D8081B30@phx.gbl>

On Sat, Apr 29, 2006 at 07:52:16PM +0000, Senior Goat wrote:
> [1.] One line summary of the problem:
> 
>    ramfs erroneously reports 0 bytes free, which confuses some programs.
> 
> [2.] Full description of the problem/report:
> 
>    The system call on a mounted ramfs, as indicated by df, reports 0 
>    bytes total, used, and free.  If ramfs is expected to perform like a 
> filesystem, it should not do this.

(...)

> [X.] Other notes, patches, fixes, workarounds:
> 
>   I read that Linus himself wrote this module.  For some reason he 
>   decided to report 0, but I can't figure why.  Perhaps the overhead for 
> finding information was too great.
> 
>  Couldn't you add up the amount of filesystem cache with the free memory 
> and get a crude, but quick estimate of the amount of free space available 
> for any given ramfs.
> 
>  I'm not sure how to handle the total space, since you probably don't 
>  want that fluctuating too much, except that you might just report the 
> total amount of ram(which won't fluctuate), and then report the used ram. 
> This is all information that /free/ reports from system calls with little 
> delay.
>
>  The only other place I can think that ramfs might get memory is when the 
> kernel swaps out other processes, but you can't count on that.
> 
>  To sum it up, the best way to get a semi-valid report would be:
> total:  total ram
> used: used ram (which takes into account memory used in the ramfs, 
> coincidentally)
> free:  total - used  (which ignores disk cache, since that should be 
> freed when needed)

To achieve this, you have to set an arbitrary limit on the maximal FS size.
I have updated a patch originally from David Gibson to enforce limits on
RAMFS. His original patch for 2.4.19-rc1-ac2 as well as my update for
2.4.32 is available here, in case you're interested in porting it to 2.6 :

   http://w.ods.org/linux/kernel/2.4/lkup/ramfs-limit.html
   
>   The other option would be to make all the little programs (like 
>   Debian's package manager) check if the filesystem it wants to write to is 
> a ramfs before reporting an error, but this is a blatant hack.

This is very hard to maintain, that's why I include the patch above in
my kernels ;-)

Cheers,
Willy


      reply	other threads:[~2006-04-29 20:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-29 19:52 PROBLEM: ramfs reports 0 free Senior Goat
2006-04-29 20:50 ` Willy Tarreau [this message]

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=20060429205045.GJ13027@w.ods.org \
    --to=willy@w.ods.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=senior_goat@hotmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.