Messages in this thread | | | Date | Wed, 21 Nov 2012 07:20:30 -0300 | Subject | Re: [RFC/PATCH 1/1] ubi: Add ubiblock driver | From | Ezequiel Garcia <> |
| |
On Tue, Nov 20, 2012 at 8:59 PM, richard -rw- weinberger <richard.weinberger@gmail.com> wrote: > On Tue, Nov 20, 2012 at 11:39 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote: >> Block device emulation on top of ubi volumes with read/write support. >> Block devices get automatically created for each ubi volume present. >> >> Each ubiblock is fairly cheap since it's based on workqueues >> and not on threads. >> >> Read/write access is expected to work fairly well because the >> request queue at block elevator orders block transfers to be space-effective. >> In other words, it's expected that reads and writes gets ordered >> to point to the same LEB. >> >> To help this and reduce access to the UBI volume, a 1-LEB size >> write-back cache has been implemented. >> Every read and every write, goes through this cache and the write is >> only done when a request arrives to read or write to a different LEB >> or when the device is released, when the last file handle is closed. > > Did you also benchmark your driver with two caches? > (One for reading and one for writing.) > By using two caches you can lower the amount of atomic LEB changes. > > Maybe it would be also good to ensure that an cache entry becomes not too old. >
Yes, I thought of this.
For now, I decided to keep the implementation as simple as possible.
Regards,
Ezequiel
| |