Some flash media are capable of reading sequentially at faster rates.
UBIFS bulk-read facility is designed to take advantage of that, by
reading in one go consecutive data nodes that are also located
consecutively in the same LEB.

Read speed on Arm platform with OneNAND goes from 17 MiB/s to
19 MiB/s.
Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>

Always allow truncations to zero, even if budgeting thinks there
is no space. UBIFS reserves some space for deletions anyway.

Otherwise, the following happans:
1. create a file, and write as much as possible there, until ENOSPC
2. truncate the file, which fails with ENOSPC, which is not good.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Signed-off-by: NZoltan Sogor <weth@inf.u-szeged.hu>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

UBIFS aligns node lengths to 8, so budgeting has to do the
same. Well, direntry, inode, and page budgets are already
aligned, but not inode data budget (e.g., data in special
devices or symlinks). Do this for inode data as well.
Also, add corresponding debugging checks.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

1. Print inode mode in some of debugging messages
2. Add few more useful assertions
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

fs.h needs path.h, not namei.h; nfs_fs.h doesn't need it at all.
Several places in the tree needed direct include.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This is a new flash file system. See
http://www.linux-mtd.infradead.org/doc/ubifs.htmlSigned-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>