mtd2block should not expand sparse loopback files

[Johannes Niess]

Hi list,

Thank you all for providing mtd and jffs2. I'm using it a little bit different 
than intended and it looks like the crash recovery feature is causing me 
trouble. I'm trying to save disk space on my gentoo installation for an old 
notebook. AFAIK jffs2 is  the only way to provide transparent read and write 
access with compression. Other FS can be used with sparse loopback files and 
do not occupy disk space for unused blocks ("Over commiting disk space" 
becomes feasible). I want to combine the features, e. g. to 
store /usr/portage in a sparse loopback file formated with jffs2.

I tried this:

# make1G sparse loop file, taking 1M real disk space
dd if=/dev/null of=sparse.jffs2 bs=1M count=1000 seek=1000
# mount it as loop device
losetup /dev/loop/0 sparse.jffs2
# make a jffs2 file system on it
mkfs.jffs2 -o /dev/loop/0 -d /emptydir
# convert it into a mtd
modprobe block2mtd block2mtd=/dev/loop/0
# mount the mtd device
mount -t jffs2 /dev/mtdblock0 /mnt/somewhere

The jffs2 is readable and writable as expected. BUT upon first mount a couple 
of pdflush (pseudo kernel) processes become active and completely expand the 
sparse loopback file. Only after that disk activity has settled, "ls" and 
"du" give identical numbers of 1GB. Before mounting "ls" gives the maximum 
size and "du" just counts occupied sectors, e. g. "ls" gives 1 GB and "du" 
only 1 MB.

"od -h sparse.jffs2|less" gives a repeating pattern after mount:

*
617750000 1985 2003 000c 0000 b0b1 e41e ffff ffff
617750020 ffff ffff ffff ffff ffff ffff ffff ffff
*
617760000 1985 2003 000c 0000 b0b1 e41e ffff ffff
617760020 ffff ffff ffff ffff ffff ffff ffff ffff
*

I guess that the "fill with 1's" flash strategy is taking its toll together 
with the "Clean" markers. Can I switch that off? Using
"mkfs.jffs2 --no-cleanmarkers"  does not help, as does  --eraseblock=0.

block2mtd should not touch unused blocks at all in this setup. They should 
only be written to on first use for storing real data.

Please make transparent compression AND loop file expansion on demand 
possible. Thank you very much for your work!

Johannes Nieß
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060527/38cf35c5/attachment.bin