FileSystem microSD cards - Revision history

Glenn: /* Why not jffs2, ubifs of nilfs */ divided to two paragraphs

2011-04-15T08:03:00Z

‎Why not jffs2, ubifs of nilfs: divided to two paragraphs

Glenn: /* Why not jffs2, ubifs of nilfs */ +,

2011-04-15T07:59:07Z

‎Why not jffs2, ubifs of nilfs: +,

Glenn: /* Why not jffs2 or ubifs */ +nilfs

2011-04-15T07:58:53Z

‎Why not jffs2 or ubifs: +nilfs

JOERG: typofix

2011-04-14T17:07:58Z

typofix

Glenn: /* Notes */ spelling

2010-01-07T17:08:19Z

‎Notes: spelling

Glenn: /* Why not jffs2 or ubifs */ +links

2010-01-07T17:07:33Z

‎Why not jffs2 or ubifs: +links

Jonci: /* Create an ext3 partition */ added easier option to look for drive (fdisk)

2009-08-29T15:06:48Z

‎Create an ext3 partition: added easier option to look for drive (fdisk)

Pander: /* Create an ext3 partition */

2009-07-28T23:54:54Z

‎Create an ext3 partition

Pander: /* Create an ext4 partition */

2009-07-28T23:38:27Z

‎Create an ext4 partition

Pander at 23:33, 28 July 2009

2009-07-28T23:33:19Z

@@ Line 46: / Line 46: @@
 # optionally set some permissions: sudo chown username:username and sudo chmod ug+rw .
-= Why not jffs2, ubifs of nilfs =
+= Why not jffs2 or ubifs =
-What about file systems like [[jffs2]], [[ubifs]] and [[nilfs]], which are aware of flash card wearing?
+What about file systems like [[jffs2]] and [[ubifs]], which are aware of flash card wearing?
 SD cards, according to SanDisk specs, should have wear leveling logic, which controls the number of writes and remaps blocks as needed. Wear-aware file systems might actually play against the logic of the card and are usually not recommendable.
 = Notes =

@@ Line 48: / Line 48: @@
 = Why not jffs2, ubifs of nilfs =
-What about file systems like [[jffs2]] [[ubifs]] and [[nilfs]], which are aware of flash card wearing?
+What about file systems like [[jffs2]], [[ubifs]] and [[nilfs]], which are aware of flash card wearing?
 SD cards, according to SanDisk specs, should have wear leveling logic, which controls the number of writes and remaps blocks as needed. Wear-aware file systems might actually play against the logic of the card and are usually not recommendable.

@@ Line 46: / Line 46: @@
 # optionally set some permissions: sudo chown username:username and sudo chmod ug+rw .
-= Why not jffs2 or ubifs =
+= Why not jffs2, ubifs of nilfs =
-What about file systems like [[jffs2]] and [[ubifs]], which are aware of flash card wearing?
+What about file systems like [[jffs2]] [[ubifs]] and [[nilfs]], which are aware of flash card wearing?
 SD cards, according to SanDisk specs, should have wear leveling logic, which controls the number of writes and remaps blocks as needed. Wear-aware file systems might actually play against the logic of the card and are usually not recommendable.

@@ Line 16: / Line 16: @@
 Long answer:
-In principle you can use any file system (fs) that is supported by the kernel in your Open Moko, commonly FAT, ext2, and ext3. reiserfs is currently not available in the standard OM kernel. What sets ext3 apart from FAT and ext2 is the journaling (also in reiserfs).
+In principle you can use any file system (fs) that is supported by the kernel in your Openmoko, commonly FAT, ext2, and ext3. reiserfs is currently not available in the standard OM kernel. What sets ext3 apart from FAT and ext2 is the journaling (also in reiserfs).
 The journal is an extra data structure used to make sure that the file system is always in a consistent state. Typically, if a crash happens in the system, the file system might get corrupted and even become unusable. In simple terms, the fs first saves all the data needed to perform the operation in the journal and only then starts updating the file system. If something goes wrong, the fs can rely on the journal to safely repeat the operation and repair the file system. Without a journal, the operation will certainly be lost and it might not even be possible to fix the file system.
@@ Line 29: / Line 29: @@
 Regarding performance, if you are using the SD mostly for static storage like maps or music files, it should not be a big problem. After the initial storage phase, the reads won't be delayed by the journal. Have also a look at [http://www.debian-administration.org/articles/388 this benchmark] between several Linux file systems.
-Regarding the extra wearing, the number of write accesses before wearing seem to be sufficiently high not to have to bother with it, and the SD card in itself as automatic wearing leveling which will ensure that the journal will be written in another place after some time. All in all, sd card damage due to the journal should not be a practical issue.
+Regarding the extra wearing, the number of write accesses before wearing seem to be sufficiently high not to have to bother with it, and the SD card in itself has automatic wearing leveling which will ensure that the journal will be written in another place after some time. All in all, sd card damage due to the journal should not be a practical issue.
 FAT might already be the fs in your card when you got a new one. It has the advantage of being recognised in many other systems. The data structures are simpler which might mean less writes on the sd-card and less code being executed (unverified) and you'll find more tools available to recover information when you get errors.
@@ Line 44: / Line 44: @@
 # disable automated file system checks: sudo tune2fs -c 0 -i 0 /dev/xyz
 # mount the device: mount/dev/xyz or simply eject and re-insert it
-# optinally set some permissions: sudo chown username:username and sudo chmod ug+rw .
+# optionally set some permissions: sudo chown username:username and sudo chmod ug+rw .
 = Why not jffs2 or ubifs =

@@ Line 54: / Line 54: @@
 = Notes =
