4K block size question

Hello,

In case of 2MiB NAND flash (with 256-byte page) the sector size is 4KiB. The JFFS2 virtual block size is also 4KiB.

The size of pristine node is 4KiB data + node header. So, in uncompressed form, the pristine node can't fit into JFFS2 block if the compression is disabled. So, how does JFFS2 work on such flash :-) ?

Thanks.

Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

By writing nodes which don't cover a full 4KiB and hence aren't pristine.

dwmw2

Thanks.

By the way, what do you (and other JFFS2 folks) think about very big nodes of size = block size? I'm going to create such a big inode checkpoints. Is it OK? Are there some reasons not to do so and split them into several smaller nodes?

Thanks.

Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Other than the fact that it doesn't pack well, not really. If they're that large are they _really_ an effective use of space?

dwmw2

Ok, thanks for answer.

Hmm, I don't cleanly understand what do you mean. I suspect you mean that requesting the whole block from the jffs2_reserve_space() is bad idea - I agree, I am not going to do so.

Or you mean that small chunks of data are compressed better than big ones? If so, can you pleas explain why?

Of course, I gonna request small piece of space (small minsize parameter of the jffs2_reserve_space()). But, if the jffs2_reserve_space() allocates the whole block, I think it is OK to write one big node.

Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Hello,

In the JFFS2, there is place where both c->erase_completion and c->inocache spinlocks are held. But the c->erase_completion is locked first. This fact does not highlighted in the README.Locking file.

I propose to metnion it there. (i.e., that if both locks are needed, the c->erase_completion must be locked first).

Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Well spotted; thanks.

dwmw2