I have tested this extreme case(No free PEBs left after creating test volumes)
on different type of machines for 100 times. The biggest number of attempts are
shown below:
x86_64 arm64
2-core4 4
4-core8 4
8-core4 4
So, setting the
- Ursprüngliche Mail -
>> Do you have numbers how many attempts were needed to get a free block?
> I tested it dozens of times. The biggest number of attempts I've ever had so
> far
> is 6. In most cases, it only takes 2 or 3 times.
So raising the retry count to, let's say, 10 would work
> You send this patch three times, I guess your mail setup has issues? :-)
Sorry, I thought I hadn't sent the first two e-mails. (The Patch work website
refreshes slowly)
> Do you have numbers how many attempts were needed to get a free block?
I tested it dozens of times. The biggest number of
- Ursprüngliche Mail -
> Von: "chengzhihao1"
> An: "richard" , "yi zhang"
> CC: "linux-mtd" , "linux-kernel"
>
> Gesendet: Donnerstag, 1. August 2019 11:13:20
> Betreff: 答复: [PATCH RFC] ubi: ubi_wl_get_peb: Replace a limited number of
> attempts with polling while getting PEB
> I
I don't quite understand why a limited number of attempts have been made to get
a free PEB in ubi_wl_get_peb (in fastmap-wl.c). I proposed this PATCH with
reference to the implementation of ubi_wl_get_peb (in wl.c). As far as I know,
getting PEB by polling probably won't fall into soft-lockup.
Running pressure test io_paral (A pressure ubi test in mtd-utils) on an
UBI device with fewer PEBs (fastmap enabled) may cause ENOSPC errors and
make UBI device read-only, but there are still free PEBs on the UBI
device. This problem can be easily reproduced by performing the following
steps on a
6 matches
Mail list logo
