Re: Can't free the ramdisk (initrd, pivot_root)
On Sun Apr 15 2001 - 15:57:52, EST Amit D Chaudhary ([EMAIL PROTECTED]) 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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
On Sun Apr 15 2001 - 15:57:52, EST Amit D Chaudhary ([EMAIL PROTECTED]) 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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 Murrayemail: [EMAIL PROTECTED] http://www.spiteful.org (coming soon) ICQ: 10602428 - "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness" - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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, ); + 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 Murrayemail: [EMAIL PROTECTED] http://www.spiteful.org (coming soon) ICQ: 10602428 - "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness" - 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/
Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 Murrayemail: [EMAIL PROTECTED] http://www.spiteful.org (coming soon) ICQ: 10602428 - "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness" - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 - 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/
Re: Can't free the ramdisk (initrd, pivot_root)
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 Murrayemail: [EMAIL PROTECTED] http://www.spiteful.org (coming soon) ICQ: 10602428 - "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness" - 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/
