Apparently not:
{pts/1}% head -2 /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / reiserfs rw 0 0
at least it is still mounted. Is there any way to free it?
TIA
-andrey
Andrey Borzenkov wrote:
> Apparently not:
>
> {pts/1}% head -2 /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/root / reiserfs rw 0 0
>
> at least it is still mounted. Is there any way to free it?
rootfs is always present. It's the root, as the name implies :)
Jeff
Jeff Garzik wrote:
> Andrey Borzenkov wrote:
>
>> Apparently not:
>>
>> {pts/1}% head -2 /proc/mounts
>> rootfs / rootfs rw 0 0
>> /dev/root / reiserfs rw 0 0
>>
>> at least it is still mounted. Is there any way to free it?
> rootfs is always present. It's the root, as the name implies :)
He's got two root filesystems, one on top of the other. It should be
possible to pivot root rather than mount the second one, thus freeing up
the memory from the initramfs.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
-----Original Message-----
>
> Jeff Garzik wrote:
> > Andrey Borzenkov wrote:
> >
> >> Apparently not:
> >>
> >> {pts/1}% head -2 /proc/mounts
> >> rootfs / rootfs rw 0 0
> >> /dev/root / reiserfs rw 0 0
> >>
> >> at least it is still mounted. Is there any way to free it?
>
> > rootfs is always present. It's the root, as the name implies :)
>
> He's got two root filesystems, one on top of the other. It should be
> possible to pivot root rather than mount the second one, thus freeing up
> the memory from the initramfs.
>
my example is after pivot_root. I still have two roots.
To clarify. I want to replace initrd with initramfs. Given all
the stuff may be put in it can easily be expanded to a couple of MBs.
initrd frees this. I do not want to waste RAM to leave them in initramfs.
thank you
-andrey
Andrey Borzenkov wrote:
> my example is after pivot_root. I still have two roots.
>
> To clarify. I want to replace initrd with initramfs. Given all
> the stuff may be put in it can easily be expanded to a couple of MBs.
> initrd frees this. I do not want to waste RAM to leave them in initramfs.
Absolutely, the memory should be reclaimed. I would have thought that
you could just unmount it--if the pivot_root is done properly there
shouldn't be any references left to the initramfs.
Jeff?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
Chris Friesen wrote:
> Andrey Borzenkov wrote:
>
>> my example is after pivot_root. I still have two roots.
>>
>> To clarify. I want to replace initrd with initramfs. Given all
>> the stuff may be put in it can easily be expanded to a couple of MBs.
>> initrd frees this. I do not want to waste RAM to leave them in initramfs.
>
>
> Absolutely, the memory should be reclaimed. I would have thought that
> you could just unmount it--if the pivot_root is done properly there
> shouldn't be any references left to the initramfs.
>
> Jeff?
You can't unmount rootfs. And I'm not sure pivot_root will work, though
we're quickly reaching the end of my knowledge[1]. Certainly the
equivalent of "rm -rf *" will work.
Jeff
[1] without reviewing the code again :)
Chris Friesen wrote:
> Absolutely, the memory should be reclaimed. I would have thought that
> you could just unmount it--if the pivot_root is done properly there
> shouldn't be any references left to the initramfs.
There is no pivot_root happening here; the kernel creates a ramfs and
mounts it on / (as rootfs), then unpacks the initramfs cpio archive into
it. After doing a few more steps, it overmounts the real root onto /,
making the rootfs filesystem invisible. It is not freed in the current
kernels.
I suspect that if you wanted to modify init/do_mounts.c, you could use
the initrd technique of doing the pivot_root yourself (instead of
letting the kernel automount the "real" root filesystem), at which point
it maybe be possible to umount and free the rootfs.
Kevin P. Fleming wrote:
> There is no pivot_root happening here; the kernel creates a ramfs and
> mounts it on / (as rootfs), then unpacks the initramfs cpio archive into
> it. After doing a few more steps, it overmounts the real root onto /,
> making the rootfs filesystem invisible. It is not freed in the current
> kernels.
Anyone know why it overmounts rather than pivots?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
> Kevin P. Fleming wrote:
>
> >There is no pivot_root happening here; the kernel creates a ramfs and
> >mounts it on / (as rootfs), then unpacks the initramfs cpio archive into
> >it. After doing a few more steps, it overmounts the real root onto /,
> >making the rootfs filesystem invisible. It is not freed in the current
> >kernels.
>
> Anyone know why it overmounts rather than pivots?
IIRC Al Viro did it on purpose, cause in this way he could get rid of
the special casing for the root filesystem in the VFS.
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com
On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
> Kevin P. Fleming wrote:
>
> >There is no pivot_root happening here; the kernel creates a ramfs and
> >mounts it on / (as rootfs), then unpacks the initramfs cpio archive into
> >it. After doing a few more steps, it overmounts the real root onto /,
> >making the rootfs filesystem invisible. It is not freed in the current
> >kernels.
>
> Anyone know why it overmounts rather than pivots?
Because amount of extra code you lose that way takes more memory than
empty roots takes.
Remove whatever files you don't need and be done with that.
[email protected] wrote:
> On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
>>Anyone know why it overmounts rather than pivots?
> Because amount of extra code you lose that way takes more memory than
> empty roots takes.
>
> Remove whatever files you don't need and be done with that.
How do you remove files from the old rootfs after the new one has been
mounted on top of it?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Mon, Nov 17, 2003 at 05:25:57PM +0000, [email protected] wrote:
> On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
> > Kevin P. Fleming wrote:
> >
> > >There is no pivot_root happening here; the kernel creates a ramfs and
> > >mounts it on / (as rootfs), then unpacks the initramfs cpio archive into
> > >it. After doing a few more steps, it overmounts the real root onto /,
> > >making the rootfs filesystem invisible. It is not freed in the current
> > >kernels.
> >
> > Anyone know why it overmounts rather than pivots?
>
> Because amount of extra code you lose that way takes more memory than
> empty roots takes.
Grr... My apologies - I shouldn't have posted before getting some coffee...
The short version of the story:
* empty rootfs consists of 1 struct superblock, 1 struct dentry and
1 struct inode. That's less than 1Kb.
* work with the mount tree is much easier if you know that its root
is always there and always the same.
* if we start playing with changing the absolute root of mount tree,
we will have to add rather unpleasant code in pivot_root() et.al. and that
extra code will definitely take more than 1Kb.
In other words, it's simply not worth the trouble. Unlike the situation with
initrd, memory is reclaimed when you do unlink() or rmdir() on rootfs. So
rm(1) will do nicely...
On Mon, Nov 17, 2003 at 12:50:34PM -0500, Chris Friesen wrote:
> [email protected] wrote:
> >On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
>
> >>Anyone know why it overmounts rather than pivots?
>
> >Because amount of extra code you lose that way takes more memory than
> >empty roots takes.
> >
> >Remove whatever files you don't need and be done with that.
>
> How do you remove files from the old rootfs after the new one has been
> mounted on top of it?
You do that before ;-)
On Mon, 2003-11-17 at 07:46, Jeff Garzik wrote:
> You can't unmount rootfs. And I'm not sure pivot_root will work, though
> we're quickly reaching the end of my knowledge[1]. Certainly the
> equivalent of "rm -rf *" will work.
The last time I checked (late 2.5.7x), pivot_root off an initramfs
didn't obviously break. This isn't the same as working correctly, but
nothing clearly wrong happened either.
<b
On Monday 17 November 2003 21:03, [email protected]
wrote:
> On Mon, Nov 17, 2003 at 12:50:34PM -0500, Chris Friesen wrote:
> > [email protected] wrote:
> > >On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
> > >>Anyone know why it overmounts rather than pivots?
> > >
> > >Because amount of extra code you lose that way takes more memory than
> > >empty roots takes.
> > >
> > >Remove whatever files you don't need and be done with that.
> >
> > How do you remove files from the old rootfs after the new one has been
> > mounted on top of it?
>
> You do that before ;-)
would the following work?
pivot_root . /initramfs
cd /initramfs && rm -rf *
?? doing it before is rather hard ... you apparently still need something to
execute your mounts :)
-andrey
On Mon, Nov 17, 2003 at 09:33:59PM +0300, Andrey Borzenkov wrote:
> On Monday 17 November 2003 21:03, [email protected]
> wrote:
> > On Mon, Nov 17, 2003 at 12:50:34PM -0500, Chris Friesen wrote:
> > > [email protected] wrote:
> > > >On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
> > > >>Anyone know why it overmounts rather than pivots?
> > > >
> > > >Because amount of extra code you lose that way takes more memory than
> > > >empty roots takes.
> > > >
> > > >Remove whatever files you don't need and be done with that.
> > >
> > > How do you remove files from the old rootfs after the new one has been
> > > mounted on top of it?
> >
> > You do that before ;-)
>
> would the following work?
>
> pivot_root . /initramfs
> cd /initramfs && rm -rf *
No. pivot_root() will not move the absolute root of tree elsewhere.
> ?? doing it before is rather hard ... you apparently still need something to
> execute your mounts :)
You do, but you can trivially call unlink() on the executable itself. It
will be freed after it does exec() of final /sbin/init...
Alternatively, you could
mkdir /root
mount final root on /root
chdir("/root");
mount("/", "initramfs", NULL, MS_BIND, NULL);
mount(".", "/", NULL, MS_MOVE, NULL);
chroot(".");
execve("/sbin/init", ...)
and have init scripts do rm -rf /initramfs/*; umount /initramfs
On Mon, Nov 17, [email protected] wrote:
> Alternatively, you could
> mkdir /root
> mount final root on /root
>
> chdir("/root");
> mount("/", "initramfs", NULL, MS_BIND, NULL);
Does this bind mount really work?
static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
{
return get_sb_nodev(fs_type, flags|MS_NOUSER, data, ramfs_fill_super);
}
static int graft_tree(struct vfsmount *mnt, struct nameidata *nd)
{
if (mnt->mnt_sb->s_flags & MS_NOUSER)
return -EINVAL;
...
--
USB is for mice, FireWire is for men!
sUse lINUX ag, nÜRNBERG
[email protected] wrote:
> On Mon, Nov 17, 2003 at 09:33:59PM +0300, Andrey Borzenkov wrote:
>
>>On Monday 17 November 2003 21:03, [email protected]
>>wrote:
>>
>>>On Mon, Nov 17, 2003 at 12:50:34PM -0500, Chris Friesen wrote:
>>>
>>>>[email protected] wrote:
>>>>
>>>>>On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
>>>>>
>>>>>>Anyone know why it overmounts rather than pivots?
>>>>>
>>>>>Because amount of extra code you lose that way takes more memory than
>>>>>empty roots takes.
>>>>>
>>>>>Remove whatever files you don't need and be done with that.
>>>>
>>>>How do you remove files from the old rootfs after the new one has been
>>>>mounted on top of it?
>>>
>>>You do that before ;-)
>>
>>would the following work?
>>
>>pivot_root . /initramfs
>>cd /initramfs && rm -rf *
>
>
> No. pivot_root() will not move the absolute root of tree elsewhere.
>
>
>>?? doing it before is rather hard ... you apparently still need something to
>>execute your mounts :)
>
>
> You do, but you can trivially call unlink() on the executable itself. It
> will be freed after it does exec() of final /sbin/init...
>
> Alternatively, you could
> mkdir /root
> mount final root on /root
>
> chdir("/root");
> mount("/", "initramfs", NULL, MS_BIND, NULL);
> mount(".", "/", NULL, MS_MOVE, NULL);
> chroot(".");
> execve("/sbin/init", ...)
>
Nope. initramfs shares the superblock with 'rootfs', which has the
MS_NOUSER flags set. Hence graft_tree() (which is the worker function
for MS_BIND) refuses to work.
Can't we just remove the MS_NOUSER flags if initramfs is active?
Probably not the correct way, but certainly the quickest :-)
The correct way would probably be to clone the superblock of initramfs,
set the filesystem-type of initramfs to 'ramfs' so that initramfs
appears to be a chroot()ed filesystem like initrd. Then we could do a
pivot_root and we have the contents of initramfs still available.
But needs someone with deeper fs-knowledge than myself to do it.
Cheers,
Hannes
--
Dr. Hannes Reinecke [email protected]
SuSE Linux AG S390 & zSeries
Deutschherrnstr. 15-19 +49 911 74053 688
90429 N?rnberg http://www.suse.de
On Wed, Nov 19, 2003 at 04:07:52PM +0100, Hannes Reinecke wrote:
> [email protected] wrote:
> >On Mon, Nov 17, 2003 at 09:33:59PM +0300, Andrey Borzenkov wrote:
> >
> >>On Monday 17 November 2003 21:03, [email protected]
> >>wrote:
> >>
> >>>On Mon, Nov 17, 2003 at 12:50:34PM -0500, Chris Friesen wrote:
> >>>
> >>>>[email protected] wrote:
[snip]
> >You do, but you can trivially call unlink() on the executable itself. It
> >will be freed after it does exec() of final /sbin/init...
> >
> >Alternatively, you could
> >mkdir /root
> >mount final root on /root
> >
> >chdir("/root");
> >mount("/", "initramfs", NULL, MS_BIND, NULL);
> >mount(".", "/", NULL, MS_MOVE, NULL);
> >chroot(".");
> >execve("/sbin/init", ...)
> >
> Nope. initramfs shares the superblock with 'rootfs', which has the
> MS_NOUSER flags set. Hence graft_tree() (which is the worker function
> for MS_BIND) refuses to work.
> Can't we just remove the MS_NOUSER flags if initramfs is active?
> Probably not the correct way, but certainly the quickest :-)
> The correct way would probably be to clone the superblock of initramfs,
> set the filesystem-type of initramfs to 'ramfs' so that initramfs
> appears to be a chroot()ed filesystem like initrd. Then we could do a
> pivot_root and we have the contents of initramfs still available.
> But needs someone with deeper fs-knowledge than myself to do it.
How about this one liner?
--- fs/ramfs/inode.c 22 Oct 2003 15:19:58 -0000 1.39
+++ fs/ramfs/inode.c 25 Nov 2003 18:10:00 -0000
@@ -207,7 +207,7 @@
static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
{
- return get_sb_nodev(fs_type, flags|MS_NOUSER, data, ramfs_fill_super);
+ return get_sb_single(fs_type, flags, data, ramfs_fill_super);
}
static struct file_system_type ramfs_fs_type = {
Since rootfs is supposed to be mounted just once, it shouldn't be a
problem using get_sb_single().
This way, you can mount rootfs anytime, and get in there to remove
files.
Am I missing something obvious here?
Have a nice day
Manuel
--
--- Manuel Estrada Sainz <[email protected]>
<[email protected]>
<[email protected]>
------------------------ <[email protected]> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.