Off-Topic > Off-Topic - Tiny Tux's Corner
problem mounting tmpfs
wysiwyg:
Ok, further testing has produced an interesting result. If I mount in this order instead of the order from the OP, everything works fine:
mount /dev
mount /proc
mount /sys
mount /dev/pts
echo /sbin/mdev > /proc/kernel...; mdev -s
Why would one way work over the others? How is the same space not being taken up doing things in this order versus the other?
One other question... why wouldn't it be better to use a ramdisk (e.g. /dev/ram0) formatted with ext2/3/4 to switch root to instead of another tmpfs? To me, it would seem one way can clearly define a "work space" whereas the tmpfs could just continue to grow and potentially use up all the ram available.
curaga:
--- Quote from: wysiwyg on January 06, 2011, 09:40:02 AM ---As in the copy using the TC code provide in the OP?
--- End quote ---
Yes.
--- Quote ---One other question... why wouldn't it be better to use a ramdisk (e.g. /dev/ram0) formatted with ext2/3/4 to switch root to instead of another tmpfs? To me, it would seem one way can clearly define a "work space" whereas the tmpfs could just continue to grow and potentially use up all the ram available.
--- End quote ---
Always fixed size, formatting takes time, no swapping, and unused, but previously used space takes ram.
wysiwyg:
--- Quote from: curaga on January 06, 2011, 09:59:25 AM ---
--- Quote ---One other question... why wouldn't it be better to use a ramdisk (e.g. /dev/ram0) formatted with ext2/3/4 to switch root to instead of another tmpfs? To me, it would seem one way can clearly define a "work space" whereas the tmpfs could just continue to grow and potentially use up all the ram available.
--- End quote ---
Always fixed size, formatting takes time, no swapping, and unused, but previously used space takes ram.
--- End quote ---
That makes sense. I am, however, trying to limit the amount of space the tmpfs can use (to prevent problems with programming mistakes or malicious activity). I suppose I can just use the 'size=' parameter, that way the only "drawback" will be a smaller fixed size than the 90% assigned by TC. :)
And yet... another question! :) Going back to the OP question about the switch_root, so is the only reason TC does this so that binaries like df work correctly or are there other reasons too?
Dave
curaga:
No other reasons really. As you can see, with the "embed" bootcode that part is skipped.
Our kernel is patched anyway so that rootfs is tmpfs, and so we get the other benefits of tmpfs (swap-ability) even with an embed boot.
wysiwyg:
--- Quote from: curaga on January 06, 2011, 02:02:20 PM ---No other reasons really. As you can see, with the "embed" bootcode that part is skipped.
Our kernel is patched anyway so that rootfs is tmpfs, and so we get the other benefits of tmpfs (swap-ability) even with an embed boot.
--- End quote ---
Is it possible to just patch the kernel so there's no need to do a swap? This can save some time. If the 'embed' bootcode skips it, wouldn't some binaries using that system still mess up (e.g. df)?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version