aboutsummaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2011-04-25 18:46:31 +0300
committerGreg Kroah-Hartman <gregkh@suse.de>2011-05-09 15:06:39 -0700
commitf038f4d893e9ef35dd38f1ca01001dfe21c5f8f5 (patch)
treec6f963140058fd3631021d69c748c53c7486bd51 /drivers
parent21fb89793df408cc116aa52399a5e6f7af459596 (diff)
downloadlinux-linaro-android-f038f4d893e9ef35dd38f1ca01001dfe21c5f8f5.tar.gz
UBIFS: seek journal heads to the latest bud in replay
commit 52c6e6f990669deac3f370f1603815adb55a1dbd upstream. This is the second fix of the following symptom: UBIFS error (pid 34456): could not find an empty LEB which sometimes happens after power cuts when we mount the file-system - UBIFS refuses it with the above error message which comes from the 'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test with the UBIFS power cut emulation enabled. Analysis of the problem. Currently UBIFS replay seeks the journal heads to the last _replayed_ bud. But the buds are replayed out-of-order, so the replay basically seeks journal heads to the "random" bud belonging to this head, and not to the _last_ one. The result of this is that the GC head may be seeked to a full LEB with no free space, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a fully or mostly dirty LEB to match the current GC head (because we need to garbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum). So 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and also fail. As a result - recovery fails and mounting fails. This patch teaches the replay to initialize the GC heads exactly to the latest buds, i.e. the buds which have the largest sequence number in corresponding log reference nodes. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions