From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Heimpold <mhei@heimpold.de>
Date: Wed, 22 May 2013 20:32:12 +0200
Subject: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is
	physically stored
In-Reply-To: <519CE560.50105@newflow.co.uk>
References: <1369078482-5863-1-git-send-email-mhei@heimpold.de>
	<456389491.x65y6Gi2JO@kerker> <519CE560.50105@newflow.co.uk>
Message-ID: <22450137.H1yK7buv94@kerker>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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