Red Hat Bugzilla – Bug 81042
ramfs broken on kernel 2.4.18-14
Last modified: 2005-10-31 17:00:50 EST
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): 2.4.18-14 How reproducible: Always 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 second. Expected results: Free space should increase after file deletion, free space should not change when not creating files on ramfs. Additional info:
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)
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.
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.
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.
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.
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 AND 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. kar@247realmedia.com aim: thequeen232323 rm
Later Red Hat dropped those changes as do the errata kernels.