Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 305154
b: refs/heads/master
c: 4415626
h: refs/heads/master
v: v3
  • Loading branch information
Artem Bityutskiy committed May 20, 2012
1 parent 054a8aa commit dd41fc9
Show file tree
Hide file tree
Showing 4 changed files with 15 additions and 12 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: a65a0eb6d198e058687a9214683bd1c418f20d39
refs/heads/master: 4415626732defb5a4567a0a757c7c5baae7ca846
9 changes: 1 addition & 8 deletions trunk/drivers/mtd/ubi/wl.c
Original file line number Diff line number Diff line change
Expand Up @@ -41,12 +41,6 @@
* physical eraseblocks with low erase counter to free physical eraseblocks
* with high erase counter.
*
* The 'ubi_wl_get_peb()' function accepts data type hints which help to pick
* an "optimal" physical eraseblock. For example, when it is known that the
* physical eraseblock will be "put" soon because it contains short-term data,
* the WL sub-system may pick a free physical eraseblock with low erase
* counter, and so forth.
*
* If the WL sub-system fails to erase a physical eraseblock, it marks it as
* bad.
*
Expand All @@ -70,8 +64,7 @@
* to the user; instead, we first want to let users fill them up with data;
*
* o there is a chance that the user will put the physical eraseblock very
* soon, so it makes sense not to move it for some time, but wait; this is
* especially important in case of "short term" physical eraseblocks.
* soon, so it makes sense not to move it for some time, but wait.
*
* Physical eraseblocks stay protected only for limited time. But the "time" is
* measured in erase cycles in this case. This is implemented with help of the
Expand Down
5 changes: 2 additions & 3 deletions trunk/fs/ubifs/super.c
Original file line number Diff line number Diff line change
Expand Up @@ -814,9 +814,8 @@ static int alloc_wbufs(struct ubifs_info *c)
}

/*
* Garbage Collector head likely contains long-term data and
* does not need to be synchronized by timer. Also GC head nodes are
* not grouped.
* Garbage Collector head does not need to be synchronized by timer.
* Also GC head nodes are not grouped.
*/
c->jheads[GCHD].wbuf.no_timer = 1;
c->jheads[GCHD].grouped = 0;
Expand Down
11 changes: 11 additions & 0 deletions trunk/include/mtd/ubi-user.h
Original file line number Diff line number Diff line change
Expand Up @@ -358,7 +358,17 @@ struct ubi_rnvol_req {
* requests.
* @lnum: logical eraseblock number to change
* @bytes: how many bytes will be written to the logical eraseblock
* @dtype: pass "3" for better compatibility with old kernels
* @padding: reserved for future, not used, has to be zeroed
*
* The @dtype field used to inform UBI about what kind of data will be written
* to the LEB: long term (value 1), short term (value 2), unknown (value 3).
* UBI tried to pick a PEB with lower erase counter for short term data and a
* PEB with higher erase counter for long term data. But this was not really
* used because users usually do not know this and could easily mislead UBI. We
* removed this feature in May 2012. UBI currently just ignores the @dtype
* field. But for better compatibility with older kernels it is recommended to
* set @dtype to 3 (unknown).
*/
struct ubi_leb_change_req {
__s32 lnum;
Expand All @@ -369,6 +379,7 @@ struct ubi_leb_change_req {

/**
* struct ubi_map_req - a data structure used in map LEB requests.
* @dtype: pass "3" for better compatibility with old kernels
* @lnum: logical eraseblock number to unmap
* @padding: reserved for future, not used, has to be zeroed
*/
Expand Down

0 comments on commit dd41fc9

Please sign in to comment.