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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
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: [email protected]
http://www.spiteful.org (coming soon) ICQ: 10602428
-----------------------------------------------------------------------------
"Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"
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
Followup to: <[email protected]>
By author: Scott Murray <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Followup to: <[email protected]>
By author: Amit D Chaudhary <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On 15 Apr 2001, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Amit D Chaudhary <[email protected]>
> 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: [email protected]
http://www.spiteful.org (coming soon) ICQ: 10602428
-----------------------------------------------------------------------------
"Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"