[continued from previous message]   
      
   > faulty. If puffs of smoke come from the PSU, it smells funny,   
   > unless there are reasons to suspect it, that isn't it.   
      
   I was surprised it said I needed 750 watt, but I thought better safe   
   than sorry   
      
   > *******   
   >   
   > Linux has write buffering. It's a FIFO of sorts.   
   > But, it has a weird behavior.   
   >   
   > If the source drive runs faster than the dest drive, we would   
   > normally expect the FIFO queue to fill up as time passes.   
   >   
   > The Linux one however, it does not write a damn thing until   
   > it is half full. Imagine we are doing our 10GB of writes before   
   > the wheels fall off. We could be thinking about our FIFO queue   
   > right now.   
   >   
   > The FIFO queue is likely at least, half full.   
   >   
   > The write buffering, normally in the design of those, the   
   > "size" of the queue is 1/8th to 1/10th of total system RAM.   
   >   
   > You're at 16GB, we'll call it 2GB then. That does not give   
   > an excuse for 10GB of writes to present a problem. Something   
   > could happen around the 2GB mark, say, or the 1GB mark (the   
   > half full point). But by the time we're copying 10GB, the   
   > FIFO Queue is full, it provides back pressure, and the reader   
   > process blocks until space is available in the FIFO Queue for   
   > more writes. After the transfer is "finished", it takes   
   > time for the queue to drain out to disk.   
   >   
   >      # [Manual option} Using a mount command for example   
   >   
   >      # When mounting your hard drives use -o sync which will   
   >      # turn off write buffering for the drive.   
   >   
   >      You can also set it up in your fstab:   
   >   
   >      /dev/sda1    /    ext4      sync    0   0   
   >   
   > One detail is, the automounter will already have mounted the volume.   
   >   
   > Maybe you could   "remount -o sync" to make it stop write buffering   
   > the particular mount point.   
   >   
   > Or, in this thread, you can stop an EXT4 from automounting,   
   > then you could do your own mount of the USB thing. And then   
   > one of the options would be the equal of   -o sync  kind of thing.   
   >   
   >     https://forums.linuxmint.com/viewtopic.php?t=456525   
   >   
   > That's udev, and other distros may be using autofs.   
   >   
   > By using   -o sync   for the USB device, that stops write buffering and   
   > makes all writes go directly to disk.   
   >   
   > *******   
   >   
   > The other possibility, is there is a temperature issue, but the   
   > drive heating up at the 10GB point, seems a bit too quick. It should   
   > take longer than that to heat/overheat the thing. So this is not   
   > likely to be the case.   
      
   I have successfully transferred larger folders eg. 50 Gb, but I usually   
   transfer in smaller parcels to avoid the possibility of failure. Just   
   now I successfully transferred 80 Gb from the NVME to the files disk. I   
   will do some more testing to try to get to the bottom of this problem.   
      
   >   
   > In general, you don't want to use  -o sync  for all USB devices.   
   > The USB flash sticks would work better without it, the HDD in enclosure,   
   > don't mind either way (the hardware has options that allow smooth operation   
   > with 512 byte writes (while the internal sectors are 4096 bytes on a 512e   
   > drive).   
   >   
   > I would be testing this with two different OSes here, to see if it is   
   > ecosystem-specific.   
      
   I can't use win10/11 since the files disk is formatted Ext4   
      
   >   
   >     Paul   
   >   
   >   
      
      
   --   
   Linux Mint 22.2   
   {I shot Felix and buried him}   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)