What is in ubifs-2.6.git - Kernel
This is a discussion on What is in ubifs-2.6.git - Kernel ; From: Artem Bityutskiy
When UBIFS switches to R/O mode because of an error,
it is reasonable to enable data CRC checking.
Signed-off-by: Artem Bityutskiy
---
fs/ubifs/io.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
...
-
[PATCH] UBIFS: check data CRC when in error state
From: Artem Bityutskiy
When UBIFS switches to R/O mode because of an error,
it is reasonable to enable data CRC checking.
Signed-off-by: Artem Bityutskiy
---
fs/ubifs/io.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
index 40e2790..0168271 100644
--- a/fs/ubifs/io.c
+++ b/fs/ubifs/io.c
@@ -62,6 +62,7 @@ void ubifs_ro_mode(struct ubifs_info *c, int err)
{
if (!c->ro_media) {
c->ro_media = 1;
+ c->no_chk_data_crc = 0;
ubifs_warn("switched to read-only mode, error %d", err);
dbg_dump_stack();
}
--
1.5.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
[PATCH] UBIFS: update dbg_dump_inode
From: Artem Bityutskiy
'dbg_dump_inode()' is quite outdated and does not print all
the fileds.
Signed-off-by: Artem Bityutskiy
---
fs/ubifs/debug.c | 42 +++++++++++++++++++++++++-----------------
1 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/fs/ubifs/debug.c b/fs/ubifs/debug.c
index d7f7645..32071ec 100644
--- a/fs/ubifs/debug.c
+++ b/fs/ubifs/debug.c
@@ -222,30 +222,38 @@ void dbg_dump_inode(const struct ubifs_info *c, const struct inode *inode)
{
const struct ubifs_inode *ui = ubifs_inode(inode);
- printk(KERN_DEBUG "inode %lu\n", inode->i_ino);
- printk(KERN_DEBUG "size %llu\n",
+ printk(KERN_DEBUG "Dump in-memory inode:");
+ printk(KERN_DEBUG "\tinode %lu\n", inode->i_ino);
+ printk(KERN_DEBUG "\tsize %llu\n",
(unsigned long long)i_size_read(inode));
- printk(KERN_DEBUG "nlink %u\n", inode->i_nlink);
- printk(KERN_DEBUG "uid %u\n", (unsigned int)inode->i_uid);
- printk(KERN_DEBUG "gid %u\n", (unsigned int)inode->i_gid);
- printk(KERN_DEBUG "atime %u.%u\n",
+ printk(KERN_DEBUG "\tnlink %u\n", inode->i_nlink);
+ printk(KERN_DEBUG "\tuid %u\n", (unsigned int)inode->i_uid);
+ printk(KERN_DEBUG "\tgid %u\n", (unsigned int)inode->i_gid);
+ printk(KERN_DEBUG "\tatime %u.%u\n",
(unsigned int)inode->i_atime.tv_sec,
(unsigned int)inode->i_atime.tv_nsec);
- printk(KERN_DEBUG "mtime %u.%u\n",
+ printk(KERN_DEBUG "\tmtime %u.%u\n",
(unsigned int)inode->i_mtime.tv_sec,
(unsigned int)inode->i_mtime.tv_nsec);
- printk(KERN_DEBUG "ctime %u.%u\n",
+ printk(KERN_DEBUG "\tctime %u.%u\n",
(unsigned int)inode->i_ctime.tv_sec,
(unsigned int)inode->i_ctime.tv_nsec);
- printk(KERN_DEBUG "creat_sqnum %llu\n", ui->creat_sqnum);
- printk(KERN_DEBUG "xattr_size %u\n", ui->xattr_size);
- printk(KERN_DEBUG "xattr_cnt %u\n", ui->xattr_cnt);
- printk(KERN_DEBUG "xattr_names %u\n", ui->xattr_names);
- printk(KERN_DEBUG "dirty %u\n", ui->dirty);
- printk(KERN_DEBUG "xattr %u\n", ui->xattr);
- printk(KERN_DEBUG "flags %d\n", ui->flags);
- printk(KERN_DEBUG "compr_type %d\n", ui->compr_type);
- printk(KERN_DEBUG "data_len %d\n", ui->data_len);
+ printk(KERN_DEBUG "\tcreat_sqnum %llu\n", ui->creat_sqnum);
+ printk(KERN_DEBUG "\txattr_size %u\n", ui->xattr_size);
+ printk(KERN_DEBUG "\txattr_cnt %u\n", ui->xattr_cnt);
+ printk(KERN_DEBUG "\txattr_names %u\n", ui->xattr_names);
+ printk(KERN_DEBUG "\tdirty %u\n", ui->dirty);
+ printk(KERN_DEBUG "\txattr %u\n", ui->xattr);
+ printk(KERN_DEBUG "\tbulk_read %u\n", ui->xattr);
+ printk(KERN_DEBUG "\tsynced_i_size %llu\n",
+ (unsigned long long)ui->synced_i_size);
+ printk(KERN_DEBUG "\tui_size %llu\n",
+ (unsigned long long)ui->ui_size);
+ printk(KERN_DEBUG "\tflags %d\n", ui->flags);
+ printk(KERN_DEBUG "\tcompr_type %d\n", ui->compr_type);
+ printk(KERN_DEBUG "\tlast_page_read %lu\n", ui->last_page_read);
+ printk(KERN_DEBUG "\tread_in_a_row %lu\n", ui->read_in_a_row);
+ printk(KERN_DEBUG "\tdata_len %d\n", ui->data_len);
}
void dbg_dump_node(const struct ubifs_info *c, const void *node)
--
1.5.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
Re: What is in ubifs-2.6.git
Hi Artem
OneNAND can support for full block read also in sync burst
block read mode ,so why u want to limit bulk read only for 4
pages , with sync burst enable u can read max 64 pages.
so in place of max 4 pages , u can set max to 64 it will be
improve performance if sync burst mode is upported.
Rgs
Amit
----- Original Message -----
From: "Artem Bityutskiy"
To:
Cc: ; "Adrian Hunter"
;
Sent: Tuesday, September 30, 2008 2:48 PM
Subject: What is in ubifs-2.6.git
> Hi,
>
> here is the stuff we have scheduled for 2.6.28. The
> patches
> contains various small fixes and cleanups, but there is
> something
> interesting as well.
>
> The first interesting thing is new "bulk read"
> functionality. The
> idea is that many NAND flashes support "bulk read" in some
> form.
> For example, OneNAND has "read while load" feature, which
> allows
> reading consecutive NAND pages faster than reading them
> one-by-one.
>
> So we've made UBIFS benefit from this feature and
> introduced new
> "bulk_read" mount option. With this option enabled UBIFS
> reads files
> a little ahead if the file data sits in consecutive
> physical
> addresses. For example, if user-space asks to read page
> zero of a
> file, and page 0-4 are in consecutive flash addressed,
> UBIFS reads
> pages 0-4 and populates them to the Page Cache.
>
> Note, this is disabled by default and UBIFS has to be
> explicitly
> mounted mounted with "bulk_read" option. The reason for
> this is
> that we consider this feature as experimental so far.
>
> Note, UBIFS does not use VFS read-ahead and actually
> explicitly
> disables it. This is because MTD is synchronous and all
> I/O is
> done synchronously, so read-ahead actually slows things
> down for
> UBIFS, instead of improving them. So the "bulk read"
> feature is
> basically internal UBIFS read-ahead implementation.
>
> We are able to gain 4-5MiB/s of read speed on OneNAND with
> bulk
> read enabled.
>
> The second interesting thing is new "no_chk_data_crc"
> mount option
> which disables data CRC32 checking.
>
> UBIFS always checks CRC of everything it reads from flash
> by default.
> On ARM platform this results in ~30% of total CPU usage in
> profiles,
> which is quite high. But many modern flashes are very
> reliable
> (e.g., OneNAND), and one does not need that level of
> protection.
> So now it is possible to disable CRC checking for _data_.
> However:
>
> * internal indexing information CRC is always checked;
> * when replaying the journal, data CRC is always checked;
> * on write, CRC is always calculated.
>
> With this mount option we are able to gain another
> 4-5MiB/s of read
> speed on OneNAND. And together with bulk-read, the read
> speed becomes
> ~10MiB/s faster.
>
> Adrian Hunter (11):
> UBIFS: add bulk-read facility
> UBIFS: add no_chk_data_crc mount option
> UBIFS: improve znode splitting rules
> UBIFS: correct key comparison
> UBIFS: ensure data read beyond i_size is zeroed out
> correctly
> UBIFS: allow for sync_fs when read-only
> UBIFS: improve garbage collection
> UBIFS: fix bulk-read handling uptodate pages
> UBIFS: add more debugging messages for LPT
> UBIFS: correct condition to eliminate unecessary
> assignment
> UBIFS: check buffer length when scanning for LPT
> nodes
>
> Artem Bityutskiy (9):
> UBIFS: add a print, fix comments and more minor stuff
> UBIFS: inline one-line functions
> UBIFS: check data CRC when in error state
> UBIFS: use bit-fields when possible
> UBIFS: fix races in bit-fields
> UBIFS: fix commentary
> UBIFS: update dbg_dump_inode
> UBIFS: correct comment for commit_on_unmount
> UBIFS: commit on sync_fs
>
> Hirofumi Nakagawa (1):
> UBIFS: remove unneeded unlikely()
>
> Julien Brunel (1):
> UBIFS: use an IS_ERR test rather than a NULL test
>
> Documentation/filesystems/ubifs.txt | 9 +
> fs/ubifs/budget.c | 26 ++--
> fs/ubifs/debug.c | 79 +++++++--
> fs/ubifs/debug.h | 6 +
> fs/ubifs/file.c | 260
> ++++++++++++++++++++++++++
> fs/ubifs/find.c | 4 +-
> fs/ubifs/gc.c | 90 ++++++++--
> fs/ubifs/io.c | 12 +-
> fs/ubifs/key.h | 22 ++-
> fs/ubifs/lprops.c | 34 +----
> fs/ubifs/lpt.c | 3 +-
> fs/ubifs/lpt_commit.c | 187
> ++++++++++++++++++-
> fs/ubifs/misc.h | 27 +++
> fs/ubifs/scan.c | 2 +-
> fs/ubifs/super.c | 109 +++++++++--
> fs/ubifs/tnc.c | 345
> ++++++++++++++++++++++++++++++++---
> fs/ubifs/tnc_misc.c | 4 +-
> fs/ubifs/ubifs-media.h | 1 -
> fs/ubifs/ubifs.h | 85 +++++++--
> fs/ubifs/xattr.c | 2 +-
> 20 files changed, 1149 insertions(+), 158 deletions(-)
>
> --
> Best regards,
> Artem Bityutskiy (?и???кий ????м)
>
>
--------------------------------------------------------------------------------
> __________________________________________________ ____
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
Re: What is in ubifs-2.6.git
On Tue, 2008-09-30 at 14:25 +0530, Amit Kumar Sharma wrote:
> Hi Artem
>
> OneNAND can support for full block read also in sync burst
> block read mode ,so why u want to limit bulk read only for 4
> pages , with sync burst enable u can read max 64 pages.
> so in place of max 4 pages , u can set max to 64 it will be
> improve performance if sync burst mode is upported.
Actually UBIFS reads up to whole eraseblock. So if you have
a file, and it is resided in consecutive NAND pages of an
eraseblock, and UBIFS has decided to do read-ahead, it would
read whole eraseblock. So for OneNAND, indeed UBIFS may read
up to 64 NAND pages at one go.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/