Re: ubi/ubifs performance comparison on two NAND devices

[Steve deRosier <derosier@gmail.com>]

On Thu, Feb 28, 2019 at 8:41 AM Tim Harvey <tharvey@gateworks.com> wrote:
>
> Ok, thanks for the pointer. Is there a sysfs node that contains all of
> those? I didn't see anything obvious. I can printk them for comparison
> but I don't see this as a raw nand issue, I see it as a ubi/ubifs
> issue. There is something going on at the ubi/ubifs layer that makes
> the Cypress FLASH very slow for the ubi scan that occurs on attach and
> the UBIFS resize that occurs on first mount.

I don't follow your assertion. IMHO, if it were at the ubi/ubifs
layer, the time it takes should be symmetrical for both your flashes.
Perhaps you're saying "I don't believe it has to do with the hardware
layer."? Maybe. Though I suggest looking at all layers and prove
things beyond a reasonable doubt, otherwise you're going to likely
spend an inordinate amount of time looking in the wrong place.

UBIFS sits on top of UBI. Which sits on top of the raw flash driver.
Which sits on top of whatever bus or SoC driver that may be necessary
(maybe there, maybe not). Which then sits on the actual hardware.
Unless you have another method of testing the raw flash driver, and
through the exact same pathway the UBI is using, I don't think you've
eliminated it. The most likely scenario is it is doing something
pathological with your flash. Looking at the timing parameters it
chooses is a good start, since IIRC, you've said you're not choosing
them, you're letting the driver do so.

Let's give an example - maybe with the new flash you've got a
write-protect GPIO setup and that wasn't in the old configuration. And
let's say it takes too long to toggle due to some really bad
setup/hold times set by default because they're not configured. And
the NAND driver writer implemented it with gpiolib, and toggles it
even on a read, and there's some horrible timing bug in gpiolib... And
since UBIFS touches every page during the scan...  boom - crazy extra
time. This is a totally made up example, but it illustrates the type
of odd non-obvious interaction that could happen even if you think
everything is fine with the raw nand.

Personally, I'd shove a bus analyzer on your NAND and take a look if
the bus sequences it does on the "good" vs the "bad" chip case are
similar. Likely that will tell you exactly why it takes so long which
in turn will lead you to exactly what the problem is.

If I had to guess, either there is a configuration error OR the nand
driver you're using is choosing bad defaults OR there's a particular
pathway in the driver that the UBI is exercising that isn't what a raw
access would exercise and there's a funky bug there.

Remember though - I'm not saying it isn't a bug in the UBI or UBIFS
code, I just don't feel you've eliminated the more likely spot first:
the code that actually deals with the chip in question. Go examine and
understand the NAND driver and printk those timing parameters.

- Steve

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/