From: Artem Bityutskiy <dedekind@infradead.org>
To: Nancy <nancydreaming@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [RFC] slight UBI scan time improvement
Date: Wed, 23 Apr 2008 15:23:55 +0300 [thread overview]
Message-ID: <1208953435.11721.60.camel@sauron> (raw)
In-Reply-To: <bae050c10804230351s699a851bmb950a18b22ae8e54@mail.gmail.com>
On Wed, 2008-04-23 at 18:51 +0800, Nancy wrote:
> Will you please explain why need leb_read_lock()?
This locks the LEB and prevent concurrent I/O to this LEB. E.g., we do
not want a situation when one process unmaps an LEB while another
process is writing to it.
That was probably overkill, but I implemented per-LEB r/w locking. This
is similar to rw semaphore in Linux. It means that several processes may
simultaneously read for this LEB, but only one process at a time may
write (or unmap).
> If I ummap a leb(only operate the eba table, do not do
> ubi_wl_put_peb() ), then, what will that PEB belong to? wl->free,
> wl->used, wl->prot.pnum, wl->prot.aec, wl->scrub? What will happen to
> that PEB?
If you unmap it you have to clean the corresponding EBA table record and
return it to the WL unit.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2008-04-23 12:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 16:42 [RFC] slight UBI scan time improvement Artem Bityutskiy
2008-04-22 17:28 ` Bruce_Leonard
2008-04-22 18:07 ` Artem Bityutskiy
2008-04-23 7:15 ` Nancy
2008-04-23 7:32 ` Artem Bityutskiy
2008-04-23 8:01 ` Nancy
2008-04-23 8:16 ` Artem Bityutskiy
2008-04-23 9:07 ` Nancy
2008-04-23 9:13 ` Artem Bityutskiy
2008-04-23 10:51 ` Nancy
2008-04-23 10:57 ` Nancy
2008-04-23 12:24 ` Artem Bityutskiy
2008-04-23 12:23 ` Artem Bityutskiy [this message]
2008-04-23 7:38 ` Hamish Moffatt
2008-04-23 8:13 ` Matthieu CASTET
2008-04-23 8:21 ` Artem Bityutskiy
2008-04-23 9:21 ` Matthieu CASTET
2008-04-23 9:27 ` Artem Bityutskiy
2008-04-23 12:40 ` Hamish Moffatt
2008-04-23 12:57 ` Artem Bityutskiy
2008-04-23 13:42 ` Hamish Moffatt
2008-04-23 14:09 ` Artem Bityutskiy
2008-04-24 1:53 ` Hamish Moffatt
2008-04-24 6:21 ` Artem Bityutskiy
2008-04-24 7:02 ` Hamish Moffatt
2008-04-24 0:10 ` Hamish Moffatt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1208953435.11721.60.camel@sauron \
--to=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nancydreaming@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox