Thread: Overlay for root filesystem
View Single Post
Old 03-04-2012, 11:40 PM   #20
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by Nyoxi View Post
Do you also have an idea how could we use that? Just by switching mmcblk0p1 from ext3 to squashfs would not help. To make proper use of the free space we would have to create new partition for our overlay between *p1 and *p2 which whould cause renumbering of all the other partitions. And would mean changing lot's of scripts and files on both main and diag partitions, but most importantly you probably wouldn't be able to boot into diags at all (or is there some idme or other variable that sais which partition to use?). The other option is to move all the partitions to move the free space to the end but this has also a few problems. First, are we sure diags will still work? Isn't there anything that relies on the original address of mmcblk0p2 on MMC? And you would have to do that before user puts his data onto userspace or you risk not having enough free space to move the partition.

But maybe I missed something.

By the way, I wouldn't shun people at lab126 because of this -- they didn't decide to use overlay (we did). And simply exchanging the free space on root filesystem for free space on overlay doesn't make you gain anything.

PS: Could you also post the real filesystem usage to be completely fair? I don't have those devices and I am too lazy to check that for KT.
I agree, it would be a major re-design effort.

I can't even guess at what might be gained or lost by it.

But still, a window of oppertunity to be kept in mind.

Right now, if people want to keep adding features to the system....
Well, there is a lot of storage available, and so what if the end result is the machine holds 1,200 books instead of 1,500?

Another oppertunity to keep in mind -
U-Boot has the ability to load a compressed kernel image and (on the k3) it is currently loading an uncompressed image.
That would result in a kernel image in about 1/2 the current storage area.
Or more features (modules) in the kernel without resizing its partition.

Just thoughts to keep in the back of one's mind, not any sort of plan or justification at the moment.
knc1 is offline   Reply With Quote