linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-mtd@lists.infradead.org, fstests@vger.kernel.org
Subject: Re: [PATCH] Add UBIFS support
Date: Tue, 16 Sep 2014 15:50:50 +0200	[thread overview]
Message-ID: <5418403A.8020004@nod.at> (raw)
In-Reply-To: <20140915215218.GH4322@dastard>

Am 15.09.2014 23:52, schrieb Dave Chinner:
> On Mon, Sep 15, 2014 at 11:11:20AM +0200, Richard Weinberger wrote:
>> UBIFS needs some extra care, the device node is of type character and
>> it has no fsck tool.
> 
> Not being familiar with UBIFS, the explaination is rather brief and
> doesn't explain anything to me. Can you document how where supposed
> to treat a filesystem that doesn't exist on a block device for all
> the tests that assume that the local fileystem is on a block device?
> e.g. how do all the generic tests that use loopback devices work?
> What about dm-flakey?

UBIFS is a filesystem designed for MTD devices.
It works on top of UBI which is kind of a LVM for NAND and NOR flashes.
On Linux MTD devices are represented as character devices, this is why
the UBI device nodes are of type character.
For more details please see:
http://www.linux-mtd.infradead.org/doc/ubi.html
http://www.linux-mtd.infradead.org/doc/ubifs.html

Of course UBIFS will not work on top of loop or dm-flakey.
AFAIK the generic tests don't use them anyway.

I'd like to have UBIFS tested with xfstests because xfstests has a very
good set of generic fs tests.
Currently UBIFS fails 20 out of 76 generic tests.
At least one issue is real. As soon I have the time I'll
inspect all other failures in detail.

>> Signed-off-by: Richard Weinberger <richard@nod.at>
>> ---
>>  README        |  1 +
>>  check         |  2 ++
>>  common/config |  4 ++--
>>  common/rc     | 18 ++++++++++++++++++
>>  4 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/README b/README
>> index 8a362bd..96adc44 100644
>> --- a/README
>> +++ b/README
>> @@ -100,6 +100,7 @@ Running tests:
>>        Running all the udf tests: ./check -udf -g udf
>>      - for running nfs tests: ./check -nfs [test(s)]
>>      - for running cifs/smb3 tests: ./check -cifs [test(s)]
>> +    - for running ubifs tests: ./check -ubifs [test(s)]
>>      - To randomize test order: ./check -r [test(s)]
>>  
>>      
>> diff --git a/check b/check
>> index 42a1ac2..57ec612 100755
>> --- a/check
>> +++ b/check
>> @@ -70,6 +70,7 @@ check options
>>      -nfs                test NFS
>>      -cifs               test CIFS
>>      -tmpfs              test TMPFS
>> +    -ubifs              test UBIFS
>>      -l			line mode diff
>>      -udiff		show unified diff (default)
>>      -n			show me, do not run tests
> 
> I'd like to avoid adding command line switches for random filesystem
> types if at all possible. I'd much prefer that it be derived from
> the current TEST_DEV if at all possible. Can you probe for UBIFS
> similar to using blkid for local filesystems?

I fear blkid does not detect UBIFS, but we can match it from the device node name.
UBIFS can only work on top of an UBI volume. UBI volumes have names like /dev/ubiX_Y.
Where X is the UBI image number and Y the volume number.

>> diff --git a/common/config b/common/config
>> index fc21b37..af082ea 100644
>> --- a/common/config
>> +++ b/common/config
>> @@ -430,7 +430,7 @@ get_next_config() {
>>  		exit 1
>>  	fi
>>  
>> -	echo $TEST_DEV | grep -qE ":|//" > /dev/null 2>&1
>> +	echo $TEST_DEV | grep -qE ":|//|ubi" > /dev/null 2>&1
>>  	if [ ! -b "$TEST_DEV" -a "$?" != "0" ]; then
>>  		echo "common/config: Error: \$TEST_DEV ($TEST_DEV) is not a block device or a network filesystem"
>>  		exit 1
> 
> Needs a comment explaining what format we are searching for there?

See above. I match the string "ubi" in /dev/ubiX_Y.

>> @@ -453,7 +453,7 @@ get_next_config() {
>>  		export SCRATCH_DEV_NOT_SET=true
>>  	fi
>>  
>> -	echo $SCRATCH_DEV | grep -qE ":|//" > /dev/null 2>&1
>> +	echo $SCRATCH_DEV | grep -qE ":|//|ubi" > /dev/null 2>&1
>>  	if [ ! -z "$SCRATCH_DEV" -a ! -b "$SCRATCH_DEV" -a "$?" != "0" ]; then
>>  		echo "common/config: Error: \$SCRATCH_DEV ($SCRATCH_DEV) is not a block device or a network filesystem"
>>  		exit 1
>> diff --git a/common/rc b/common/rc
>> index b8f711a..064b987 100644
>> --- a/common/rc
>> +++ b/common/rc
>> @@ -1034,6 +1034,12 @@ _require_scratch_nocheck()
>>  		    _notrun "this test requires a valid \$SCRATCH_MNT and unique $SCRATCH_DEV"
>>  		fi
>>  		;;
>> +	ubifs)
>> +		if [ -z "$SCRATCH_DEV" -o ! -c "$SCRATCH_DEV" -o ! -d "$SCRATCH_MNT" ];
>> +		then
>> +		    _notrun "this test requires a valid \$SCRATCH_MNT and unique $SCRATCH_DEV"
>> +		fi
>> +		;;
> 
> s/unique/valid/

Will fix!

Thanks,
//richard

  reply	other threads:[~2014-09-16 13:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15  9:11 [PATCH] Add UBIFS support Richard Weinberger
2014-09-15  9:12 ` Richard Weinberger
2014-09-15 21:52 ` Dave Chinner
2014-09-16 13:50   ` Richard Weinberger [this message]
2014-09-17  4:47     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5418403A.8020004@nod.at \
    --to=richard@nod.at \
    --cc=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).