Patchwork UBI/ubifs problem

login
register
mail settings
Submitter Artem Bityutskiy
Date March 7, 2012, 4:37 p.m.
Message ID <1331138261.3463.19.camel@sauron.fi.intel.com>
Download mbox | patch
Permalink /patch/145318/
State New
Headers show

Comments

Artem Bityutskiy - March 7, 2012, 4:37 p.m.
On Wed, 2012-03-07 at 17:26 +0100, Ricard Wanderlof wrote:
> Is it possible to get mkfs.ubifs to create an image without specifying the 
> max-leb-count ? I.e. just to create an image that is as big as it has to 
> be.

Has to be? :-) Not sure how to find this out. Basically the idea was
that you know how big is has to be and translate that to
--max-leb-count.

> > P.S. I did not even compile - test the below patch, but will push out a
> > tested version.
> 
> Thanks for the patch, I'll try to test it.

It broke compilation, the working one is attached.
Ricard Wanderlof - March 8, 2012, 5:09 a.m.
On Wed, 7 Mar 2012, Artem Bityutskiy wrote:

> On Wed, 2012-03-07 at 17:26 +0100, Ricard Wanderlof wrote:
>> Is it possible to get mkfs.ubifs to create an image without specifying the
>> max-leb-count ? I.e. just to create an image that is as big as it has to
>> be.
>
> Has to be? :-) Not sure how to find this out. Basically the idea was
> that you know how big is has to be and translate that to
> --max-leb-count.

I think what I'm thinking about is that in the specialized case of ubifs 
used for a read-only file system, such as a root file system (without 
/etc, /var, and so on), it would be possible for mkfs.ubifs to create a 
file system, and use as many LEBs as it needs for the actual data. On a 
read-only file system there doesn't even have to be a journal, although I 
don't know if that is possible.

In that case one could simply feed the required directory structure to 
mkfs.ubifs, and it would create the file system image, and report how many 
LEBs are required in the flash.

> It broke compilation, the working one is attached.

Ok, I'll have a look at the new one instead.

/Ricard
Artem Bityutskiy - March 9, 2012, 1:39 p.m.
On Thu, 2012-03-08 at 06:09 +0100, Ricard Wanderlof wrote:
> On Wed, 7 Mar 2012, Artem Bityutskiy wrote:
> 
> > On Wed, 2012-03-07 at 17:26 +0100, Ricard Wanderlof wrote:
> >> Is it possible to get mkfs.ubifs to create an image without specifying the
> >> max-leb-count ? I.e. just to create an image that is as big as it has to
> >> be.
> >
> > Has to be? :-) Not sure how to find this out. Basically the idea was
> > that you know how big is has to be and translate that to
> > --max-leb-count.
> 
> I think what I'm thinking about is that in the specialized case of ubifs 
> used for a read-only file system, such as a root file system (without 
> /etc, /var, and so on), it would be possible for mkfs.ubifs to create a 
> file system, and use as many LEBs as it needs for the actual data. On a 
> read-only file system there doesn't even have to be a journal, although I 
> don't know if that is possible.

Well, I'd accept a patch which added a --optimize-for-ro option which
would prepare a file-system with the smallest journal size.
Ricard Wanderlof - March 9, 2012, 1:45 p.m.
On Fri, 9 Mar 2012, Artem Bityutskiy wrote:

>> I think what I'm thinking about is that in the specialized case of ubifs
>> used for a read-only file system, such as a root file system (without
>> /etc, /var, and so on), it would be possible for mkfs.ubifs to create a
>> file system, and use as many LEBs as it needs for the actual data. On a
>> read-only file system there doesn't even have to be a journal, although I
>> don't know if that is possible.
>
> Well, I'd accept a patch which added a --optimize-for-ro option which
> would prepare a file-system with the smallest journal size.

Can the journal be eliminated completely or does something in ubifs 
require there to be a journal at all times, albeit small?

/Ricard
Artem Bityutskiy - March 9, 2012, 1:51 p.m.
On Fri, 2012-03-09 at 14:45 +0100, Ricard Wanderlof wrote:
> On Fri, 9 Mar 2012, Artem Bityutskiy wrote:
> 
> >> I think what I'm thinking about is that in the specialized case of ubifs
> >> used for a read-only file system, such as a root file system (without
> >> /etc, /var, and so on), it would be possible for mkfs.ubifs to create a
> >> file system, and use as many LEBs as it needs for the actual data. On a
> >> read-only file system there doesn't even have to be a journal, although I
> >> don't know if that is possible.
> >
> > Well, I'd accept a patch which added a --optimize-for-ro option which
> > would prepare a file-system with the smallest journal size.
> 
> Can the journal be eliminated completely or does something in ubifs 
> require there to be a journal at all times, albeit small?

I think currently at least 5 LEBs are required:

/* Minimum number of logical eraseblocks in the log */
#define UBIFS_MIN_LOG_LEBS 2
/* Minimum number of bud logical eraseblocks (one for each head) */
#define UBIFS_MIN_BUD_LEBS 3
/* Minimum number of journal logical eraseblocks */
#define UBIFS_MIN_JNL_LEBS (UBIFS_MIN_LOG_LEBS + UBIFS_MIN_BUD_LEBS)

Patch

From 5a1f36c90c9b21a7aa31c29a1926b376dd6a11cf Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Wed, 7 Mar 2012 16:29:45 +0200
Subject: [PATCH] UBIFS: improve error messages

Ricard complaints that the following error message is odd:

"UBIFS error (pid 1578): validate_sb: bad superblock, error 8"

and he is right. This patch improves the error messages a bit and makes
them more user-friendly.

Reported-by: Ricard Wanderlof <ricard.wanderlof@axis.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
 fs/ubifs/sb.c |   19 ++++++++++++++-----
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c
index 6094c5a..771f7fb 100644
--- a/fs/ubifs/sb.c
+++ b/fs/ubifs/sb.c
@@ -410,13 +410,23 @@  static int validate_sb(struct ubifs_info *c, struct ubifs_sb_node *sup)
 	}
 
 	if (c->main_lebs < UBIFS_MIN_MAIN_LEBS) {
-		err = 7;
+		ubifs_err("too few main LEBs count %d, must be at least %d",
+			  c->main_lebs, UBIFS_MIN_MAIN_LEBS);
 		goto failed;
 	}
 
-	if (c->max_bud_bytes < (long long)c->leb_size * UBIFS_MIN_BUD_LEBS ||
-	    c->max_bud_bytes > (long long)c->leb_size * c->main_lebs) {
-		err = 8;
+	max_bytes = (long long)c->leb_size * UBIFS_MIN_BUD_LEBS;
+	if (c->max_bud_bytes < max_bytes) {
+		ubifs_err("too small journal (%lld bytes), must be at least "
+			  "%lld bytes",  c->max_bud_bytes, max_bytes);
+		goto failed;
+	}
+
+	max_bytes = (long long)c->leb_size * c->main_lebs;
+	if (c->max_bud_bytes > max_bytes) {
+		ubifs_err("too large journal size (%lld bytes), only %lld bytes"
+			  "available in the main area",
+			  c->max_bud_bytes, max_bytes);
 		goto failed;
 	}
 
@@ -450,7 +460,6 @@  static int validate_sb(struct ubifs_info *c, struct ubifs_sb_node *sup)
 		goto failed;
 	}
 
-	max_bytes = c->main_lebs * (long long)c->leb_size;
 	if (c->rp_size < 0 || max_bytes < c->rp_size) {
 		err = 14;
 		goto failed;
-- 
1.7.9.1