4K block size question

4K block size question

[Artem B. Bityuckiy]

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.

Re: 4K block size question

[David Woodhouse]

On Wed, 2004-10-20 at 14:57 +0400, Artem B. Bityuckiy wrote:
> 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 :-) ?

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

-- 
dwmw2

Re: 4K block size question

[Artem B. Bityuckiy]

> By writing nodes which don't cover a full 4KiB and hence aren't
> pristine.
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.

Re: 4K block size question

[David Woodhouse]

On Wed, 2004-10-20 at 15:17 +0400, Artem B. Bityuckiy wrote:
> > By writing nodes which don't cover a full 4KiB and hence aren't
> > pristine.
> 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?

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

Re: 4K block size question

[Artem B. Bityuckiy]

Ok, thanks for answer.

> Other than the fact that it doesn't pack well, not really.
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?

> If they're that large are they _really_ an effective use of space? 
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.

Re: 4K block size question

[Artem B. Bityuckiy]

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.

Re: 4K block size question

[David Woodhouse]

On Thu, 2004-10-21 at 15:58 +0400, Artem B. Bityuckiy wrote:
> 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).

Well spotted; thanks.

-- 
dwmw2