delayed close on mtdblock

delayed close on mtdblock

[Alexander Stein]

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?

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein

SYS TEC electronic GmbH
August-Bebel-Str. 29
D-07973 Greiz

Tel: +49-3661-6279-0, Fax: +49-3661-6279-99
eMail:    Alexander.Stein@systec-electronic.com
Internet: http://www.systec-electronic.com

Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Jena, HRB 205563

Re: delayed close on mtdblock

[Artem Bityutskiy]

[-- 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 --]

Re: delayed close on mtdblock

[Joakim Tjernlund]

>
> 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?

Me too. I fixed a similar issue for mtdchar "[MTD] Only call mtd->sync() method in mtdchar close if opened for write."
in 2007 so the same should be applied for mtdblock

 Jocke

Re: delayed close on mtdblock

[Alexander Stein]

On Tuesday 10 January 2012 10:54:35 Artem Bityutskiy wrote:
> 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.

I had somethng like this in mind, but was unsure about possible side effects.

> Care to submit a
> patch?

I would gladly submit a patch, but I don't know where to get the R/O status. 
There is no struct file in this function like in the mtdchar case as Joakim 
wrote.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein

SYS TEC electronic GmbH
August-Bebel-Str. 29
D-07973 Greiz

Tel: +49-3661-6279-0, Fax: +49-3661-6279-99
eMail:    Alexander.Stein@systec-electronic.com
Internet: http://www.systec-electronic.com

Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Jena, HRB 205563

Re: delayed close on mtdblock

[Joakim Tjernlund]

>
> On Tuesday 10 January 2012 10:54:35 Artem Bityutskiy wrote:
> > 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.
>
> I had somethng like this in mind, but was unsure about possible side effects.
>
> > Care to submit a
> > patch?
>
> I would gladly submit a patch, but I don't know where to get the R/O status.
> There is no struct file in this function like in the mtdchar case as Joakim
> wrote.

hmm, I GUESSING you have to add file mode to struct mtd_blktrans_dev and
update mode in blktrans_open() so you can use it later on.

 Jocke

>
> Best regards,
> Alexander