* [PATCH]erase block header(revision 2)
@ 2005-09-26 8:18 zhao forrest
2005-09-26 8:41 ` Jörn Engel
0 siblings, 1 reply; 5+ messages in thread
From: zhao forrest @ 2005-09-26 8:18 UTC (permalink / raw)
To: dedekind, joern, havasi; +Cc: linux-mtd
Hi,
This is second revision of erase block header patch.
Compared with revision 1, the following changes are made:
1 totally remove JFFS2_NODETYPE_DIRENT_EBH and
JFFS2_NODETYPE_INODE_EBH stuff
2 change the node type from JFFS2_FEATURE_INCOMPAT to
JFFS2_FEATURE_RWCOMPAT_DELETE
3 replace 4 with sizeof(uint32_t) in summary.c
The patch is at
http://www.infradead.org/~forrest/eraseblock_header_r2.patch
Thanks,
Forrest
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH]erase block header(revision 2)
2005-09-26 8:18 [PATCH]erase block header(revision 2) zhao forrest
@ 2005-09-26 8:41 ` Jörn Engel
2005-09-26 11:05 ` Artem B. Bityutskiy
0 siblings, 1 reply; 5+ messages in thread
From: Jörn Engel @ 2005-09-26 8:41 UTC (permalink / raw)
To: zhao forrest; +Cc: dedekind, linux-mtd
On Mon, 26 September 2005 16:18:15 +0800, zhao forrest wrote:
>
> This is second revision of erase block header patch.
> Compared with revision 1, the following changes are made:
> 1 totally remove JFFS2_NODETYPE_DIRENT_EBH and
> JFFS2_NODETYPE_INODE_EBH stuff
> 2 change the node type from JFFS2_FEATURE_INCOMPAT to
> JFFS2_FEATURE_RWCOMPAT_DELETE
> 3 replace 4 with sizeof(uint32_t) in summary.c
>
> The patch is at
> http://www.infradead.org/~forrest/eraseblock_header_r2.patch
Didn't read it all.
> diff -auNrp ./mtd/fs/jffs2/build.c ./mtd_EBH_EBS/fs/jffs2/build.c
> --- ./mtd/fs/jffs2/build.c 2005-09-22 11:08:47.000000000 +0800
> +++ ./mtd_EBH_EBS/fs/jffs2/build.c 2005-09-23 14:19:42.000000000 +0800
> @@ -331,6 +331,8 @@ int jffs2_do_mount_fs(struct jffs2_sb_in
> c->blocks[i].first_node = NULL;
> c->blocks[i].last_node = NULL;
> c->blocks[i].bad_count = 0;
> + c->blocks[i].has_ebh = 0;
> + c->blocks[i].erase_count = 0;
> }
>
> INIT_LIST_HEAD(&c->clean_list);
> diff -auNrp ./mtd/fs/jffs2/erase.c ./mtd_EBH_EBS/fs/jffs2/erase.c
> --- ./mtd/fs/jffs2/erase.c 2005-09-22 11:08:47.000000000 +0800
> +++ ./mtd_EBH_EBS/fs/jffs2/erase.c 2005-09-23 14:31:42.000000000 +0800
> @@ -210,6 +210,10 @@ static void jffs2_erase_callback(struct
> } else {
> jffs2_erase_succeeded(priv->c, priv->jeb);
> }
> +
> + if (!priv->jeb->has_ebh) {
> + priv->jeb->has_ebh = 1;
> + }
priv->jeb->has_ebh = 1;
> kfree(instr);
> }
> #endif /* !__ECOS */
> @@ -362,16 +366,14 @@ static void jffs2_mark_erased_block(stru
> }
>
> /* Write the erase complete marker */
> - D1(printk(KERN_DEBUG "Writing erased marker to block at 0x%08x\n", jeb->offset));
> + D1(printk(KERN_DEBUG "Writing eraseblock header to block at 0x%08x\n", jeb->offset));
> bad_offset = jeb->offset;
>
> /* Cleanmarker in oob area or no cleanmarker at all ? */
> - if (jffs2_cleanmarker_oob(c) || c->cleanmarker_size == 0) {
> + if (jffs2_cleanmarker_oob(c)) {
>
> - if (jffs2_cleanmarker_oob(c)) {
> - if (jffs2_write_nand_cleanmarker(c, jeb))
> - goto filebad;
> - }
> + if (jffs2_write_nand_ebh(c, jeb))
> + goto filebad;
>
> jeb->first_node = jeb->last_node = NULL;
> jeb->free_size = c->sector_size;
> @@ -382,10 +384,17 @@ static void jffs2_mark_erased_block(stru
> } else {
>
> struct kvec vecs[1];
> - struct jffs2_unknown_node marker = {
> + struct jffs2_eraseblock_header marker = {
> .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK),
> - .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER),
> - .totlen = cpu_to_je32(c->cleanmarker_size)
> + .nodetype = cpu_to_je16(JFFS2_NODETYPE_ERASEBLOCK_HEADER),
> + .totlen = cpu_to_je32(PAD(c->ebh_size)),
> + .fs_version = JFFS2_VERSION,
> + .compat_fset = JFFS2_EBH_COMPAT_FSET,
> + .incompat_fset = JFFS2_EBH_INCOMPAT_FSET,
> + .rocompat_fset = JFFS2_EBH_ROCOMPAT_FSET,
> + .erase_count = cpu_to_je32(jeb->erase_count),
> + .dsize = cpu_to_je16(0),
> + .data_crc = cpu_to_je32(0)
> };
>
> marker_ref = jffs2_alloc_raw_node_ref();
> @@ -395,6 +404,7 @@ static void jffs2_mark_erased_block(stru
> }
>
> marker.hdr_crc = cpu_to_je32(crc32(0, &marker, sizeof(struct jffs2_unknown_node)-4));
> + marker.node_crc = cpu_to_je32(crc32(0, &marker, sizeof(struct jffs2_eraseblock_header)-8));
>
> vecs[0].iov_base = (unsigned char *) ▮
> vecs[0].iov_len = sizeof(marker);
> @@ -415,12 +425,12 @@ static void jffs2_mark_erased_block(stru
> marker_ref->next_in_ino = NULL;
> marker_ref->next_phys = NULL;
> marker_ref->flash_offset = jeb->offset | REF_NORMAL;
> - marker_ref->__totlen = c->cleanmarker_size;
> + marker_ref->__totlen = PAD(c->ebh_size);
>
> jeb->first_node = jeb->last_node = marker_ref;
>
> - jeb->free_size = c->sector_size - c->cleanmarker_size;
> - jeb->used_size = c->cleanmarker_size;
> + jeb->free_size = c->sector_size - PAD(c->ebh_size);
> + jeb->used_size = PAD(c->ebh_size);
> jeb->dirty_size = 0;
> jeb->wasted_size = 0;
> }
> diff -auNrp ./mtd/fs/jffs2/fs.c ./mtd_EBH_EBS/fs/jffs2/fs.c
> --- ./mtd/fs/jffs2/fs.c 2005-09-22 11:08:47.000000000 +0800
> +++ ./mtd_EBH_EBS/fs/jffs2/fs.c 2005-09-26 15:34:54.000000000 +0800
> @@ -476,6 +476,7 @@ int jffs2_do_fill_super(struct super_blo
> }
>
> c->cleanmarker_size = sizeof(struct jffs2_unknown_node);
> + c->ebh_size = sizeof(struct jffs2_eraseblock_header);
If you add the padding here, you don't need it everywhere else.
> /* Joern -- stick alignment for weird 8-byte-page flash here */
>
> /* NAND (or other bizarre) flash... do setup accordingly */
> diff -auNrp ./mtd/fs/jffs2/nodelist.h ./mtd_EBH_EBS/fs/jffs2/nodelist.h
> --- ./mtd/fs/jffs2/nodelist.h 2005-09-22 11:08:47.000000000 +0800
> +++ ./mtd_EBH_EBS/fs/jffs2/nodelist.h 2005-09-23 14:25:36.000000000 +0800
> @@ -196,6 +196,9 @@ struct jffs2_eraseblock
> struct jffs2_raw_node_ref *last_node;
>
> struct jffs2_raw_node_ref *gc_node; /* Next node to be garbage collected */
> +
> + uint8_t has_ebh;
This breaks your alignment. You really need to get that into your
head. Gcc will allocate a u32 for this field anyway - no matter how
small you make it. It needs the extra room for alignment of the next
field.
> + uint32_t erase_count;
> };
Jörn
--
Don't patch bad code, rewrite it.
-- Kernigham and Pike, according to Rusty
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH]erase block header(revision 2)
2005-09-26 8:41 ` Jörn Engel
@ 2005-09-26 11:05 ` Artem B. Bityutskiy
2005-09-27 7:17 ` zhao forrest
0 siblings, 1 reply; 5+ messages in thread
From: Artem B. Bityutskiy @ 2005-09-26 11:05 UTC (permalink / raw)
To: zhao forrest; +Cc: linux-mtd
Also did not review carefully, just nodes.
.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK),
- .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER),
- .totlen = cpu_to_je32(c->cleanmarker_size)
+ .nodetype = cpu_to_je16(JFFS2_NODETYPE_ERASEBLOCK_HEADER),
+ .totlen = cpu_to_je32(PAD(c->ebh_size)),
---------------------------------------------------
As we discussed, we should store real EBH node size it .totlen, not the
EBH size + paddings to the end of page, etc. Please, store the EBH size
on flash in c->ebg_size, no problems, but let 'totlen' have the same
semantica as all other nodes.
marker_ref->next_in_ino = NULL;
marker_ref->next_phys = NULL;
marker_ref->flash_offset = jeb->offset | REF_NORMAL;
- marker_ref->__totlen = c->cleanmarker_size;
+ marker_ref->__totlen = PAD(c->ebh_size);
---------------------------------------------------
Why do you use PAD() here? What for?
jeb->first_node = jeb->last_node = marker_ref;
- jeb->free_size = c->sector_size - c->cleanmarker_size;
- jeb->used_size = c->cleanmarker_size;
+ jeb->free_size = c->sector_size - PAD(c->ebh_size);
+ jeb->used_size = PAD(c->ebh_size);
---------------------------------------------------
And here
struct jffs2_raw_node_ref *gc_node; /* Next node to be garbage
collected */
+
+ uint8_t has_ebh;
+ uint32_t erase_count;
};
---------------------------------------------------
'uint8_t has_ebh'? I would make it just int ...
+struct jffs2_eraseblock_header
+{
+ jint16_t magic;
+ jint16_t nodetype; /* == JFFS2_NODETYPE_ERASEBLOCK_HEADER */
+ jint32_t totlen;
+ jint32_t hdr_crc;
+ uint8_t fs_version; /* the version of this JFFS2 fs image */
+ uint8_t compat_fset;
+ uint8_t incompat_fset;
+ uint8_t rocompat_fset;
+ jint32_t erase_count; /* the erase count of this erase block */
+ jint16_t dsize; /* the size of additional data behind node_crc */
+ jint32_t node_crc;
+ jint32_t data_crc;
+ jint32_t data[0];
+} __attribute__((packed));
+
struct jffs2_raw_dirent
{
---------------------------------------------------
On-flash nodes has name started from jffs2_raw_, could you please be
consistend and call your strucrure, say, jffs2_raw_eraseblock_header or
jffs2_raw_ebh?
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH]erase block header(revision 2)
2005-09-26 11:05 ` Artem B. Bityutskiy
@ 2005-09-27 7:17 ` zhao forrest
2005-09-27 8:38 ` Artem B. Bityutskiy
0 siblings, 1 reply; 5+ messages in thread
From: zhao forrest @ 2005-09-27 7:17 UTC (permalink / raw)
To: dedekind; +Cc: linux-mtd
>
>Also did not review carefully, just nodes.
>
>
> .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK),
>- .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER),
>- .totlen = cpu_to_je32(c->cleanmarker_size)
>+ .nodetype = cpu_to_je16(JFFS2_NODETYPE_ERASEBLOCK_HEADER),
>+ .totlen = cpu_to_je32(PAD(c->ebh_size)),
>---------------------------------------------------
>As we discussed, we should store real EBH node size it .totlen, not
>the EBH size + paddings to the end of page, etc. Please, store the
>EBH size on flash in c->ebg_size, no problems, but let 'totlen' have
>the same semantica as all other nodes.
>
OK.
>
>
> marker_ref->next_in_ino = NULL;
> marker_ref->next_phys = NULL;
> marker_ref->flash_offset = jeb->offset | REF_NORMAL;
>- marker_ref->__totlen = c->cleanmarker_size;
>+ marker_ref->__totlen = PAD(c->ebh_size);
>---------------------------------------------------
>Why do you use PAD() here? What for?
>
I'll not eliminate this PAD(), you may grep "__totlen" to find the
reason.
>
> jeb->first_node = jeb->last_node = marker_ref;
>
>- jeb->free_size = c->sector_size - c->cleanmarker_size;
>- jeb->used_size = c->cleanmarker_size;
>+ jeb->free_size = c->sector_size - PAD(c->ebh_size);
>+ jeb->used_size = PAD(c->ebh_size);
>---------------------------------------------------
>And here
>
Also I'll not eliminate this PAD(). The reason is the same as the
above.
>
>
> struct jffs2_raw_node_ref *gc_node; /* Next node to be garbage
>collected */
>+
>+ uint8_t has_ebh;
>+ uint32_t erase_count;
> };
>---------------------------------------------------
>'uint8_t has_ebh'? I would make it just int ...
>
OK.
>
>
>+struct jffs2_eraseblock_header
>+{
>+ jint16_t magic;
>+ jint16_t nodetype; /* == JFFS2_NODETYPE_ERASEBLOCK_HEADER */
>+ jint32_t totlen;
>+ jint32_t hdr_crc;
>+ uint8_t fs_version; /* the version of this JFFS2 fs image */
>+ uint8_t compat_fset;
>+ uint8_t incompat_fset;
>+ uint8_t rocompat_fset;
>+ jint32_t erase_count; /* the erase count of this erase block */
>+ jint16_t dsize; /* the size of additional data behind node_crc */
>+ jint32_t node_crc;
>+ jint32_t data_crc;
>+ jint32_t data[0];
>+} __attribute__((packed));
>+
> struct jffs2_raw_dirent
> {
>---------------------------------------------------
>On-flash nodes has name started from jffs2_raw_, could you please be
>consistend and call your strucrure, say, jffs2_raw_eraseblock_header
>or jffs2_raw_ebh?
>
OK.
Thanks,
Forrest
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH]erase block header(revision 2)
2005-09-27 7:17 ` zhao forrest
@ 2005-09-27 8:38 ` Artem B. Bityutskiy
0 siblings, 0 replies; 5+ messages in thread
From: Artem B. Bityutskiy @ 2005-09-27 8:38 UTC (permalink / raw)
To: zhao forrest; +Cc: linux-mtd
zhao forrest wrote:
>> marker_ref->next_in_ino = NULL;
>> marker_ref->next_phys = NULL;
>> marker_ref->flash_offset = jeb->offset | REF_NORMAL;
>> - marker_ref->__totlen = c->cleanmarker_size;
>> + marker_ref->__totlen = PAD(c->ebh_size);
>> ---------------------------------------------------
>> Why do you use PAD() here? What for?
>>
> I'll not eliminate this PAD(), you may grep "__totlen" to find the
> reason.
I did not ask to remove that so far, I asked why do you use it here?
Is it explainable in words?
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-09-27 8:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-26 8:18 [PATCH]erase block header(revision 2) zhao forrest
2005-09-26 8:41 ` Jörn Engel
2005-09-26 11:05 ` Artem B. Bityutskiy
2005-09-27 7:17 ` zhao forrest
2005-09-27 8:38 ` Artem B. Bityutskiy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox