Yes, of course.
>Also, with exec chroot /mnt ... , can you get rid of initrd afterwards ?
>/ should be busy because of /mnt, so you're stuck without something like
>the magic in change_root. This is particularly bad on systems with a big
>initrd which always need it to boot (i.e. not just during installation).
>I'm sure somebody out there must have a notebook with the hard disk on
>PCMCIA or such ...
In one "exec chroot..." initial ramdisk that I have used,
after the "exec chroot", mkfs is run on the initial ramdisk and it
is mounted as /tmp, which the kernel allows, so clearly the appropriate
reference count has dropped to zero.
As for reclaiming the space, I must admit that right now the
only technique that I know of is to use the kernel bug that causes
ramdisks to lose their contents when mounted with a blocksize different
from that which was used to initially write to them, so "mount -t iso9660
/dev/ramdsik" fails and releases the ramdisk memory. Clearly, a more
appropriate interface for releasing a ramdisk (any ramdisk, not just
the initial ramdisk) is needed.
There is an optimization to the write() system call that I
would like to see that involves detecting the following scenario:
mmap file1 --> memory
write memory --> file2
I would like to have write() call some kind of show circuit
file_operations->copy() routine in this case, which would typically
fall through to a some kind of device-level short circuit routine, so
that "cp filea fileb" would necessarily even result in data being
transferred across the scsi bus, even if the operation were done via
NFS if there were an extended NFS "copy" operation. Anyhow, my point
is that, with such an arrangement, it would also very easy to notice
"dd if=/dev/zero of=/dev/ramdisk" and just have the ramdisk release
pages that are being replaced with pages from /dev/zero. To me, that
would be the most elegant solution.
I agree that until there is a standard way to release the ramdisk
storage, we should not eleiminate the old change_root() stuff.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu