Question about mkfs.jffs2 "-s" option

Artem Bityutskiy dedekind1 at gmail.com
Fri May 4 03:15:37 EDT 2012


On Thu, 2012-05-03 at 21:13 +0300, Shmulik Ladkani wrote:
> Hi Ricard,
> 	
> On Thu, 3 May 2012 09:35:14 +0200 (CEST) Ricard Wanderlof <ricard.wanderlof at axis.com> wrote:
> > 
> > On Wed, 2 May 2012, Grant Edwards wrote:
> > 
> > > The NAND flash I'm using has to be written in 4K blocks -- isn't that
> > > the "page size"?
> > 
> > The smallest writable unit in a NAND flash is called a 'page', but AFAIK 
> > this is not what the -s option in mkfs.jffs2 is for. Instead, it is 
> > related for the kernel memory managament page size, which is 4k for most 
> > architectures.
> 
> According to MKFS.JFFS2(1),
> 
> 	-s, --pagesize=SIZE
> 		Use page size SIZE.  The default is 4 KiB.  This size is
> 		the maximum size of a data node.
> 
> And according to http://linux-mtd.infradead.org/~dwmw2/jffs2.pdf
> 
> 	In order to facilitate rapid decompression of
> 	data upon readpage() requests, nodes contain
> 	no more than a single page of data, according to
> 	the hardware page size on the target platform.
> 
> Wow.
> I always assumed I had to set it according to NAND's page size, not
> according to target system's mm page size.

Shmulik, I can give some info about this. First of all because of
compression and very different node sizes (UBIFS and JFFS2) and because
JFFS2 was designed for NOR flash originally - NAND page size is not
something which affects the design of file-systems, or their on-flash
layout. We use write-buffers on I/O level to make it appear like the
eraseblock is byte-writable.

The RAM page size comes from the general linux design - the VFS writes
in RAM page size units, and it is much simpler to make max node size =
PAGE_CACHE_SIZE rather than trying to split it when the PAGE_CACHE_SIZE
is something like 16KiB. This is where this -s stuff comes from. I think
it was a mistake to introduce this parameter because it is very unlikely
JFFS2 is/was used on systems with a different PAGE_CACHE_SIZE.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120504/2ec16ba2/attachment-0001.sig>


More information about the linux-mtd mailing list