From: nospam@needed.invalid   
      
   On Sun, 2/15/2026 6:35 PM, Lawrence D’Oliveiro wrote:   
   > On Sun, 15 Feb 2026 17:01:06 -0500, Paul wrote:   
   >   
   >> On Sun, 2/15/2026 3:23 PM, Lawrence D’Oliveiro wrote:   
   >>>   
   >>> On Sun, 15 Feb 2026 06:37:31 -0500, Paul wrote:   
   >>>   
   >>>> That's a failure to do the safety checks first (FSCK before   
   >>>> backup) ...   
   >>>   
   >>> Not sure why that would be necessary, unless you’re doing low-level   
   >>> access to the volume and bypassing the filesystem code in the   
   >>> kernel.   
   >>>   
   >>> Otherwise you can rely on the kernel to ensure the filesystem is   
   >>> fit to access -- that is the authoritative implementation of the   
   >>> filesystem-access code, after all.   
   >>   
   >> Do you remember the old SunOS OS and the file system there ? That   
   >> used to regularly tip over.   
   >>   
   >> And it used to take forever to start, and read the filesystem and   
   >> make sure it would work.   
   >   
   > We have journalled filesystems now.   
   >   
   > So, to get back to my original question, what was the need for “FSCK   
   > before backup”, again?   
   >   
      
   It's to make sure that when you read metadata from the file system,   
   it can successfully be used to put everything back.   
      
   The representation can be block-based (inodes/clusters), plus it also   
   has metadata for the location of files. This is what allows restoration   
   into a smaller partition at restore time. The file metadata allows switching   
   to file mode. Whereas the block-based part that records something, that's   
   only good enough by itself for block-based restoral into an identically   
   sized partition.   
      
   In terms of behavior, a restore that is block based only, reading the   
   backup is "smooth" and laying down the blocks is "smooth". Whereas if   
   you ask for the files to be placed into a smaller partition, at least   
   one side of the operation is noisy due to the need to randomly seek.   
   This could change, depending on the algorithm used for restoring   
   (whether it tries to defragment, or it lets things go-to-hell   
   on a restore in the file-by-file mode). But with sufficient file metadata   
   stored (at the end of the backup session), it can do just about   
   anything needed, during a restore.   
      
   In an era where we "constantly repair" filesystems, there should   
   be little chance of the "buildup of latent faults". It was   
   latent faults, like one file system problem layered on top   
   of a second file system problem, that caused filesystems to tip   
   over. And this is why, today, there is so much checking for   
   "clean" when the system starts. It's not only that the file   
   system is journaled, even for unjournaled filesystems the   
   amount of maintenance the filesystem receives, it's more   
   frequent. I seem to remember there might have been a policy   
   where a full fsck is only done every 100 boots or so. And if   
   we went back even further in time, there might have been   
   no scheduled fsck at all. It was up to the administrator   
   to do the fsck (and answer the questions, and the questions   
   were always "skill testing" so mere users wanted no part of that).   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)