Where does the N900 swap live?

[epz]

I know the N900 has 256megs 768megs swap and 32gigs of storage.

Reading the reports im not clear if the swap is just a partition on the 32gig storage or a separate type of (hopefully) storage.

Whenever I setup a linux distro I much prefer to dynamically add the swap i need it by building a number of big empty file on / and formatting/mounting them as swap

[GeneralAntilles]

It's a partition on the internal 32GB eMMC:


768MB of swap
~2GB of ext3
Rest as FAT32

[Jack6428]

It's a partition on the internal 32GB eMMC:


768MB of swap
~2GB of ext3
Rest as FAT32


hey that's great..2GB for apps? i like that alot..now i will be able to install not only apps but games too :)

[solideogloria]

hey that's great..2GB for apps?

2b - Operating system

[epz]

cheers, looks like i will be doing some repartitioning, i would normally be slightly worried about a large amount of writes to an ssd but you can get a full kde desktop under 256 apparently since the qt4 rewrite

[Corwin_bg]

I know the N900 has 256megs 768megs swap and 32gigs of storage.

Reading the reports im not clear if the swap is just a partition on the 32gig storage or a separate type of (hopefully) storage.

Whenever I setup a linux distro I much prefer to dynamically add the swap i need it by building a number of big empty file on / and formatting/mounting them as swap
Keeping the swap on the large memory card means less overall wear, as the writes will be spread across the whole card.

[GeneralAntilles]

cheers, looks like i will be doing some repartitioning, i would normally be slightly worried about a large amount of writes to an ssd but you can get a full kde desktop under 256 apparently since the qt4 rewrite

It's an eMMC, actually. But modern flash isn't really all that prone to write failure. Especially if you don't fill it up completely.

[spock]

It's an eMMC, actually. But modern flash isn't really all that prone to write failure. Especially if you don't fill it up completely.

I'm not sure that's right. Modern flash is worse at cycling, and it's only getting worse as the lithography drops. Corwin was correct, spreading the writes across the whole card will significantly enhance the endurance, provided that it is actually done properly.

[Milhouse]

I'm not sure that's right. Modern flash is worse at cycling, and it's only getting worse as the lithography drops. Corwin was correct, spreading the writes across the whole card will significantly enhance the endurance, provided that it is actually done properly.

Seems to me that Corwin and GA are both right... the flash memory will wear level using free space, fill it up and wear levelling won't be so efficient (which is pretty much what GA is getting at). Mind you as long as the kernel implements TRIM the flash memory should be kept in good shape.

[attila77]

Free space (especially considering fragmentation and FAT) does influence it, but not directly. The eMMC works 2+ levels below the filesystem, it has no idea which parts does the FS consider 'empty' - but it doesn't have to know that to work ! Think about it this way - whether a block (from the FS aspect) is empty or not has nothing to with how many times it was overwritten in the past. It's better to move a newly written block to a long-time (FS wise) *occupied* block, if it was rarely rewritten in the past - and move the contents of that (apparently inactive) block to one that has a higher wear level. Now, you might think 'hey, but then it's not just a write, but a read, too, speed is going to suffer !'. Well, there are tricks for that, too - you can do this relocation *in advance*, anticipating writes, when the device is inactive (so, when you have nothing better to do, copy a few rarely used blocks (full or not) to new (high wear) places, and then mark the originating blocks as next up for writing. Lots of magic happening there under the hood. So much in fact, that if you start micromanaging your flash you actually have good chances of making things worse than if you did nothing special (as that's what the system was designed for :) )

[Milhouse]

http://www.anandtech.com/storage/showdoc.aspx?i=3631

OK, these are SSDs he's discussing but the gist is that free space is crucial to long term performance as it allows the device to consolidate or "clean" erase blocks (in real time or in the background), which is what I think you are alluding to attila77. This is why the TRIM command (supported by some MMC/eMMC 4.4 controllers) can help the SSD/eMMC to identify those pages containing invalid data and which are no longer used by the filesystem, and prioritise them for cleaning.

Erase block cleaning helps to minimize write amplification, which is good, as high write amplification reduces the benefit of wear levelling (ie. reduced memory lifespan).

Interesting to note that SSDs have up to 10% (or more) space set aside for the purpose of wear-levelling that can/will be used after every block has been written to once - I very much doubt such space is available to the N900 32GB eMMC though.

Now, I've no idea if eMMC behaves like SSD controllers - I'd be surprised if they did - but if the eMMC has to perform more read-modify-writes (ie. increased write amplification) as data is written then either performance drops as the drive becomes more "used" (ie. full) or the lifespan of the drive will be reduced as wear levelling is not as efficient, or both.

[lma]

See also this (http://www.advogato.org/person/dwmw2/diary/211.html) blog entry by the JFFS2 author.

[shadowjk]

Most mmc controllers perform write-modify cycle if you don't write 256kbyte sequentially, or however big the erase block size is on the device. You're looking at huge amounts of write amplification for the normal swap usage :)

Here's a description, it most likely applies to everything that isn't a top-end indilinx or intel SSD:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg170028.html