Free Up Flash Space With Strip *?

[daniel3000]

Hi,

is there any danger in running a "strip *" on all binaries and libs in all directories in order to free up some space (hopefully)?

daniel

[lardman]

Should be fine. They should all have been stripped already when 'make install 'was run.


Si

[daniel3000]

was brave - tested that.
Went into the various bin and lib directories and did

Code: [Select]

find -type f -exec strip '{}' \; -print
The results are partially remarkable:


/usr/bin: 23.4 -> 22.2 MB (-1.2MB)
/usr/local/bin: 6.8 -> 6.3 MB (-0.5MB)
/bin: 1.6 -> 1.6MB (0)
/sbin: 1.8 -> 1.8MB (0)
/usr/sbin: 2.9 -> 2.9MB (0)
/lib: 7.7 ->
/usr/lib: 105.5 -> 97.7MB (-7.8MB)


...here I stopped:
The decreased directory size is good, but OTOH df -h now shows only 2MB free on / instead of 6MB as before that process.
During stripping, it even showed ZERO free space on root.
Any idea what the reason could be?
Does strip create data somewhere which is doesn't delete again?

This is not the final result I wanted to see...    

Thanks for any hint!
daniel

[Chero]

was brave - tested that.
Went into the various bin and lib directories and did

Code: [Select]

find -type f -exec strip '{}' \; -print
The results are partially remarkable:


/usr/bin: 23.4 -> 22.2 MB (-1.2MB)
/usr/local/bin: 6.8 -> 6.3 MB (-0.5MB)
/bin: 1.6 -> 1.6MB (0)
/sbin: 1.8 -> 1.8MB (0)
/usr/sbin: 2.9 -> 2.9MB (0)
/lib: 7.7 ->
/usr/lib: 105.5 -> 97.7MB (-7.8MB)


...here I stopped:
The decreased directory size is good, but OTOH df -h now shows only 2MB free on / instead of 6MB as before that process.
During stripping, it even showed ZERO free space on root.
Any idea what the reason could be?
Does strip create data somewhere which is doesn't delete again?

This is not the final result I wanted to see...   

Thanks for any hint!
daniel
[div align=\"right\"][a href=\"index.php?act=findpost&pid=147496\"][{POST_SNAPBACK}][/a][/div]

check tmp

[Meanie]

was brave - tested that.
Went into the various bin and lib directories and did

Code: [Select]

find -type f -exec strip '{}' \; -print
The results are partially remarkable:


/usr/bin: 23.4 -> 22.2 MB (-1.2MB)
/usr/local/bin: 6.8 -> 6.3 MB (-0.5MB)
/bin: 1.6 -> 1.6MB (0)
/sbin: 1.8 -> 1.8MB (0)
/usr/sbin: 2.9 -> 2.9MB (0)
/lib: 7.7 ->
/usr/lib: 105.5 -> 97.7MB (-7.8MB)


...here I stopped:
The decreased directory size is good, but OTOH df -h now shows only 2MB free on / instead of 6MB as before that process.
During stripping, it even showed ZERO free space on root.
Any idea what the reason could be?
Does strip create data somewhere which is doesn't delete again?

This is not the final result I wanted to see...   

Thanks for any hint!
daniel
[div align=\"right\"][a href=\"index.php?act=findpost&pid=147496\"][{POST_SNAPBACK}][/a][/div]

that's expected. jffs2 is a compressed filesystem. the amount of free space is calculated from the ratio of compression with available blocks. since you stripped all the binaries, the compressability  of the files have reduced and hence the ratio of compression also changed, so the result you see is correct. compression files on a jffs2 fs is counterproductive.

[daniel3000]

Hi Chero,

/tmp is not on the root fs, but /dev/shm/tmp (12MB).
However, there is nothing left from strip.

Hi Meanie,

I thought strip strips unneeded stuff, but doesn't compress the remaining dat?
So the compression ratio should not be affected significantly, to my understanding.

Also, doesn't jffs consider ALL the data on the drive for calculatoin of free space from compression ratio? Since I only got 10 MB from a 121MB drive, this is less than 10%. How can jffs reduce the amount of free calculated memory from about 15MB (as it should be after the stripping) to only 2MB, and especially: why should jffs calculate 0MB free DURING the stripping?
Also: After I strip data, I have more space. Even if compression is not that effective afterwards, shouldn't jffs report also MORE free space, but just not as much more as I deleted/stripped?
That's not clear to me.

I restored the backup of last night with the unstripped binaries, just to be sure there is no crap data.


And while we are at it:

I have installed the newer freetype library (see epdfview/poppler thread).
I wondered why this is so much larger than the old freetype.
Ran a "strip" on /usr/lib/libfreetype.a and /usr/lib/libfreetype.so.6.3.8 and guess what?
Together they shrank from about 3MB to 600kB. :-)
df -h reported 6.1MB before, now it reports 7.3MB free space.

So, to take this as a result for above discussion:
strip deleted 2.4MB of data,
df -h reports 1.2MB more free space (factor 0.5).

...will post about that on the epdfview thread, too, so people can reduce the size of the installation of freetype.

daniel

[pelrun]

That cannot be it - no matter how highly compressible the data removed is, the resultant smaller file can't be larger after compression than the original. Yes, the ratio would be different, but that number is meaningless without the uncompressed sizes of the files being identical (which they obviously cannot be.)

Perhaps he's just caused the jffs2 journal to balloon in size with all the writes that stripping operation incurred.

[desertrat]

On a "regular" filesystem, if a file that is being used is changed/deleted/replaced the system will keep a copy of the original hanging around so that any processes running which needs that file will not be shafted. When all processes requiring that file is terminated the copy of the original is removed. This mechanism is probably why Linux only requires a reboot when changing kernels, whereas in windoze "your mouse has moved you need to restart windows for the changes to take effect".

So basically rebooting your machine should (hopefully ) get your free space back.

[lardman]

Perhaps he's just caused the jffs2 journal to balloon in size with all the writes that stripping operation incurred.

That would be my guess.

Try a couple of reboots and see if jffs2 will reclaim the space that was used by the old files.


Si

[pelrun]

If it is the journal then reboots won't make any difference, as it's stored in the flash as well.

But desertrat raises a good point, under linux open file handles increment the reference count on files, preventing the space from being reclaimed even if you've deleted all the hard links on the drive for that file. A reboot will sort all of those files out.

[lardman]

It needn't be the journal itself though, it could simply be that the jffs2 garbage collector hasn't got around to running and reclaiming the space.

My understanding is that a reboot tends to get this to run (though I'm a little foggy on the details, if anyone knows better please let me know)


Si