From: hujianyang <hujianyang@huawei.com>
To: <dedekind1@gmail.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
Bill Pringlemeir <bpringlemeir@nbsps.com>
Subject: Re: [PATCH v5 3/4] ubi-utils: ubidump: introduce ubidump
Date: Thu, 20 Nov 2014 17:24:03 +0800 [thread overview]
Message-ID: <546DB333.5080500@huawei.com> (raw)
In-Reply-To: <1414761646.23185.71.camel@sauron.fi.intel.com>
On 2014/10/31 21:20, Artem Bityutskiy wrote:
> On Fri, 2014-10-31 at 18:55 +0800, hujianyang wrote:
>> I should say it is unfair for me to discuss a problem like this with
>> you. I will follow your idea because I not good at English.
>>
>> Give me some days, I will resend this patch set. I'm happy to see the
>> patch set is thinner than it used to be. Thanks for your help.
>
> Well, nothing unfair. I might be missing your point. All I want is to
> understand what will the options be, what will they mean. If you cannot
> come up with a short and concise description for the options, explain
> them in a long way in the e-mail, I'll help with the concise version.
> And you do not have t agree with me, I am just asking question so at
> this point. Do not worry about your English skills too much.
>
>
>
Artem,
Sorry, I'm busy with other stuff these days so I have to leave *ubidump*
behind. I'd like to introduce this option to you and wish you could help
me come up with a suitable name.
This dump tool can print NODEs type only, like this:
/tmp# ./ubidump /dev/ubi0_0 --lnum 0
scan LEB 0:0
look at LEB 0:0 (126976 bytes left)
scanning superblock node at LEB 0:0
look at LEB 0:4096 (122880 bytes left)
hit empty space at LEB 0:4096
stop scanning LEB 0 at offset 126976
/tmp# ./ubidump /dev/ubi0_0 --lnum 1
scan LEB 1:0
look at LEB 1:0 (126976 bytes left)
scanning master node at LEB 1:0
look at LEB 1:512 (126464 bytes left)
scanning padding node at LEB 1:512
1508 bytes padded at LEB 1:512, offset now 2048
look at LEB 1:2048 (124928 bytes left)
scanning master node at LEB 1:2048
look at LEB 1:2560 (124416 bytes left)
scanning padding node at LEB 1:2560
1508 bytes padded at LEB 1:2560, offset now 4096
look at LEB 1:4096 (122880 bytes left)
scanning master node at LEB 1:4096
look at LEB 1:4608 (122368 bytes left)
scanning padding node at LEB 1:4608
1508 bytes padded at LEB 1:4608, offset now 6144
look at LEB 1:6144 (120832 bytes left)
scanning master node at LEB 1:6144
look at LEB 1:6656 (120320 bytes left)
scanning padding node at LEB 1:6656
1508 bytes padded at LEB 1:6656, offset now 8192
look at LEB 1:8192 (118784 bytes left)
hit empty space at LEB 1:8192
stop scanning LEB 1 at offset 126976
But it can do more, print data in NODEs with an additional option:
/tmp# ./ubidump /dev/ubi0_0 --lnum 0 --info(--ubifs As you suggested)
scan LEB 0:0
look at LEB 0:0 (126976 bytes left)
scanning superblock node at LEB 0:0
magic 0x6101831
crc 0x1144bca
node_type 6 (superblock node)
group_type 0 (no node group)
sqnum 1
len 4096
key_hash 0 (R5)
key_fmt 0 (simple)
flags 0
big_lpt 0
space_fixup 0
min_io_size 2048
leb_size 126976
leb_cnt 940
max_leb_cnt 940
max_bud_bytes 5459968
log_lebs 4
lpt_lebs 2
orph_lebs 2
jhead_cnt 1
fanout 8
lsave_cnt 256
default_compr 1
rp_size 5242880
rp_uid 0
rp_gid 0
fmt_version 4
time_gran 1000000000
UUID 0x175248cUB
look at LEB 0:4096 (122880 bytes left)
hit empty space at LEB 0:4096
stop scanning LEB 0 at offset 126976
Do you have a good idea about how we call this option?
By the way, I've replied the mail
"UBIFS assert failed in ubifs_set_page_dirty at 1421"
reported by jijiagang@hisilicon.com but mm people do not response.
http://lists.infradead.org/pipermail/linux-mtd/2014-November/056378.html
I will change some mm code and test if it works, do you have any
suggestions about this?
Thanks~!
Hu
next prev parent reply other threads:[~2014-11-20 9:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 10:37 [PATCH v5 1/4] ubi-utils: ubidump: add ubifs-media hujianyang
2014-10-22 10:40 ` [PATCH v5 2/4] ubi-utils: ubidump: add libdump hujianyang
2014-10-22 10:43 ` [PATCH v5 3/4] ubi-utils: ubidump: introduce ubidump hujianyang
2014-10-30 8:19 ` Artem Bityutskiy
2014-10-30 8:30 ` Artem Bityutskiy
2014-10-31 2:17 ` hujianyang
2014-10-31 7:32 ` Artem Bityutskiy
2014-10-31 10:55 ` hujianyang
2014-10-31 13:20 ` Artem Bityutskiy
2014-11-20 9:24 ` hujianyang [this message]
2014-11-27 14:32 ` Artem Bityutskiy
2014-12-01 1:45 ` hujianyang
2014-10-22 10:47 ` [PATCH v5 4/4] ubi-utils: ubidump: compile enable hujianyang
2014-10-30 7:51 ` [PATCH v5 1/4] ubi-utils: ubidump: add ubifs-media Artem Bityutskiy
2014-10-30 8:01 ` Artem Bityutskiy
2014-10-31 2:03 ` hujianyang
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=546DB333.5080500@huawei.com \
--to=hujianyang@huawei.com \
--cc=bpringlemeir@nbsps.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.