All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Stein <alexander.stein@systec-electronic.com>
To: linux-mtd@lists.infradead.org
Subject: delayed close on mtdblock
Date: Wed, 04 Jan 2012 15:18:21 +0100	[thread overview]
Message-ID: <14259449.DIx1JTusJU@ws-stein> (raw)

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

             reply	other threads:[~2012-01-04 14:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-04 14:18 Alexander Stein [this message]
2012-01-10  8:54 ` delayed close on mtdblock Artem Bityutskiy
2012-01-10  9:01   ` Joakim Tjernlund
2012-01-10  9:22   ` Alexander Stein
2012-01-10  9:30     ` Joakim Tjernlund

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=14259449.DIx1JTusJU@ws-stein \
    --to=alexander.stein@systec-electronic.com \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.