R0B_IX wrote:I just had two thoughts on this, not sure if any will interest you, but, couldn't you...
1. Compress the entire tree, and then make some scripts to uncompress the tree when running an emerge option, and then recompress it afterwords? Assuming you had that 250 megs free, then it should work just fine.
This would give back the space for normal work. However emerge operations would still require the same amount of free space due to the uncompression of the tree. This is actually the real problem on my box as I had to update my gcc which needs obviously about 250mb for extraction of the distfile to /var/tmp and patching. I'll see if the build process will require additionally a lot more space.
R0B_IX wrote:
2. You could put the tree on a cd-rw, and then, similar to the previous script, have a script that "tricks" the emerge function into thinking that it is writing to the cd when doing an emerge sync, when you are actually redirecting the files somewhere else, and then you can update the cd-rw at your convenience with the latest additions/subtractions. A little more difficult than the first option, but with this option, you would never need to have the 250 megs free after the initial burn (assuming the portage tree isn't 100% redone, which I am sure will at least slightly annoying a bunch of people
. Anyways, post back if you think of any more ideas.
This workaround is somehow again a solution by just adding additional space (hdd or cd, doesn't matter).
Again, as far as I can judge on the implementation of the portage tree I'd say: The tree itself uses too much space compared to the functionality. I guess it could seriously be done without the waste of space.
I think there's a real overhead due to the filesystem. I dunno how much file system space is really needed for a single file entry in the file system. But consider this:
Assumed a file entry on the disk needs 4k (I've really no idea if this is the case) and there are 57000 files. This would lead to a space consumption of 228MB. This is really scary as this is in the range of the real size of the current portage tree on my boxes. The missing 20-30MB are probably the file sizes of the ebuild scripts theirself.
Now consider this:
Code: Select all
aphrodite root # find /usr/portage/ > test.txt
aphrodite root # ls -alF
total 3216
drwx------ 21 root root 4096 Aug 16 21:13 ./
drwxr-xr-x 19 root root 4096 Jul 20 18:53 ../
-rw-r--r-- 1 root root 2902064 Aug 16 21:13 structure.txt
aphrodite root #
The structural information of the portage tree in a plain textfile takes nearly 3mb. Nice and small.
Still missing: the ebuild scripts, manifest files, Changelog files, Digest files, patch files... all summed up with find:
Code: Select all
-rw-r--r-- 1 root root 218197 Aug 16 21:19 Changelogs.txt
-rw-r--r-- 1 root root 212925 Aug 16 21:19 Manifest.txt
-rw-r--r-- 1 root root 634942 Aug 16 21:19 digest.txt
-rw-r--r-- 1 root root 572587 Aug 16 21:16 ebuilds.txt
-rw-r--r-- 1 root root 92642 Aug 16 21:18 patches.txt
-rw-r--r-- 1 root root 2902064 Aug 16 21:13 structure.txt
aphrodite root #
Perhaps I forgot some file types but the real sum of the above stuff is not more than 5mb including the structural layout.
Now compare 250mb against 5mb. If this could really be implemented in a more efficient manner the gain would be factor 50 !
Cheerz Al[/quote]
).
And I guess that number will increase with every new ebuild.
