Date:	Tue, 30 Sep 2008 14:25:42 +0530
From:	Amit Kumar Sharma <amitsharma.9@...sung.com>
To:	Artem Bityutskiy <dedekind@...radead.org>,
	linux-fsdevel@...r.kernel.org
Cc:	linux-mtd@...ts.infradead.org,
	Adrian Hunter <ext-adrian.hunter@...ia.com>,
	linux-kernel@...r.kernel.org
Subject: 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" <dedekind@...radead.org>
To: <linux-fsdevel@...r.kernel.org>
Cc: <linux-mtd@...ts.infradead.org>; "Adrian Hunter" 
<ext-adrian.hunter@...ia.com>; 
<linux-kernel@...r.kernel.org>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists