FAQ entry for loopback mounting
After struggling with loopback mounting jffs2 files for a while, here is a suggestion to update the FAQ entry "I cannot loop mount a JFFS2 image" found at http://www.linux-mtd.infradead.org/faq/jffs2.html
Caveat: I am not a MTD guru, what I document here was learned by trial and error, and coaching by joern, tglx and dwmw2. I hope it is useful and not entirely incorrect ;) Feedback welcome, and if you want a HTML-ized version for the webpage, let me know.
Loopback mounting a JFFS2 image
Currently, it is not possible to mount a JFFS2 image via loopback (eg. "mount -oloop -tjffs2 file.jffs2 /mnt/foo" does not work). There are several close approximations: mtdram and block2mtd. An older method, blkmtd, has recently been deprecated.
METHOD mtdram:
The mtdram method (CONFIG_MTD_MTDRAM in your kernel config, not to be confused with the CONFIG_MTD_RAM option!) creates a MTD device in RAM. You can copy your JFFS2 image there and then mount it, just like you would do with a real MTD device in flash. The only downside is that it eats up a lot of memory (eg. don't try making a 1GiB mtdram device).
# modprobe mtdram total_size=8192 erase_size=128
This creates a MTD device 8MiB big, with an erase size of 128kiB. Note the implied units are kilobytes. Check in /proc/mtd to see the newly-created device (your numbers will vary!)
# cat /proc/mtd dev: size erasesize name mtd0: 00800000 00020000 "mtdram test device"
Now it can be operated like any other MTD device. To "fill" it with your JFFS2 image, just copy that image to /dev/mtd0. Then mount the device somewhere.
# cp file.jffs2 /dev/mtd0 # mount -tjffs2 /dev/mtdblock0 /mnt/foo
The contents are now visible under /mnt/foo.
METHOD block2mtd:
The block2mtd method (CONFIG_MTD_BLOCK2MTD in your kernel config) can be used to transform a block device into an MTD device. Combined with the standard loopback device (CONFIG_BLK_DEV_LOOP), this can be used to "mount" a JFFS2 image without the RAM overhead of the mtdram method.
You must ensure that the JFFS2 image file is padded to a multiple of the block size when using this method, otherwise your filesystem will be truncated to the next-to-last block, and some data will be lost. Note that the mkfs.jffs2 utility has a -p option that will add the padding.
The first step is to create a block device from the image file using the standard loop method.
# modprobe loop (if necessary) # losetup /dev/loop0 /path/to/file.jffs2
Now that we have a block device, it is "made into" a MTD device using block2mtd module:
# modprobe block2mtd block2mtd=/dev/loop0,128ki
Here the "128ki" is the erase block size. Only "ki" is accepted, due to bugs in the parsing code. The code understands "M" and "G" but will barf on subsequent arguments. You cannot add the logical-seeming "B", for example, "128kiB" is not accepted. If you use no letters, then the value is interpreted in BYTES (unlike the mtdram which assumes kiB).
There are additional options that can be passed (comma-separated): "ro" makes the device read-only, and "sync" presumably makes it synchronous.
At this point, a new MTD device is created and can be mounted like any other MTD device.
# cat /proc/mtd dev: size erasesize name mtd0: 00800000 00020000 "block2mtd: /dev/loop0"
# mount -tjffs2 /dev/mtdblock0 /mnt/foo
The contents are now accessible under /mnt/foo. Note there is no need to copy the image file into the mtd device in this case!
Note: there was an "embarrassing typo" in block2mtd in kernel 2.6.12 and earlier, which makes it unusable. It was fixed in 2.6.13 and beyond. And the units parsing problems described above are present in 2.6.16 but will presumably be fixed.
-R
Quoted 5 lines · Ralph Siemsen
Here the "128ki" is the erase block size. Only "ki" is accepted, due to bugs in the parsing code. The code understands "M" and "G" but will barf on subsequent arguments. You cannot add the logical-seeming "B", for example, "128kiB" is not accepted. If you use no letters, then the value is interpreted in BYTES (unlike the mtdram which assumes kiB).
You probably wouldn't want 'M' or 'G' on their own, because those would be multiples of ten, and unlikely to be useful in this context. Making it accept (and ignore) 'B' would perhaps be useful -- patches welcome.
Signature · 1 line
dwmw2
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Ralph Siemsen
I misread the code a bit. "Mi" and "Gi" should in fact work (I didn't try them), having been bitten repeatedly by neither "k" or "kB" working as one might have (naviely) expected. Yes I know the "i" thing is SI standard but the old "be leniant in what you accept" policy really should apply imho.
We _are_ being lenient. If you say 'k' or 'M' instead of 'Ki' or 'Mi' then you are going to get the powers of ten which you asked for... which is almost certainly _not_ what you wanted. Giving you powers of two is not an option. So it's best not to accept it at all.
Signature · 1 line
dwmw2
Quoted 4 lines · David Woodhouse
We _are_ being lenient. If you say 'k' or 'M' instead of 'Ki' or 'Mi' then you are going to get the powers of ten which you asked for... which is almost certainly _not_ what you wanted. Giving you powers of two is not an option. So it's best not to accept it at all.
No, if you give it "k" only, then it multiples by 1024, but because there is no "i", it does not advance *endp, and then parse_num() returns -EINVAL because it sees trailing garbage. So just "k" is not accepted at all, which is not "leniant" in my books.
-R
Quoted 11 lines · Ralph Siemsen
Quoted 4 lines · David Woodhouse
We _are_ being lenient. If you say 'k' or 'M' instead of 'Ki' or 'Mi' then you are going to get the powers of ten which you asked for... which is almost certainly _not_ what you wanted. Giving you powers of two is not an option. So it's best not to accept it at all.
No, if you give it "k" only, then it multiples by 1024, but because there is no "i", it does not advance *endp, and then
parse_num()returns-EINVALbecause it sees trailing garbage. So just "k" is not accepted at all, which is not "leniant" in my books.
Well, we have the following options:
1) accept "k" only, interpret as 1024
2) accept both "k" and "ki", interpret as 1024
3) accept "k" and interpret as 1000, accept "ki" and interpret as 1024
4) accept "ki" only, interpret as 1024
Option 1 is what has been done by every piece of software for years. People are used to it. But it also causes confusion at time. For example, my 40GB hard disk is only 37GiB in size. Hard disk manufacturers _do_ mean 1000*1000*1000 when talking about GB. DRAM manufacturers mean 1024*1024*1024 when talking about GB. GBit ethernet means 1000MBit. 10MBit might mean 10*1024*1024, not sure about that.
Ergo: It is confusing, don't do it.
Option 2 has all the disadvantages of 1.
Ergo: It is confusing, don't do it.
Option 3 will cause many people to expect "k" to be interpreted as 1024, while something completely different happens.
Ergo: It is confusing, don't do it.
Option 4 simply doesn't accept "k". People used to it will have to stop and think, then notice that it is called "ki" now and definitely means 1024, even when talking about hard disks, ethernet, etc.
Ergo: Initial surprise, but after that the interface does what one expects.
I personally don't like solution 4 too much either. But it is much better than the other three. And the "but this is flash, so in this particular case everyone knows it means 1024" argument simply doesn't work. If you look at the FAQ section of your favorite computer magazine, you see the "why is my 40GB hard disk only 37GiB in size" question in it. People don't know when "k" means 1000 and when it means 1024.
If you have a better solution, though, I'm all yours. ;)
Jörn
Signature · 4 lines
I've never met a human being who would want to read 17,000 pages of documentation, and if there was, I'd kill him to get him out of the gene pool. -- Joseph Costello
Quoted 6 lines · Jörn Engel
Well, we have the following options:
1) accept "k" only, interpret as 1024
2) accept both "k" and "ki", interpret as 1024
3) accept "k" and interpret as 1000, accept "ki" and interpret as 1024
4) accept "ki" only, interpret as 1024
It's "Ki" not "ki".
David Vrabel
Signature · 4 lines
David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/
Quoted 1 line · David Vrabel
It's "Ki" not "ki".
Indeed, though this is only a IEC standard and not part of SI. They write "For consistency with the other prefixes for binary multiples, the symbol Ki is used for 2^10 rather than ki."
Of course this only opens the door to even more end-user confusion.
-R
Quoted 7 lines · Ralph Siemsen
Indeed, though this is only a IEC standard and not part of SI. They write "For consistency with the other prefixes for binary multiples, the
symbol Ki is used for 2^10 rather than ki."Of course this only opens the door to even more end-user confusion.
There is no scope for confusion; it is all very simple:
k == 1,000 (one thousand) M == 1,000,000 (one million) G == 1,000,000,000 (one milliard) T == 1,000,000,000,000 (one en_GB billion)
Ki == 1,024 (2^10) Mi == 1,048,576 (2^20) Gi == 1,073,741,824 (2^30) Ti == 1,099,511,627,776 (2^40)
Signature · 1 line
dwmw2
Quoted 2 lines · David Woodhouse
G == 1,000,000,000 (one milliard)
billion
Quoted 1 line
T == 1,000,000,000,000 (one
en_GBbillion)
trillion
The old british terms haven't been in widespread use in the UK for a over a decade (at least).
See official UK government usage of the terms, for example.
David Vrabel
Signature · 4 lines
David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/
Quoting myself:
Quoted 4 lines
METHOD mtdram:
[snip]# cp file.jffs2 /dev/mtd0 # mount -tjffs2 /dev/mtdblock0 /mnt/foo
I'm bored of arguing about suffixes. Let's talk MTD.
When using mtdram device, is it necessary to fill the device with 0xff first? Suppose I make a 8388608 byte mtdram device and then my file.jffs2 is only 6000000 bytes long. Need I fill the rest of the device with 0xff before mounting? Should I fill with zeros (there was an unanswered question on this subject 2005-Dec-14 on the list).
What about if I "reaload", eg. umount the device, and want to copy a new file.jffs2 image into it? Or should the driver be reloaded in this case?
-R