* Re: Does JFFS respect partitions? [not found] <200102150323.TAA01327@concorde.cs.ucla.edu> @ 2001-02-15 10:10 ` David Woodhouse 2001-02-15 11:11 ` Jeremy Elson 0 siblings, 1 reply; 3+ messages in thread From: David Woodhouse @ 2001-02-15 10:10 UTC (permalink / raw) To: Jeremy Elson; +Cc: jffs-dev, mtd 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Does JFFS respect partitions? 2001-02-15 10:10 ` Does JFFS respect partitions? David Woodhouse @ 2001-02-15 11:11 ` Jeremy Elson 2001-02-15 11:41 ` David Woodhouse 0 siblings, 1 reply; 3+ messages in thread From: Jeremy Elson @ 2001-02-15 11:11 UTC (permalink / raw) To: David Woodhouse; +Cc: jffs-dev, mtd 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Does JFFS respect partitions? 2001-02-15 11:11 ` Jeremy Elson @ 2001-02-15 11:41 ` David Woodhouse 0 siblings, 0 replies; 3+ messages in thread From: David Woodhouse @ 2001-02-15 11:41 UTC (permalink / raw) To: Jeremy Elson; +Cc: jffs-dev, mtd 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-02-15 11:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200102150323.TAA01327@concorde.cs.ucla.edu>
2001-02-15 10:10 ` Does JFFS respect partitions? David Woodhouse
2001-02-15 11:11 ` Jeremy Elson
2001-02-15 11:41 ` David Woodhouse
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox