journalled fs on partitioned flash

journalled fs on partitioned flash

[Peter Kundrat]

Greetings,

My idea to configure the embedded i386 box with Doc Millenium flash
was to create 2 partitions, with one partition beeing used for cfg
data and the second for cramfs. When trying jffs, i found that it 
required mtdblock to be mounted on. With this requirement i dont see
any other way how to get my desired setup with partitioned flash
(except for ext3 on ntfl, but that doesnt seem to be ported to 2.4 
(i havent checked latest status)).

So it seems i have to use compressed loop over jffs on mtdblock.
Does anybody have such a config working ?

When i tried to dd if=rootfs.jffs of=/dev/mtdblock/0 i got
end_request: I/O error, dev 1f:00 (mtdblock) sector 0 
end_request: I/O error, dev 1f:00 (mtdblock) sector 254
etc. every 254 blocks
and dd hung in D state (__wait_on_buffer+0x4c)

Is it a known problem ? Does any have cloop working on 2.4 (on
first try the compilation choked .. i'll have a closer look
whether it was my fault or not).

	Thanks for any advice,

		Peter



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

Re: journalled fs on partitioned flash

[David Woodhouse]

On Wed, 27 Sep 2000, Peter Kundrat wrote:

> When i tried to dd if=rootfs.jffs of=/dev/mtdblock/0 i got
> end_request: I/O error, dev 1f:00 (mtdblock) sector 0 
> end_request: I/O error, dev 1f:00 (mtdblock) sector 254
> etc. every 254 blocks
> and dd hung in D state (__wait_on_buffer+0x4c)
> 
> Is it a known problem ? 

Yep. The mtdblock device doesn't actually work, and it's used by JFFS
_only_ to get a handle on the underlying MTD device. Use the character
device to put your initial image on there instead.

I'm not sure how effective cloop on JFFS will be - if it's just
compression you're after, you'd probably be better off implementing
compression in JFFS - it's not too hard.

And JFFS doesn't work on the DiskOnChip yet, because the DiskOnChip uses
NAND flash. See sjhill's TODO list.

-- 
dwmw2




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

Re: journalled fs on partitioned flash

[David Given]

[...]
>Yep. The mtdblock device doesn't actually work, and it's used by JFFS
>_only_ to get a handle on the underlying MTD device. Use the character
>device to put your initial image on there instead.

It worked all right when I was playing with it. Admittedly, I wasn't doing any 
real work.

>I'm not sure how effective cloop on JFFS will be - if it's just
>compression you're after, you'd probably be better off implementing
>compression in JFFS - it's not too hard.

I'm using a cramfs FS image in a jffs partition. It works fine, although I get 
a few access-beyond-end-of-device errors when it gets mounted.

Do I take it that I can't burn a cramfs image into a raw partition, and then

mount /mnt /dev/mtdblock/1 -t cramfs

...?

-- 
David Given
dg@tao-group.com




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

Re: journalled fs on partitioned flash

[David Woodhouse]

dwmw2@infradead.org said:
>  The mtdblock device doesn't actually work

dg@tao-group.com said:
>  Do I take it that I can't burn a cramfs image into a raw partition,
> and then mount /mnt /dev/mtdblock/1 -t cramfs 

s/doesn't actually work/work reliably/

YMMV - if you're using it read-only and never writing to any other parts of 
the same flash chips, you ought to be fine. If it ever has to 
sleep in the request function, boom.


--
dwmw2




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

small nftl fix

[Peter Kundrat]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

Greetings,

When writing to an empty fs on nftl, I always got garbled partition table.
Looking at the nftl.c, there seems to be a problem with overwriting media header
(which seems to be at the FirstPhysicalEUN). 

So the patch simply skips first two units (i'd like to know if magic constant 2 
is fine (i got it from nftl_format.c)).

Except for that there is a smal fix for LEVEL3 debug eliminating the dump of
"unrecognised partitions" (it was not very syslog friendly anyways).

Last part is about setting LastFreeEUN after the scanning loop .. which didnt
make sense to me .. (it is not correct before the loop either - for the
case of no empty blocks, but seems better :).
Anyways its quite late now, so i may have missed something.

Another problem is the fact, that VirtualUnitTable and ReplUnitTable are
allocated for NumEraseUnits, but are indexed with absolute EUN numbers .. 

Also WriteInh seems to be set to 0x1 on all my units (formatted by m-sys utils),
but the code checks for 0xffffffff .. is that value in specification ?


	Thats for tonight, more later,

		pkx

PS: is it possible to obtain specifications for DOC devices resp. nftl layout ?

[-- Attachment #2: first-eun-pkx.patch --]
[-- Type: text/plain, Size: 2804 bytes --]

--- nftl.c.orig	Sun Oct  1 11:52:19 2000
+++ nftl.c	Wed Oct  4 03:46:17 2000
@@ -237,10 +237,11 @@
 	nftl->lastEUN = le16_to_cpu(nftl->MediaHdr.NumEraseUnits) +
 		le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN) - 1;
 	nftl->numfreeEUNs = 0;
+	nftl->LastFreeEUN = le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN)+2;
 
 	/* Scan each physical Erase Unit for validity and to find the 
 	   Virtual Erase Unit Chain to which it belongs */
-	for (i = le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN); i <= nftl->lastEUN; i++) {
+	for (i = le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN)+2; i <= nftl->lastEUN; i++) {
 		union nftl_uci uci;
 		unsigned long ofs;
 		size_t retlen;
@@ -277,6 +278,10 @@
 		nftl->VirtualUnitTable[i] = le16_to_cpu(uci.a.VirtUnitNum);
 		nftl->ReplUnitTable[i] = le16_to_cpu(uci.a.ReplUnitNum);
 
+		if (nftl->ReplUnitTable[i] < le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN)+2) 
+			printk(KERN_WARNING "EUN %d: is replaced by HDR EUN (%x)\n", i,
+			       le16_to_cpu(uci.a.ReplUnitNum));
+
 		/* if (!(VUN & 0x8000) && VUN < (arraybounds)).. optimises to: */
 		if (le16_to_cpu(uci.a.VirtUnitNum) < nftl->numvunits) 
 			nftl->EUNtable[le16_to_cpu(uci.a.VirtUnitNum) & 0x7fff] = i;
@@ -288,7 +293,6 @@
 		}
 	} 
 	NFTLs[firstfree] = nftl;
-	nftl->LastFreeEUN = le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN);
 
 #ifdef PSYCHO_DEBUG
 	for (i=0; i < 10/* nftl->numvunits*/; i++) {
@@ -377,17 +381,24 @@
 			}
 			if (!strncmp(hdr.DataOrgID, "ANAND", 6)) {
 				DEBUG(MTD_DEBUG_LEVEL2, "Valid NFTL partition at ofs 0x%lx\n", ofs);	
+				DEBUG(MTD_DEBUG_LEVEL2,"Erase Units: %d, FirstPhysicalEUN: %d, FormattedSize: %d, UnitSizeFactor: 0x%0x\n",
+				      hdr.NumEraseUnits, hdr.FirstPhysicalEUN,
+				      hdr.FormattedSize, hdr.UnitSizeFactor);
 				NFTL_setup(mtd, ofs, &hdr);
-			} else {
-				DEBUG(MTD_DEBUG_LEVEL3,"No valid NFTL Partition at ofs 0x%lx\n", ofs);
-				for (i = 0; i < 6; i++) {
-				    DEBUG(MTD_DEBUG_LEVEL3,"%x, ", hdr.DataOrgID[i]);
-				}
+			} /* else {
+				DEBUG(MTD_DEBUG_LEVEL3,
+				      "No valid NFTL Partition at ofs 0x%lx"
+				      ", DataOrgId %02.2x,%02.2x,%02.2x,%02.2x,%02.2x,%02.2x (%6.6s)\n",
+				      ofs, hdr.DataOrgID[0], hdr.DataOrgID[1], hdr.DataOrgID[2], 
+				           hdr.DataOrgID[4], hdr.DataOrgID[5], hdr.DataOrgID[6],
+					   hdr.DataOrgID);
+
 				DEBUG(MTD_DEBUG_LEVEL3," = %s\n", hdr.DataOrgID);
 				DEBUG(MTD_DEBUG_LEVEL3,"%d, %d, %d, %d\n",
 				      hdr.NumEraseUnits, hdr.FirstPhysicalEUN,
 				      hdr.FormattedSize, hdr.UnitSizeFactor);
 			}
+				*/
 		}
 		return;
 	}
@@ -430,7 +441,7 @@
 		}
 
 		if (++pot > nftl->lastEUN)
-			pot = le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN);
+			pot = le16_to_cpu(nftl->MediaHdr.FirstPhysicalEUN)+2;
 
 		if (!silly--) {
 			printk("Tell Dave he fucked up. LastFreeEUN = %d, "

Re: small nftl fix

[David Woodhouse]

kundrat@pkx.sk said:
> When writing to an empty fs on nftl, I always got garbled partition
> table. Looking at the nftl.c, there seems to be a problem with
> overwriting media header (which seems to be at the FirstPhysicalEUN).
> 

Sorry for the delayed response. Your patch looks good. However, I believe 
the spec allows the header units to be in places other than the first two 
physical units of the NFTL, so it would be better to make sure we don't use 
(EUN == nftl->MediaUnit || EUN == nftl->SpareMediaUnit) rather than 
hardcoding that to not use (EUN < nftl->MediaHdr.FirstPhysicalEUN + 2)

In practice, I don't really expect that to happen, but we might as well be 
pedantic in our adherence to the NFTL spec. 

In the meantime, could anyone else who's seen NFTL corruption please try 
Peter's patch?

--
dwmw2




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

Re: journalled fs on partitioned flash

[Peter Kundrat]

On Wed, Sep 27, 2000 at 10:17:57AM +0100, David Woodhouse wrote:
> I'm not sure how effective cloop on JFFS will be - if it's just
> compression you're after, you'd probably be better off implementing
> compression in JFFS - it's not too hard.

Unfortunately time constraints for the project dont allow me to hack jffs now.

I'd prefer to have one r/o partition with cramfs (mounted on /usr) to be able 
to upload the whole filesystem at once even on on the running box. 
Compressed jffs case also would be a bit more difficult to update live.
Even if i had JFFS working, more viable option would be to use partitioned mtd
a'la pnc2000.c.

Not having ext3 for 2.4 leaves me with the option of either using reiserfs
or ext2/minix and living with fsck.


	Regards

		pkx



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