FAQ entry for loopback mounting

FAQ entry for loopback mounting

[Ralph Siemsen]

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

Re: FAQ entry for loopback mounting

[David Woodhouse]

On Wed, 2006-04-05 at 12:00 -0400, Ralph Siemsen wrote:
> 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.

-- 
dwmw2

Re: FAQ entry for loopback mounting

[David Woodhouse]

On Wed, 2006-04-05 at 13:10 -0400, Ralph Siemsen wrote:
> 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.

-- 
dwmw2

Re: FAQ entry for loopback mounting

[Ralph Siemsen]

David Woodhouse wrote:

> 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

Re: FAQ entry for loopback mounting

[Jörn Engel]

On Wed, 5 April 2006 13:36:56 -0400, Ralph Siemsen wrote:
> David Woodhouse wrote:
> 
> >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.

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

-- 
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

Re: FAQ entry for loopback mounting

[David Vrabel]

Jörn Engel wrote:
> 
> 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
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: FAQ entry for loopback mounting

[Ralph Siemsen]

David Vrabel wrote:

> 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

Re: FAQ entry for loopback mounting

[David Woodhouse]

On Thu, 2006-04-06 at 08:04 -0400, Ralph Siemsen wrote:
> 
> 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)

-- 
dwmw2

Re: FAQ entry for loopback mounting

[David Vrabel]

David Woodhouse wrote:
> 
> G == 1,000,000,000        (one milliard)

billion

> T == 1,000,000,000,000    (one en_GB billion)

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
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: FAQ entry for loopback mounting

[Ralph Siemsen]

Quoting myself:

> 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