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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
