| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
jffs2_flash_direct_writev() always invokes jffs2_sum_add_kvec(), even
if mtd_writev() fails. Usually, this results in an extra summary entry
pointing to dirty node space, which should be ignored -- it is a bit of
a waste, but harmless.
When mtd_writev() returns *retlen == 0, though, the node space is not
reserved as dirty, but re-used; the extra summary entry then points
into the space of the next node. After the erase block has been closed,
we get the following messages on remount:
jffs2: error: (79) jffs2_link_node_ref:
Adding new ref c3048d18 at (0x00ec5b88-0x00ec6bcc)
not immediately after previous (0x00ec5b88-0x00ec5b88)
...
jffs2: Checked all inodes but still 0x2088 bytes of unchecked space?
jffs2: No space for garbage collection. Aborting GC thread
The extra summary entries amount to "unchecked space", so that
jffs2_garbage_collect_pass() returns -ENOSPC. And without garbage
collection, the filesystem becomes unuseable over time as the erase
blocks fill up.
Fix this by skipping jffs2_sum_add_kvec() when the MTD write fails. We
don't need the summary entry anyway, and the behaviour matches that of
jffs2_flash_writev() in wbuf.c (with write buffering enabled).
Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
|
|
This patch makes the 'mtd_writev()' function more usable and logical. We first
teach it to fall-back to the 'default_mtd_writev()' function if the MTD driver
does not define its own '->writev()' method. Then we make block2mtd and JFFS2
just 'mtd_writev()' instead of 'default_mtd_writev()' function. This means we
can now stop exporting 'default_mtd_writev()' and instead, export
'mtd_writev()'. This is much cleaner and more logical, as well as allows us to
get read of another direct 'mtd->writev' access in JFFS2.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Instead, use 'default_mtd_writev()' function which MTD provides.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
In particular, remove the bit in the LICENCE file about contacting
Red Hat for alternative arrangements. Their errant IS department broke
that arrangement a long time ago -- the policy of collecting copyright
assignments from contributors came to an end when the plug was pulled on
the servers hosting the project, without notice or reason.
We do still dual-license it for use with eCos, with the GPL+exception
licence approved by the FSF as being GPL-compatible. It's just that nobody
has the right to license it differently.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
|
|
Do the summary collection in the right place. If the device
was not writebuffered but had c->mtd->writev function
(e.g. blkmtd) the summary collector function was not called.
Signed-off-by: Ferenc Havasi <havasi@inf.u-szeged.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
The goal of summary is to speed up the mount time. Erase block summary (EBS)
stores summary information at the end of every (closed) erase block. It is
no longer necessary to scan all nodes separetly (and read all pages of them)
just read this "small" summary, where every information is stored which is
needed at mount time.
This summary information is stored in a JFFS2_FEATURE_RWCOMPAT_DELETE. During
the mount process if there is no summary info the orignal scan process will
be executed. EBS works with NAND and NOR flashes, too.
There is a user space tool called sumtool to generate this summary
information for a JFFS2 image.
Signed-off-by: Ferenc Havasi <havasi@inf.u-szeged.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
