Re: Does JFFS respect partitions?

Re: Does JFFS respect partitions?

[David Woodhouse]

jelson@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@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@infradead.org

Re: Does JFFS respect partitions?

[Jeremy Elson]

David Woodhouse writes:
>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.

Interesting - I didn't realize the DOC did internal wear-levelling.  I
guess that might mean that there's no point in using JFFS on top of
the NTFL layer anyway?

I appreciate your advice and knowing that readonly partitions are not,
in reality, readonly from the point of view of the actual flash
blocks.  Our original (non-Linux) system was split into two partitions
to prevent against corruption of the OS filesystem - we didn't want
the readonly boot partition to stop working due to, say, a poweroff in
the middle of a write to a log file on the writable partition.  I
guess I was assuming that, underneath, writes to the DOC sectors were
more or less atomic, and that corruption on that level was much more
unlikely.  I was more worried about a long-lived write failing,
e.g. 30 seconds worth of buffer cache in the OS not being flushed
before a poweroff.

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

This sounds ideal - how does one do this?

>> Also, what's jffs2?  Is it safe to use that, and how is it different? 
>
>Pay no attention to the man behind the curtain.

I don't know the intricacies of the existing jffs2 code or what's left
to implement, but, will a broomstick speed things up for you?  :-)

-Jer


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

Re: Does JFFS respect partitions?

[David Woodhouse]

jelson@ISI.EDU said:
>  Interesting - I didn't realize the DOC did internal wear-levelling.

The DiskOnChip doesn't. It's just a bunch of flash chips with a clever ASIC 
to multiplex them and do some ECC in hardware.

The NFTL psuedo-filesystem does. In software. 

> I guess that might mean that there's no point in using JFFS on top of
> the NTFL layer anyway?

True.


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

> This sounds ideal - how does one do this?

You need to get your hands dirty. See the 'add_mtd_partitions' code in 
mtdpart.c and some of the drivers which call it - basically you have an 
underlying MTD device (the DiskOnChip) and you define two dummy devices 
which just add an offset to the address requested and pass through to the 
'real' device's methods. 

It's probably better to take the other route I suggested - have two NFTL
partitions on the DiskOnChip. Clever offset/len args to nftl_format will do
that. The NFTL code ought to be OK with it, and it shouldn't be difficult to
fix if it isn't.

> I don't know the intricacies of the existing jffs2 code or what's left
> to implement, but, will a broomstick speed things up for you?  :-)

Heh - maybe. But stupid quantities of caffeine seem to be working OK at the 
moment.

--
dwmw2




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