Can't free the ramdisk (initrd, pivot_root)

Can't free the ramdisk (initrd, pivot_root)

[H. Peter Anvin]

Hello friends,

I am trying the following setup, and it works beautifully, *except*
that I don't seem to be able to free the ramdisk memory at the end.
This is using the 2.4.3 stock kernel:

I load an initrd in "non-initrd" mode:

label single
        kernel vmlinuz
        append initrd=initrd.gz root=/dev/ram0 init=/linuxrc single

The initrd sets up a ramfs which is intended to become the root
filesystem, and then calls pivot_root:

[....]
umount /proc

# At this point, all that is mounted is /ram and /ram/usr

# Switch roots and run init
cd /ram
pivot_root /ram /ram/initrd
exec /sbin/init "$@"


(And yes, the /ram/initrd mount point directory does exist.)

This successfully runs init, and I can umount /initrd in the new
setup, but I cannot then destroy the ramdisk contents by calling
ioctl([/dev/ram0], BLKFLSBUF, 0) -- it always returns EBUSY.  What is
holding this ramdisk busy, especially since I could successfully
umount the filesystem?  Seems like a bug to me.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Can't free the ramdisk (initrd, pivot_root)

[Scott Murray]

On 14 Apr 2001, H. Peter Anvin wrote:

> Hello friends,
>
> I am trying the following setup, and it works beautifully, *except*
> that I don't seem to be able to free the ramdisk memory at the end.

Heh, sounds familiar, I was in exactly the same situation a month ago.
I meant to post something about it, but kept forgetting.

> This successfully runs init, and I can umount /initrd in the new
> setup, but I cannot then destroy the ramdisk contents by calling
> ioctl([/dev/ram0], BLKFLSBUF, 0) -- it always returns EBUSY.  What is
> holding this ramdisk busy, especially since I could successfully
> umount the filesystem?  Seems like a bug to me.

Indeed it is.  This fix for drivers/block/rd.c (excerpted from 2.4.3-ac6):

@@ -690,6 +690,7 @@
 done:
        if (infile.f_op->release)
                infile.f_op->release(inode, &infile);
+       blkdev_put(out_inode->i_bdev, BDEV_FILE);
        set_fs(fs);
        return;
 free_inodes: /* free inodes on error */

has been in Alan's tree since some time in November (it first appeared
in the 2.4.0test11ac1 Change Log).

Another ramdisk gotcha that also still exists is that cramfs still seems to
be hosing the ramdisk superblock if it's compiled into the kernel.  I had to
not only switch to romfs for my initrd, but also compile cramfs support out
of the kernel.  There was a big discussion about this exact problem back in
January, but none of the suggested fixes seem to have been incorporated.

Scott


-- 
=============================================================================
Scott Murray                                        email: scott@spiteful.org
http://www.spiteful.org (coming soon)                 ICQ: 10602428
-----------------------------------------------------------------------------
     "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"

Re: Can't free the ramdisk (initrd, pivot_root)

[Amit D Chaudhary]

On the same topic, I have not found any change in free memory reported before 
and after the ioctl call. Though umount /initrd does free around 2 MB.


Amit

Re: Can't free the ramdisk (initrd, pivot_root)

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0104151251500.4284-100000@godzilla.spiteful.org>
By author:    Scott Murray <scott@spiteful.org>
In newsgroup: linux.dev.kernel
> 
> Indeed it is.  This fix for drivers/block/rd.c (excerpted from 2.4.3-ac6):
> 

This did the trick.  I bounced the patch to Linus, too.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Can't free the ramdisk (initrd, pivot_root)

[H. Peter Anvin]

Followup to:  <3ADA0B50.8030301@muppetlabs.com>
By author:    Amit D Chaudhary <amit@muppetlabs.com>
In newsgroup: linux.dev.kernel
> 
> On the same topic, I have not found any change in free memory
> reported before and after the ioctl call. Though umount /initrd does
> free around 2 MB.
> 

With Scott's patch applied, I get substantially better performance on
low-memory machines, so I'm guessing it's doing its job.  Also, just
umount /initrd for me made it still possible to mount it, so it
clearly did not go away.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Can't free the ramdisk (initrd, pivot_root)

[Scott Murray]

On 15 Apr 2001, H. Peter Anvin wrote:

> Followup to:  <3ADA0B50.8030301@muppetlabs.com>
> By author:    Amit D Chaudhary <amit@muppetlabs.com>
> In newsgroup: linux.dev.kernel
> >
> > On the same topic, I have not found any change in free memory
> > reported before and after the ioctl call. Though umount /initrd does
> > free around 2 MB.
> >
>
> With Scott's patch applied, I get substantially better performance on
> low-memory machines, so I'm guessing it's doing its job.  Also, just
> umount /initrd for me made it still possible to mount it, so it
> clearly did not go away.

I can't take credit for the patch, just the (mis)fortune of having to
track down its existence. :)  All mentions of it in Alan's older change
logs have it uncredited, so I'm unsure if he or someone else fixed it.

Scott


-- 
=============================================================================
Scott Murray                                        email: scott@spiteful.org
http://www.spiteful.org (coming soon)                 ICQ: 10602428
-----------------------------------------------------------------------------
     "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"

Re: Can't free the ramdisk (initrd, pivot_root)

[Ralph Jones]

On Sun Apr 15 2001 - 15:57:52, EST Amit D Chaudhary (amit@muppetlabs.com) wrote:

>  On the same topic, I have not found any change in free memory reported before 
>  and after the ioctl call. Though umount /initrd does free around 2 MB. 

I have found the same thing - that umount /initrd seems to free the memory and that freeramdisk (with the patch to rd.c) does not appear to do anything.  

I have not found any more correspondance about this topic and was wondering if this behaviour was ok.  Specifically I would like to know if I need to apply the rd.c patch and then to run freeramdisk, or if I can just leave this out.  

Ralph Jones

Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com