Searched hist:"5817 b9dc9cc1225feedd9e1282707165fc64c384" (Results 1 – 3 of 3) sorted by relevance
| /openbmc/linux/fs/jffs2/ |
| H A D | jffs2_fs_sb.h | diff 5817b9dc9cc1225feedd9e1282707165fc64c384 Mon Feb 01 06:00:25 CST 2016 David Woodhouse <David.Woodhouse@intel.com> jffs2: Improve post-mount CRC scan efficiency
We need to finish doing the CRC checks before we can allow writes to
happen, and we currently process the inodes in order. This means a call
to jffs2_get_ino_cache() for each possible inode# up to c->highest_ino.
There may be a lot of lookups which fail, if the inode# space is used
sparsely. And the inode# space is *often* used sparsely, if a file
system contains a lot of stuff that was put there in the original
image, followed by lots of creation and deletion of new files.
Instead of processing them numerically with a lookup each time, just
walk the hash buckets instead.
[fix locking typo reported by Dan Carpenter]
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
| H A D | nodemgmt.c | diff 5817b9dc9cc1225feedd9e1282707165fc64c384 Mon Feb 01 06:00:25 CST 2016 David Woodhouse <David.Woodhouse@intel.com> jffs2: Improve post-mount CRC scan efficiency
We need to finish doing the CRC checks before we can allow writes to
happen, and we currently process the inodes in order. This means a call
to jffs2_get_ino_cache() for each possible inode# up to c->highest_ino.
There may be a lot of lookups which fail, if the inode# space is used
sparsely. And the inode# space is *often* used sparsely, if a file
system contains a lot of stuff that was put there in the original
image, followed by lots of creation and deletion of new files.
Instead of processing them numerically with a lookup each time, just
walk the hash buckets instead.
[fix locking typo reported by Dan Carpenter]
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
| H A D | gc.c | diff 5817b9dc9cc1225feedd9e1282707165fc64c384 Mon Feb 01 06:00:25 CST 2016 David Woodhouse <David.Woodhouse@intel.com> jffs2: Improve post-mount CRC scan efficiency
We need to finish doing the CRC checks before we can allow writes to
happen, and we currently process the inodes in order. This means a call
to jffs2_get_ino_cache() for each possible inode# up to c->highest_ino.
There may be a lot of lookups which fail, if the inode# space is used
sparsely. And the inode# space is *often* used sparsely, if a file
system contains a lot of stuff that was put there in the original
image, followed by lots of creation and deletion of new files.
Instead of processing them numerically with a lookup each time, just
walk the hash buckets instead.
[fix locking typo reported by Dan Carpenter]
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|