diff --git a/doc/ubi.xml b/doc/ubi.xml index 13b8174..d912b8f 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -974,28 +974,7 @@ go to the mapped PEB.
The LEB map operation is available via the ubi_leb_map()
UBI kernel API function, or via the UBI_IOCEBMAP
volume character
device ioctl command. However, thie ioctl interface is available only starting
-from kernel version 2.6.29
The LEB map operation accepts the dtype
parameter which suggests
-UBI which type of data the LEB will contain. Namely, dtype
may be
-one of:
UBI_SHORTTERM
- the LEB will store short-term data,
- which means that it will be erased soon; UBI will map this LEB to a
- PEB with low erase counter, so it will grow relative to other PEB
- erase counters;UBI_LONGTTERM
- the LEB will store long-term data and
- will not be erased soon; UBI will map this LEB to a PEB with high erase
- counter, so it will go down relative to other PEB erase counters;UBI_UNKNOWN
- should be used most of the time, when
- you are not sure whether the data are long-term or short term.Bear in mind that dtype
is only a hint. Please, use
-UBI_UNKNOWN
if unsure. And note, UBI authors never really tested
-the effects of using UBI_SHORTTERM
and UBI_LONGTTERM
,
-so there is not guarantee they improve anything.
2.6.29
.
One of the possible use-cases of the LEB map operation is making sure the old LEB contents goes away forever. As it was explained in @@ -1109,8 +1088,6 @@ struct ubi_leb_change_req req; req.lnum = lnum_to_change; req.len = data_len; -req.dtype = UBI_LONGTERM; /* data persistency (may also be UBI_SHORTTERM - and UBI_UNKNOWN) */ fd = open("/dev/my_volume"); ioctl(fd, UBI_IOCEBCH, &req); write(fd, data_buf, data_len);