Re: delayed close on mtdblock

[Artem Bityutskiy <dedekind1@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

On Wed, 2012-01-04 at 15:18 +0100, Alexander Stein wrote:
> Hello,
> 
> I observed an somewhat interesting situation regarding mtdblock. I have a NOR-
> Flash with several mtd partitions. One holds the configuration from the 
> bootloader and another one contains UBI/UBIFS.
> During bootup I attach UBI and mount UBIFS, no problems so far. To read the 
> bootloader coniguration I open the corresponding mtdblock with O_RDONLY, do an 
> lseek, read and close it afterwards, nothing special. But I noticed the 
> close() call take >1s which seems to far big, as there is nothing to be 
> written into this mtdblock device.
> I digged into the kernel and get to mtdblock_release(). I can see that 
> write_cached_data does nothing as the cache is clean. But mbd->mtd->sync 
> (cfi_amdstd_sync in my case) takes a while because the chip state is currently 
> FL_ERASING. The retry loop is taken several times before exiting the function.
> If I don't mount UBIFS there is no such delay. I'm wondering if there is 
> actually a need to sync the chip if the cache is clean. Can someone explain 
> this to me?

Most probably this is because NOR flash erase is very slow. You probably
do writes to the UBIFS partition, which initiates many erase operations.
When you close the mtdblock device - it syncs the flash chip which
blocks until the pending erase operations initiated by UBIFS finish
(because these are 2 partitions on the same chip).

I think the quick fix for you would be to avoid calling mtd->sync() in
mtdblock if the device is R/O - makes no sense anyway. Care to submit a
patch?

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]