From: BitTwister@mouse-potato.com   
      
   On Tue, 27 Sep 2022 13:15:25 -0400, Mike Small wrote:   
   > Richard Kettlewell  writes:   
   >   
   >> Rich  writes:   
   >>> Mike Small  wrote:   
   >>>> I'm noticing places in both Slackware's installer and   
   >>>> debian-installer where a mkfs run is immediately followed by a   
   >>>> sync...   
   >>>>   
   >>>> [snip]   
   >>>>   
   >>>> Is this just a known thing among those who've been around?  mkfs   
   >>>> isn't truly done and with all bits on disk when it exits?   
   >>>   
   >>> It is not just mkfs.  Linux caches writes in RAM, with the data   
   >>> actually being committed to disk some time later.   
   >>>   
   >>> If you want to be sure a write has hit the disk (note, due to on disk   
   >>> caches, you can never really be /sure/) you need to tell the kernel to   
   >>> write the cached RAM data out to disk -- that is what 'sync' does.   
   >>>   
   >>> Those sync's are not strictly necessary, but are likely present for   
   >>> safety's sake.  Run the mkfs, then try to make certian all the writes   
   >>> have been at least sent to the disk controller.   
   >>   
   >> They are redundant, at least for ext4, since mkfs.ext4 calls fsync on   
   >> the target device. I’m not going to check other filesystems but the   
   >> situation is likely to be the same.   
   >   
   > Suppose the ext4 fs was on an encrypted volume on top of a dm raid,   
   > i.e. two levels of device mapper. Is it possible that the fsync on the   
   > crypt device wouldn't carry through to the raid?   
   >   
   > My reason for looking at what Slackware and Debian do came from seeing a   
   > script at work fail intermittently. It does the following:   
   >   
   >     1. create an ext4 fs   
   >     2. mount it   
   >     3. copy files to it   
   >     4. unmount it   
   >     5. remount it at a different point   
   >     6. access copied files.   
   >   
   > This sequence sometimes fails at step 5 and rarely in step 6.  Typically   
   > it does not fail. Could be a hardware error or something else (I'm   
   > always looking for a new thing to blame udevd on, for instance), but it   
   > sure would be nice (but not reassuring) if only a sync or two was what   
   > was needed.   
   >   
      
   I suggest adding test return status after each step to help find the problem.   
      
   Example:   
      
     if [ $? -ne 0 ] ; then   
       _code=$?   
       echo "Return status $_code is not 0 for command   
       command_executed_here   
       "   
       exit $_code   
     fi   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)