From: robin_listas@es.invalid   
      
   On 15/10/2018 23.26, bad sector wrote:   
   > On 10/15/18 8:52 AM, Carlos E.R. wrote:   
   >> On 15/10/2018 04.59, bad sector wrote:   
   >>> On 10/14/2018 10:14 PM, Carlos E.R. wrote:   
   >>   
   >>   
   >>>> Please paste the exact command with output   
   >>>   
   >>> This would be a typical command (as root)   
   >>>   
   >>> dd if=/dev/sda2 of=/mnt/p02-backup-iso.dd   
   >>>   
   >>> I get output when it completes OK, such as blocks in & blocks out but   
   >>> when it fails everything freezes & locks up, a hard reset is then the   
   >>> only way out.   
   >>   
   >> Then try this way:   
   >>   
   >> dd if=/dev/sda2 of=/mnt/p02-backup-img.dd oflag=direct bs=16M   
   >   
   > that worked, much obliged.   
      
   :-)   
      
   >   
   >   
   >> (side note: it is not an ISO image)   
   >   
   > manner of speaking, OK, it's just a bit4bit copy   
   >   
   > i put .dd as an extension, tells me how i made it   
      
   I know. But I reserve the name "iso" to those images that contain an   
   iso9660 filesystem. Being picky ;-)   
      
      
   >> Rationale for the options:   
   >>   
   >> direct  makes dd bypass the cache. The disk image will not be cached by   
   >> the kernel, eating most cache memory used by other processes, and making   
   >> the entire system run slow. I use this method on writing to USB sticks   
   >> and it is actually faster.   
   >>   
   >> bs  by default dd writes blocks of 512 bytes, which is slow; and worse   
   >> once the cache is disabled.   
   >   
   > is Suse more susceptible to such problems then?   
      
   Not that I know. Maybe some choice of swapiness or some such setting   
   makes it more susceptible, something about how disk cache is employed.   
      
   For example, if the machine has less RAM, it would hit this problem   
   earlier. If the memory assigned to cache per disk is limited somehow (I   
   do not know how), it would, or might, not.   
      
   I do not "use" TW, yet I concocted that dd line for use when writing   
   images to USB sticks. Someone was writing to several sticks at the same   
   time and the machine would crawl on its knees - WTF? Just writing to a   
   slow device, an operation that is not CPU intensive task at all?   
      
   My guess is, that any Linux machine should benefit with "oflag=direct   
   bs=16M". But I don't use other Linuxes, so I don't know for certain.   
      
      
   Notice that any big file copy would have a similar problem. Like copying   
   movies.   
      
   On the other hand, writing many small files might be worse this way.   
      
      
   Note: it might be possible to create a user menu entry for 'mc' to copy   
   large files using dd and this trick. Maybe one day I'll think about it :-)   
      
   --   
   Cheers, Carlos.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)