|
Linux Kernel
3.7.1
|
All Data Structures Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
|
Linux Kernel
3.7.1
|
Go to the source code of this file.
Macros | |
| #define | SOFT_LEBS_LIMIT 4 |
| #define | HARD_LEBS_LIMIT 32 |
Functions | |
| int | ubifs_garbage_collect_leb (struct ubifs_info *c, struct ubifs_lprops *lp) |
| int | ubifs_garbage_collect (struct ubifs_info *c, int anyway) |
| int | ubifs_gc_start_commit (struct ubifs_info *c) |
| int | ubifs_gc_end_commit (struct ubifs_info *c) |
| void | ubifs_destroy_idx_gc (struct ubifs_info *c) |
| int | ubifs_get_idx_gc_leb (struct ubifs_info *c) |
| void ubifs_destroy_idx_gc | ( | struct ubifs_info * | c | ) |
| int ubifs_garbage_collect | ( | struct ubifs_info * | c, |
| int | anyway | ||
| ) |
ubifs_garbage_collect - UBIFS garbage collector. : UBIFS file-system description object : do GC even if there are free LEBs
This function does out-of-place garbage collection. The return codes are: o positive LEB number if the LEB has been freed and may be used; o %-EAGAIN if the caller has to run commit; o %-ENOSPC if GC failed to make any progress; o other negative error codes in case of other errors.
Garbage collector writes data to the journal when GC'ing data LEBs, and just marking indexing nodes dirty when GC'ing indexing LEBs. Thus, at some point commit may be required. But commit cannot be run from inside GC, because the caller might be holding the commit lock, so %-EAGAIN is returned instead; And this error code means that the caller has to run commit, and re-run GC if there is still no free space.
There are many reasons why this function may return %-EAGAIN: o the log is full and there is no space to write an LEB reference for ->gc_lnum; o the journal is too large and exceeds size limitations; o GC moved indexing LEBs, but they can be used only after the commit; o the shrinker fails to find clean znodes to free and requests the commit; o etc.
Note, if the file-system is close to be full, this function may return %-EAGAIN infinitely, so the caller has to limit amount of re-invocations of the function. E.g., this happens if the limits on the journal size are too tough and GC writes too much to the journal before an LEB is freed. This might also mean that the journal is too large, and the TNC becomes to big, so that the shrinker is constantly called, finds not clean znodes to free, and requests commit. Well, this may also happen if the journal is all right, but another kernel process consumes too much memory. Anyway, infinite %-EAGAIN may happen, but in some extreme/misconfiguration cases.
| int ubifs_garbage_collect_leb | ( | struct ubifs_info * | c, |
| struct ubifs_lprops * | lp | ||
| ) |
ubifs_garbage_collect_leb - garbage-collect a logical eraseblock. : UBIFS file-system description object : describes the LEB to garbage collect
This function garbage-collects an LEB and returns one of the , , etc positive codes in case of success, %-EAGAIN if commit is required, and other negative error codes in case of failures.
| int ubifs_gc_end_commit | ( | struct ubifs_info * | c | ) |
| int ubifs_gc_start_commit | ( | struct ubifs_info * | c | ) |
ubifs_gc_start_commit - garbage collection at start of commit. : UBIFS file-system description object
If a LEB has only dirty and free space, then we may safely unmap it and make it free. Note, we cannot do this with indexing LEBs because dirty space may correspond index nodes that are required for recovery. In that case, the LEB cannot be unmapped until after the next commit.
This function returns %0 upon success and a negative error code upon failure.
| int ubifs_get_idx_gc_leb | ( | struct ubifs_info * | c | ) |
1.8.2