[Galaxy Y GT-S5360 General] halnovemila:
Hello everyone, I want to share my findings on the topic said in the thread title.

Someone used to visit this forum might think that the topic is been asked and answered already in the past but what I found is something that is not been said already, or, at least, is not that easy to find.

Owners of smartphone with very limited internal storage, like Galaxy Y, will likely end up to be concerned of every single MB of storage space that seems to be "lost"; and so that's why me too I start my search to find the reason and any possibile fix to get rid of a large "system data" block that was wasting about 7% of space in my 2nd SDcard partition.

Let's note this please: I'M NOT talking about the "system data" block shown in the primary (1st or only) partition on SDcard as shown by the Diskusage app.

*THAT* "System data" block is just the space used by the .android_secure folder (that exist on root of SDcard in case some apps have been moved there) but not reported by Diskusage in the shown *virtual* App2SD folder.

The SDcard/.android_secure folder is mount as /mnt/secure/asec and there the size can be checked.

As you can see the size of .android_secure folder, in this example, is 179.60MB that is exactly the sum of App2SD folder and System data block (85.5+94.1=179.6).

But what is this?

Here you can see a "huge" 28.4MB "System data" block that eats more than 7% of the 2nd SDcard partition.

As many other Galaxy Y owners I've installed Link2SD app on my phone, that provides a convenient way to move davilk-cache apps files (eventually along with the data files in the Plus version) from internal storage Data partition to a secondary partition on the SDCard.

In my opinion Link2SD is the best solution for storage management... beside that Link2SD provide a lot of useful functionalities and informations, it is also not advisable to completely replace the small internal Data partition with a big partition that reside on the SDcard, because in the not so unlikely event of a SDcard failure the phone will be left in a completely unusable status; furthermore the internal storage sequential write and random performance might be much better than a cheap SDcard.

....

[/data partition performance test with AndroBench]...[/sdcard partition performance test]

With the help of Link2SD (and many other manual operations) I've been able to get an excellent 55% of free storage space in /Data partition while the phone is still fully functional in case of removal, missing, or failure of SDcard.

[User apps fully installed and running in internal storage(/system, /data, /cache): Browser, Youtube, Quickoffice, Maps, Google Play Store, Trillian, VoipCheapGlobal, Gmail, Mail, QuickPic, Tethering Widget, Flashlight, Root Explorer, Terminal Emulator, SSHDroid, VNC_server]

Unlike the "System data" block in SDcard, the one in 2nd partition is completely unrelated to any apps and, THERE'S NO WAY TO REMOVE IT BY DOING ANY FILE OR FOLDER REMOVAL.

What DiskUsage show as "System data" is actually "reserved blocks" that is pertinent to the design of Ext filesystems generation (Ext2/3/4), along with the blocks used for journaling (Ext3/4).

Those "reserved blocks" were thought as a "emergency room for root" to avoid the case of root user not able to login because of zero left free space in filesystem.

By deafult this reserved blocks amount is computed as 5% of filesystem size, and that might be a super huge waste of space (think of a 50GB reserved on a 1000GB filesystem) especially in the case of a "non system" partition, like the ones in SDcard (other infos here http://unix.stackexchange.com/questions/41125/ext2-3-4-reserved-blocks-percentage-purpose).

So, in order to free up the useless "reserved blocks", that's what I did on a Linux box equipped with a card reader (/dev/mmcblk0)

First I checked the amount of reserved blocks

root@Microknoppix:/home/knoppix# tune2fs -l /dev/mmcblk0p2 | grep Reserved
Reserved block count: 21247
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)

Then I've set the reserved blocks percentage to 0%

root@Microknoppix:/home/knoppix# tune2fs -m 0 /dev/mmcblk0p2
tune2fs 1.42.5 (29-Jul-2012)
Setting reserved blocks percentage to 0% (0 blocks)

DONE! :D

While doing my research on this topic, I realized that my Ext3 filesystem I made long time ago, didn't fit the whole partition... so I had few extra MB wasted; to get them back that's what I did:

I first checked the partition size

root@Microknoppix:/home/knoppix# fdisk -l | grep mmcblk0p2
/dev/mmcblk0p2 3037184 3887103 424960 83 Linux

mount the partition in /media/mmcblk0p2 and checked the filesystem size

root@Microknoppix:/home/knoppix# df /media/mmcblk0p2
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mmcblk0p2 404378 295442 88052 78% /media/mmcblk0p2

UNMOUNT and perform a filesystem check (mandatory)

root@Microknoppix:/home/knoppix# umount /dev/mmcblk0p2

root@Microknoppix:/home/knoppix# e2fsck -f /dev/mmcblk0p2
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mmcblk0p2: 2769/104448 files (24.8% non-contiguous), 308754/417690 blocks

resize the filesystem to partition size

root@Microknoppix:/home/knoppix# resize2fs /dev/mmcblk0p2
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mmcblk0p2 to 424960 (1k) blocks.
The filesystem on /dev/mmcblk0p2 is now 424960 blocks long.

Mount again and check the new filesystem size:

root@Microknoppix:/home/knoppix# df /media/mmcblk0p2
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mmcblk0p2 411387 295442 94698 76% /media/mmcblk0p2

And that's the final result! :D

"System data" shrinked from 28.4MB to only 8MB! :cool:

The left 8MB are in use for the filesystem journaling.

FAT and Ext2 filesystems doesn't make use of journaling so there's not reserved space for that.

Therefore in order to gain few others free MB is possible to use Ext2 in place of Ext3, given that Ext2 (according to a Wikipedia page here http://en.wikipedia.org/wiki/Ext2 ) "is still the filesystem of choice for flash-based storage media".

...