From: invalid@invalid.invalid   
      
   Mike Small  writes:   
   > 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?   
      
   It’d certainly be a bug in whichever layer didn’t propagate it, and it   
   would (almost certainly) affect sync in the same way, i.e. the sync   
   wouldn’t help in the presence of that (hypothetical) bug.   
      
   > 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.   
      
   ‘Fails’ isn’t really enough information to even speculate. Looking at   
   the behavior, any error message, and any kernel logs, might shed some   
   light on the situation.   
      
   --   
   https://www.greenend.org.uk/rjk/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)