-Note 1: this page is mostly based on feedback from the OpenMoko community list: see [http://lists.openmoko.org/pipermail/community/2009-January/040521.html here] and [http://lists.openmoko.org/pipermail/community/2009-February/041072.html here].
+Note 1: this page is mostly based on feedback from the Openmoko community list: see [http://lists.openmoko.org/pipermail/community/2009-January/040521.html here] and [http://lists.openmoko.org/pipermail/community/2009-February/041072.html here].
-Note 2: file systems are quite complex components of an operating system, each one with different weak and strong points, which makes it difficult to give a definitive answer to tell which file system is the best. As you can see from the mailing list posts, you'll find people vouching for any of these three options. Furthermore, although the mentioned are well-known, there are actually not yet benchmarks specific to the Open Moko architecture in combination with microSD cards, of which there are many models around.
+Note 2: file systems are quite complex components of an operating system, each one with different weak and strong points, which makes it difficult to give a definitive answer to tell which file system is the best. As you can see from the mailing list posts, you'll find people vouching for any of these three options. Furthermore, although the mentioned are well-known, there are actually not yet benchmarks specific to the Openmoko architecture in combination with microSD cards, of which there are many models around.

@@ Line 37: / Line 37: @@
 == Create an ext3 partition ==
 # put new purchased device in laptop or desktop
-# see which device it is via: mount (usually look for /media/disk)
+# see which device it is via: mount (usually look for /media/disk) or look out for it in sudo fdisk -l
 # run: sudo fdisk /dev/xyz
 # create new partition table with 'n' (all default will result in Linux, type 83), save and exit with 'w'
@@ Line 44: / Line 44: @@
 # disable automated file system checks: sudo tune2fs -c 0 -i 0 /dev/xyz
 # mount the device: mount/dev/xyz or simply eject and re-insert it
-# optinally set some permissions: sudo chown username.username .;sudo chmod ug+rw .
+# optinally set some permissions: sudo chown username:username and sudo chmod ug+rw .
 = Why not jffs2 or ubifs =

@@ Line 38: / Line 38: @@
 # put new purchased device in laptop or desktop
 # see which device it is via: mount (usually look for /media/disk)
-# run: fdisk /dev/xyz
+# run: sudo fdisk /dev/xyz
-# create new partition table (Linux, type 83), save and exit
+# create new partition table with 'n' (all default will result in Linux, type 83), save and exit with 'w'
-# unmoun tdevice: umount /dev/xyz
+# unmount device: sudo umount /dev/xyz
-# create new file system: mkfs.ext3 /dev/xyz
+# create new ext3 file system: sudo mkfs.ext3 /dev/xyz
-# disable automated file system checks: tune2fs -c 0 -i 0 /dev/xyz
+# disable automated file system checks: sudo tune2fs -c 0 -i 0 /dev/xyz
 = Why not jffs2 or ubifs =

@@ Line 35: / Line 35: @@
 It is also important to note that ext is faster than FAT (benchmark, anyone?) but, most importantly, it supports owner/group concept and permissions, which FAT doesn't. Of course, since FR is in general a single user device, the permissions might be not so important. Another advantage of ext2/3 is support for hard/soft links, which is typically useful to avoid redundant copies of files. For instance, if you are storing maps and you have blank tiles files, you can keep a single blank file and have all the others be just a link to this one (you would need a script for that to make it practical)
-== Create an ext4 partition ==
+== Create an ext3 partition ==
-* put new purchased device in laptop or desktop
+# put new purchased device in laptop or desktop
-* see which device it is via: mount
+# see which device it is via: mount (usually look for /media/disk)
-* run: fdisk /dev/xyz
+# run: fdisk /dev/xyz
-* create new partition table (Linux, type 83), save and exit
+# create new partition table (Linux, type 83), save and exit
-* create new filesystem (unmount first): mkfs.ext4 /dev/xyz
+# unmoun tdevice: umount /dev/xyz
-* disable automated filesystem checks: tune2fs -c 0 -i 0 /dev/xyz
+# create new file system: mkfs.ext3 /dev/xyz
 = Why not jffs2 or ubifs =

← Older revision		Revision as of 23:33, 28 July 2009
Line 34:		Line 34:

	It is also important to note that ext is faster than FAT (benchmark, anyone?) but, most importantly, it supports owner/group concept and permissions, which FAT doesn't. Of course, since FR is in general a single user device, the permissions might be not so important. Another advantage of ext2/3 is support for hard/soft links, which is typically useful to avoid redundant copies of files. For instance, if you are storing maps and you have blank tiles files, you can keep a single blank file and have all the others be just a link to this one (you would need a script for that to make it practical)		It is also important to note that ext is faster than FAT (benchmark, anyone?) but, most importantly, it supports owner/group concept and permissions, which FAT doesn't. Of course, since FR is in general a single user device, the permissions might be not so important. Another advantage of ext2/3 is support for hard/soft links, which is typically useful to avoid redundant copies of files. For instance, if you are storing maps and you have blank tiles files, you can keep a single blank file and have all the others be just a link to this one (you would need a script for that to make it practical)
		+
		+	== Create an ext4 partition ==
		+	* put new purchased device in laptop or desktop
		+	* see which device it is via: mount
		+	* run: fdisk /dev/xyz
		+	* create new partition table (Linux, type 83), save and exit
		+	* create new filesystem (unmount first): mkfs.ext4 /dev/xyz
		+	* disable automated filesystem checks: tune2fs -c 0 -i 0 /dev/xyz

	= Why not jffs2 or ubifs =		= Why not jffs2 or ubifs =