[Samsung Galaxy W I8150] v0rt3x:
Actually it depends on how much applications you want being installed on your phone but yes it worths installing it for at least 5 reasons:

Being able to mount to your computer your SD cards using the debug mode without stopping the applications that you should have moved to the SD card using the native App2SD.

Not being limited by the size of the /data partition because of the *.dex files generated for the dalvik cache.

You can move any kind of applications even those that are not movable to SD!

Link2SD includes free utilities like conversion of system application to user application (and vice versa) that you'll have to pay for with other solutions like Titanium Backup.

Avoiding slow downs because of the loop mounts created (Just run the "mount" command from an adb shell or terminal and you'll see).

Indeed I noticed a global slow down of my phone after I've started getting more and more applications being installed and beside I'm using some other tool to avoid push services and other unwanted background processes to be started by some applications, I've come to the conclusion that too many loop mounts because of the native App2SD is not good either (I suspect it takes over the RAM).

Actually the Link2SD FAQ will give you all the good reasons why to use it:

http://www.link2sd.info/faq

Recommendations:

I'd like to also share share my experience (I may move the following to another thread):

Recommend microSD cards:

Regarding the microSD card you can use even a 32 GB class 10.

The ones I recommend (32 GB class 10) are Samsung, SanDisk, Transcend (Those Transcend ones made in Korea are logically made by Samsung, the ones made in China are made by SanDisk).

Partitionning and formatting:

The tough part is the partitioning and formatting.

Out of the box, all the microSD cards are partitioned and formatted so that they are aligned with their erase block size (it can be 8 MiB, 12 MiB...)

Thus you'll have to consult so you'll know the erase block size:

the Linaro flash card survey:

https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey

the corresponding flashbench mailing list

http://lists.linaro.org/mailman/listinfo/flashbench-results

You can also use the flashbench tool to figure it out.

The problem is that you cannot create or resize the FAT32 partition using Windows (even with minitool partition or paragon partition manager), nor with Linux by using gparted or other because you won't get your partitions aligned with the erase blocks and thus you'll get bad performances and faster wearing of your card.

Backup:

Before formatting do a raw backup of the first 16 MiB (for the partitions table and the FAT32 description) using busybox dd on the phone itself or dd on Linux.

For example on the phone:

dd if=/dev/block/mmcblk1 of=/sdcard/mmcblk1-orig-1st-16MiB.img bs=4M count=4

Also you must keep using the default cluster size of 32 kiB because of optimization done at the level of Android and because smaller cluster size will mean more memory taken from the RAM - Actually the FAT is loaded in the RAM, so you must keep it not too big.

Formulas:

Then decide how much you need for the Link2SD partition - You can start with 1 GiB or so, personally I use about 2 GiB. You can check how much space is taken by the asec images to decide...

Now here comes some math (The formulas are to be used in LibreOffice Calc):

Partitioning:

We need to define the new size for the FAT32 partition at the beginning so it is aligned with the erase block size and so that the File Allocation Tables are located between the special offsets (especially true with SanDisk - for example the FAT must be located between the offsets at 4 MiB and 12 MiB, that's why most SD card have 4 MiB unpartitioned free space at the beginning).

new_fat32_partition_size = MROUND(whole_microsd_size - wanted_link2sd_partition_size + fat32_start_offset ; erase_block_size) - fat32_start_offset

With:

whole_microsd_size: The actual total size of the card - You can get it using fdisk.

wanted_link2sd_partition_size: The size you'd like for the Link2SD partition.

fat32_start_offset: The offset where the 1st FAT32 partition starts.

erase_block_size: The erase block size.

So for example for a SanDisk microSDHC 32 GB Class 10, we have an erase block size of 12 MiB (actually 3 times 4 MiB) and a FAT description that has to start at the offset at 4 MiB and then next erase block that starts at the offset at 12 MiB.

Therefore you'll have:

new_fat32_partition_size = MROUND(30,101,504 kiB - 1,061,376 kiB + 4,194,304 kiB ; erase_block_size) - 12 582 912 kiB = 30,101,504 kiB

Therefore using fdisk you should get something like the following when printing the partitions (p) - Don't forget to disable the DOS compatibility flag and use the sector as the unit:

Disk /dev/mmcblk0: 31.9 GB, 31914983424 bytes
4 heads, 16 sectors/track, 973968 cylinders, total 62333952 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9a064f9d

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 60211199 30101504 c W95 FAT32 (LBA)
/dev/mmcblk0p2 60211200 62333951 1061376 83 Linux

FAT32 formatting:

In order to use mkdosfs 3.0.9 or later with the right amount of reserved sectors so the root directory and data will start exactly at the next erase block offset.

The idea is to make so that the FATs ends exactly before that offset, but for that we need to know the size of one FAT.

Here is the formula based on mkdosfs source code, to calculate that needed number of reserved sectors:

total_number_of_sectors = total_number_of_blocks * block_size / sector_size

number_of_sectors_for_fats_and_data = total_number_of_sectors - MROUND(default_number_of_reserved_sectors ; cluster_size)

number_of_clusters = (number_of_sectors_for_fats_and_data * sector_size + number_of_fats * 8) / (cluster_size * sector_size + number_of_fats * 4)

fat_size = MROUND(CEILING((number_of_clusters + 2) * 4 / sector_size ; 1) ; cluster_size)

root_directory_offset = default_number_of_reserved_sectors + number_of_fats * fat_size

aligned_root_directory_offset = MROUND(root_directory_offset ; erase_block_size * 1024^2 / sector_size)

number_of_reserved_sectors = aligned_root_directory_offset - root_directory_offset + default_number_of_reserved_sectors

With:

sector_size: 512 bytes (Standard value)

block_size: 1,024 bytes (Standard value)

total_number_of_blocks: new_fat32_partition_size in kiB

default_number_of_reserved_sectors: 64 (can be 32)

cluster_size: 64 sectors (i.e. 32 kiB)

number_of_fats: 2 (Standard value)

So for example for that same card you'll get:

total_number_of_sectors = 60,203,008

number_of_reserved_sectors = 1,664

Therefore here is the command to format the FAT32 partition:

$> sudo mkdosfs -F 32 -s 64 -R 1664 -n EXTERNAL_SD -v /dev/mmcblk0p1

mkdosfs 3.0.9 (31 Jan 2010)
/dev/mmcblk0p1 has 4 heads and 16 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 60203008 sectors;
file system has 2 32-bit FATs and 64 sectors per cluster.
FAT size is 7360 sectors, and provides 940416 clusters.
There are 1664 reserved sectors.
Volume ID is 8aa89e36, volume label EXTERNAL_SD.

You can see that each FAT takes less than 3.6 MiB, so with 2 FATs and the reserved sector the FAT description takes less than 8 MiB.

You can then check using hexdump if indeed the root directory starts at the the 12 MiB offset (knowing that the partition begin at the 4 MiB offset - indeed 12 = 4 + 8).

For that let's read the first 13 MiB of the card:

$> sudo hd -n $[13*1024*1024] /dev/mmcblk0

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 82 |................|
000001c0 03 00 0c f8 95 a3 00 20 00 00 00 a0 96 03 00 f8 |....... ........|
000001d0 96 a3 83 1b f3 28 00 c0 96 03 00 64 20 00 00 00 |.....(.....d ...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400000 eb 58 90 6d 6b 64 6f 73 66 73 00 00 02 40 80 06 |.X.mkdosfs...@..|
00400010 02 00 00 00 00 f8 00 00 10 00 04 00 00 00 00 00 |................|
00400020 00 a0 96 03 c0 1c 00 00 00 00 00 00 02 00 00 00 |................|
00400030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00400040 00 00 29 e5 a5 dc 46 45 58 54 45 52 4e 41 4c 5f |..)...FEXTERNAL_|
00400050 53 44 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac |SDFAT32 ...w|.|
00400060 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 5e eb f0 32 |".t.V.......^..2|
00400070 e4 cd 16 cd 19 eb fe 54 68 69 73 20 69 73 20 6e |.......This is n|
00400080 6f 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 64 69 |ot a bootable di|
00400090 73 6b 2e 20 20 50 6c 65 61 73 65 20 69 6e 73 65 |sk. Please inse|
004000a0 72 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 66 6c |rt a bootable fl|
004000b0 6f 70 70 79 20 61 6e 64 0d 0a 70 72 65 73 73 20 |oppy and..press |
004000c0 61 6e 79 20 6b 65 79 20 74 6f 20 74 72 79 20 61 |any key to try a|
004000d0 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 00 00 00 00 |gain ... .......|
004000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400200 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|
00400210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004003e0 00 00 00 00 72 72 41 61 7e 59 0e 00 03 00 00 00 |....rrAa~Y......|
004003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400c00 eb 58 90 6d 6b 64 6f 73 66 73 00 00 02 40 80 06 |.X.mkdosfs...@..|
00400c10 02 00 00 00 00 f8 00 00 10 00 04 00 00 00 00 00 |................|
00400c20 00 a0 96 03 c0 1c 00 00 00 00 00 00 02 00 00 00 |................|
00400c30 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00400c40 00 00 29 e5 a5 dc 46 45 58 54 45 52 4e 41 4c 5f |..)...FEXTERNAL_|
00400c50 53 44 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac |SDFAT32 ...w|.|
00400c60 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 5e eb f0 32 |".t.V.......^..2|
00400c70 e4 cd 16 cd 19 eb fe 54 68 69 73 20 69 73 20 6e |.......This is n|
00400c80 6f 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 64 69 |ot a bootable di|
00400c90 73 6b 2e 20 20 50 6c 65 61 73 65 20 69 6e 73 65 |sk. Please inse|
00400ca0 72 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 66 6c |rt a bootable fl|
00400cb0 6f 70 70 79 20 61 6e 64 0d 0a 70 72 65 73 73 20 |oppy and..press |
00400cc0 61 6e 79 20 6b 65 79 20 74 6f 20 74 72 79 20 61 |any key to try a|
00400cd0 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 00 00 00 00 |gain ... .......|
00400ce0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400e00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004d0000 f8 ff ff 0f ff ff ff 0f f8 ff ff 0f ff ff ff 0f |................|
004d0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00868000 f8 ff ff 0f ff ff ff 0f f8 ff ff 0f ff ff ff 0f |................|
00868010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00c00000 45 58 54 45 52 4e 41 4c 5f 53 44 08 00 00 52 b3 |EXTERNAL_SD...R.|

We can see that indeed the root partition starts at the offset 0x00c00000 which is 12 MiB!

Also note that 0x00400000 is the 4 MiB offset, the beginning of the FAT32 partition...

You can try the hexdump against the backup you did and you'll see that the factory formatting is also with a number of reserved sector so that the root directory is aligned. For example I've found the root directory at the 12 MiB offset (of course) and for that they use 1,170 reserved sector (I've decoded the hexdump to get that value) which matches the formula. They also set 8,192 hidden sectors - that's more for compatibility with some cameras, we don't care here...

Link2SD formatting:

I use ext4 for that partition, I've got inspiration from http://blogofterje.wordpress.com/2012/01/14/optimizing-fs-on-sd-card/, however I'm not sure if indeed using the stride and the stripe-width options is really needed:

[FONT=Courier New]$ sudo mkfs.ext4 -O ^has_journal -E stride=4,stripe-width=512 -b 4096 -L Link2SD /dev/mmcblk0p2

mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=Link2SD
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=4 blocks, Stripe width=512 blocks
66384 inodes, 265344 blocks
13267 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=272629760
9 block groups
32768 blocks per group, 32768 fragments per group
7376 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.[/FONT]

Anyway I consider the Link2SD partition is going to be used much more for read than write and we need the same file system that is used on the other partitions of the phone (i.e. ext4).

I hope it's not too complicated and that will help ;)

Some other references:

http://android.bytearrays.com/android/align-your-sdcard-fat-and-ext-partition/

http://www.bradfordembedded.com/2011/12/format-an-sd-card-with-8-mib-aligned-partitions/

http://www.olpcnews.com/forum/index.php?topic=4993.0

http://www.patriotmemory.com/forums...ite-speed-by-aligning-FAT32&p=41521#post41521

http://xdaforums.com/showthread.php?t=1224408