Nice to hear, sr00t, but as i understand it, the problem is not with general Easy Debian use, but with initial unpacking Easy Debian image. That shouldn't take more than 15 minutes, but many time last for 2 hours, and you may not see happy ending, because N900 tend to reboot after long time of 0 responsiveness.

It apply to any big file unpacking (or even copying!) in general, not only Easy Debian.

My stone to the garden - i use swap on SD class 2 only, and even with such low class, i see massive improvement, don't even need to use swapoff/swapon. Have in mind that i also tweaked nr_request to 256. That seems quite opposite to setting proposed in first post of this topic - maybe it need update?

My findings are exactly the same, see my settings here http://talk.maemo.org/showpost.php?p...&postcount=112, proved to work. I have nor swapolube installed neither other tweaks (KP46 of course).

To OP - please either remove or update first post to reflect latest findings. Thanks.

oooohhh.....awright! fdisk-ing microSD to a 1gb swap partition.

Swapoff/swapon has the side effect of defragmenting the swap area, which makes future swap writes faster.

install swapon from debian package called as mount. unzip using archive manager and copy it to where every you want. there is a thread for creating swap on mmc.

i also have swapon and off script which basically switches one off and second on and otherway round so that all swap gets defragmented. i run generally in 3 to 4 days to cleanup swap space.

I have a script which looks at the output of 'iostat -m' command. When the amount of megabytes written to a swap partition exceeds the size of the swap partition, the fragmentation effects start. I store the megabytes written in a file after reswap(swapon temp, swapoff main, swapon main, swapoff temp) and keep track of bytes written after last reswap.

I also run a re-swap and chunk out to temp and then back to primary every 3 days at 4 AM with fcron.

Helps a ton.

@shadowk & hawaii:

Do you both do this using the internal swap? I'm curious how much of the slowness people regularly report comes from I/O collisions with the eMMC and how much comes from the swap partition fragmentation - since not that many people move swap off-device onto a microSD and even less run scrips like you two do to make sure swap stays fresh and defragmented I can't help but wonder which of these actually helps more; and if you have experience with both methods seperately, and/or one method seperately and both methods combined, if you perceived one as no longer useful once the other one was implemented. I.E do you feel moving swap to the sd card helps even if you're already doing the swap-space cleaning thing (and vice versa, though I suspect preventing fragmentation is always going to be an improvement in the long run - it's only the disk I/O thing I think could be negligible, given the discoveries in this thread that swapoff/swapon seems to speed up things that were originally believed to be the fault of I/O bottlenecks)?

I first moved swap to microsd. This helped a little with some I/O heavy things. but found that "stutter" increased significantly after 3-4 days uptime.

I then made a script to dump info (sector numbers) of all write accesses to microsd, plotted that on a graph on my PC. Discovered that it was a linear line (mostly) until reaching the end of the swap area, after which the dots indicating which sector was written to became more and more random. This is how I discovered swap fragmentation issue and the fix.

As I still need a temporary swap for the swapoff/swapon cycle I just kept swap mainly on microsd, and use the emmc swap temporarily when refreshing the microsd swap.

I only use swap on external microsd. I never bothered to do anything intelligent :P I just set a 2 day nightly "reswap" provided my device was locked, plugged in and it was 3 AM in the morning.

I still reboot my device every now and then to clean out cobwebs.