All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Heimpold <mhei@heimpold.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
Date: Wed, 22 May 2013 20:32:12 +0200	[thread overview]
Message-ID: <22450137.H1yK7buv94@kerker> (raw)
In-Reply-To: <519CE560.50105@newflow.co.uk>

Hi,

> > ...
> > fw_setenv state=2
> > dd if=... of=/dev/mmcblk0...
> > fw_setenv state=1
> > ...
> > reboot
> 
> Not sure what final "OS" environment you're running, but I would think
> that "reboot" would sync for you ?

I'm using OpenWRT and reboot links to the busybox implementation.
This implemenetation calls sync when I traced it correctly.

According to "man 2 sync":

<quote>
DESCRIPTION
       sync() causes all buffered modifications to file metadata and data to be written to the underlying file systems.
</quote>

When I use fw_setenv with /dev/mmcblk0, that means with a block device directly,
then I have a problem matching the "filesystem layer" of the description above with
the "block layer" which I am using.

Futhermore another quote from the very same man page:
<quote>
BUGS
       ...sync() schedules the writes, but may return before the actual writing is done.  However, since version  1.3.20  Linux
       does actually wait.  (This still does not guarantee data integrity: modern disks have large caches.)
</quote>

So it seems to me, that calling "sync" doesn't do the job.

When looking at "man 2 fsync" I read 
<quote>
... This includes writing through or flushing a disk  cache  if
present.  The call blocks until the device reports that the transfer has completed....
</quote>

This looks much better.

However, I did not trace the call chain in linux kernel down to the block layer yet.
Maybe I should.

BR, Michael

  reply	other threads:[~2013-05-22 18:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20 19:34 [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored Michael Heimpold
2013-05-21 12:47 ` Wolfgang Denk
2013-05-21 17:34   ` Michael Heimpold
2013-05-22 14:32     ` Mats Kärrman
2013-05-22 15:33     ` Mark Jackson
2013-05-22 18:32       ` Michael Heimpold [this message]
2017-07-25  0:42 ` [U-Boot] " Tom Rini
  -- strict thread matches above, loose matches on Subject: below --
2017-07-13 13:11 [U-Boot] [PATCH] " Vincent Prince
2017-07-14  9:07 ` Vincent Prince

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=22450137.H1yK7buv94@kerker \
    --to=mhei@heimpold.de \
    --cc=u-boot@lists.denx.de \
    /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.