Bug 81042 - ramfs broken on kernel 2.4.18-14
Summary: ramfs broken on kernel 2.4.18-14
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-03 18:31 UTC by Tim Russell
Modified: 2005-10-31 22:00 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-06-05 13:46:56 UTC

Attachments (Terms of Use)

Description Tim Russell 2003-01-03 18:31:51 UTC
Description of problem:

I run a mini-ITX system with RH 8.0 which uses a custom initrd to take a 
preconfigured install of RH 8.0, untar it to a ramfs filesystem, then 
pivot_root to it.  This allows the system to run completely out of RAM and 
spin down the hard drive about 95% of the time.

My previous system, based on RH 7.2, did this flawlessly.  However, with the 
new machine, two things occur with ramfs: firstly, when a file is created and 
deleted, the disk space used by the file is not reclaimed.  Secondly, when the 
disk cache fills up, as in transferring a large (>500M) file to the system 
(hard drive, not ramfs), free space is taken from the ramfs filesystem until 
no more exists and cannot be returned no matter what I do.  While the transfer 
is in progress, "find / -xdev -mtime -1 -print" shows no files being created 
or updated on the ramfs at all.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

Free space reclamation problem:

1. mount -t ramfs -o maxsize=327680 none /mnt/ram
2. Check free space using "df /mnt/ram"
3. dd if=/dev/zero of=/mnt/ram/testfile bs=1k count=30000
4. Check free space using "df /mnt/ram"
5. rm /mnt/ram/testfile
6. Check free space using "df /mnt/ram"

Disk cache interaction problem:

Not sure if a normal ramfs mounted on a hard-disk-based system will exhibit 
this behavior, but I bet it will.

1. mount -t ramfs -o maxsize=327680 none /mnt/ram
2. Check free space with "df /mnt/ram"
3. Transfer a file > total ram size to the system
4. Check free space with "df /mnt/ram".  It will be markedly lower although no 
files changed on the ramfs.  Repeat until ramfs has zero free space.

Actual results:

Free space didn't change for the first, ramfs had zero free space for the 

Expected results:

Free space should increase after file deletion, free space should not change 
when not creating files on ramfs.

Additional info:

Comment 1 Michael Lee Yohe 2003-01-03 20:44:59 UTC
I'm not sure if there were any relevant changes but have you looked into the
latest errata kernel for Red Hat Linux 8.0? (2.4.18-19.8.0)

Comment 2 Tim Russell 2003-01-06 18:13:28 UTC
Haven't actually tried out the newer kernel, but I downloaded the source from 
both 2.4.18-14 and 2.4.18-19 and fs/ramfs/inode.c are exactly the same.

FYI, I "updated" this system in-place to the 2.4.7-10 kernel from RH 7.2 and 
everything works perfectly, so this isn't wierdness with anything else in 8.0 
besides the kernel.  So RedHat 8.0 with a 7.2 kernel works perfect.  Something 
got broken in ramfs after 7.2.

Comment 3 Tim Russell 2003-01-13 05:31:39 UTC
Well, apparently I'm not going to get a response on this, even though it was 
Red Hat who accepted Alan Cox's ramfs patch that caused this mess.

I switched the system over to tmpfs and it's working fine with 2.4.18-19.

Comment 4 Michael Lee Yohe 2003-01-13 13:36:44 UTC
Arjan is an extremely busy person - I'm sure if you would have simply "pinged"
him via this bug, or simply sent him a courteous request email - he would have
eventually replied.  Arjan has been helpful to me, personally, off to the side.

Comment 5 David Dombek 2003-04-21 12:36:00 UTC
Tested a SuSe 7.3, 2.4.16 Kernel and RAMFS worked without incident.

So when is RedHat going to finally do anything about this bug?

The problem has been verified on 7.3 and 8.0 so far.  I don't have a 9.0 
install to test with.

Comment 6 Kris Reilly 2003-04-22 17:30:40 UTC
this condition also exists for kernel versions:
Linux 107.back 2.4.18-18.7.xbigmem #1 SMP Wed Nov 13 18:24:15 EST 2002 i686 unknown
Linux dannon 2.4.18-26.7.xbigmem #1 SMP Mon Feb 24 09:18:30 EST 2003 i686 unknown

mkdir /tmp/ramfs
mount -t ramfs -o none /dev/ram1 /tmp/ramfs -o maxsize=128000 
cp /home0/aalexand/tmp/rpt_104_16_track.dat /tmp/ramfs/
df -h /tmp/ramfs
/dev/ram1             125M   33M   92M  26% /tmp/ramfs 
rm /tmp/ramfs/rpt_104_16_track.dat
df -h /tmp/ramfs
/dev/ram1             125M   33M   92M  26% /tmp/ramfs
ls /tmp/ramfs
directory empty

We are using tmpfs as a substitute for ramfs, but are unpleased with its
performance under load.  We are also looking into ramdisk, but are having
performance issues with ramdisks as large as we are hoping to use (>=512MB).

Please let me know if there is a patch being developed to fix ramfs or if there
is a workaround in place.

aim: thequeen232323  


Comment 7 Alan Cox 2003-06-05 13:46:56 UTC
Later Red Hat dropped those changes as do the errata kernels.

Note You need to log in before you can comment on or make changes to this bug.