Does JFFS respect partitions?

[David Woodhouse]

jelson at isi.edu said:
>  I am trying to get JFFS to run on one of 2 partitions on a DOC2000. I
> ran fdisk on /dev/nftl/disc0/disc (in devfs-parlance; equivalant to /
> dev/nftla I think; it's major 93 minor 0).  Using fdisk I was able to
> create 2 partitions, /dev/nftl/disc/part[34], and successfully created
> an ext2 partition in part3.  Now, I want to use JFFS on part4.  But,
> it seems that JFFS only wants to talk to the raw block device (/dev/
> mtdblock/0), not the partitioned block device.

> I need to do this because I need one bootable readonly partition (ext2
> works fine, I'll probably use cramfs eventually if the bootloader
> supports it).  The 2nd partition needs to be writable, and therefore
> wear-levelled, so I want to use JFFS.  But JFFS doesn't want to play
> along :-).

> The design of the system demands 2 partitions: one of which is
> guaranteed to never be corrupted (the readonly partition), and a
> writable but disposable partition, so unfortunately using JFFS for the
> entire block device is not an option. 

Don't do that.

The DiskOnChip is a clever ASIC and a handful of NAND flash chips. It's 
shipped with a pseudo-filesystem on it which emulates a block device, 
called NFTL (NAND Flash Translation Layer). The sectors in your emulated 
block device may end up anywhere on the physical flash, as you'd expect 
from a filesystem.

On top of that emulated block device, you put your normal partition table 
and filesystems. 

Having a read-only partition on the _emulated_ block device doesn't help. 
The blocks of that partition will still be shifted around to perform 
wear-levelling while you write to the other partition. If the NFTL 
filesystem gets corrupted (note the BETA in capital letters in the 
CONFIG_NFTL_RW config option), you've still lost your read-only filesystem.

Note that you _could_ in theory have two NFTL 'filesystems' on the same 
DiskOnChip - giving you two separate block devices nftla and nftlb. The 
NFTL write code is slightly suspect ATM, but I don't expect it to be so 
screwed that it writes to the flash _outside_ its own space. You don't 
bother partitioning them - use the whole device for the filesystem. Mount 
one of them read-only and mount the other read-write.

It's also possible to register the DiskOnChip raw flash as two separate MTD 
devices, which is how we 'partition' normal flash. Then you let the NFTL 
code put a filesystem on one of them and use JFFS on the other. 

jelson at isi.edu said:
>  Will there be any ill effects if I just remove the check in JFFS for
> MTD_BLOCK_MAJOR?

It cannot work on a block device (at the moment); only on a real flash
device. The only thing it does with the block device it's passed is use the
minor number to lookup an MTD device.

> Also, what's jffs2?  Is it safe to use that, and how is it different? 

Pay no attention to the man behind the curtain. The garbage collect code,
and half of the code to scan the filesystem on mount, are absent presumed 
not written yet. But if you mount an empty filesystem, it seems to work 
fine until the log gets to the end of the first pass of the flash. :)

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org