XPost: alt.windows7.general   
   From: nospam@needed.invalid   
      
   On 4/28/2024 3:06 AM, JJ wrote:   
   > On Sat, 27 Apr 2024 17:04:57 +0200, R.Wieser wrote:   
   >> Hello all,   
   >>   
   >> On a machine runnung XPsp3 :   
   >>   
   >> A while ago  tried to copy a couple of 1...4 GB files to an USB stick, and   
   >> it threw the "delayed write failed" error (after a couple of hundred MByte),   
   >> after which the machine froze and I had to power-cycle it to get it to   
   >> respond again (not even the task-manager wanted to come up).   
   >>   
   >> A bit of googeling gave me the answer : unticking "Enable write caching on   
   >> the disk" - even though that was in a section that was grayed out because   
   >> its parent, "Optimize for performance", wasn't selected ("Optimize for quick   
   >> removal" was).   
   >>   
   >> No, the question is not why I had to untick something in a grayed-out   
   >> section, don't worry. :-)   
   >>   
   >> My question is even worse than that :   
   >>   
   >> Does anyone know (or have a link to an MS article to) why that the "delayed   
   >> writing" (which I assume was still doing its job) causes such a big problem   
   >> ?   
   >>   
   >> And don't worry, its just curiosity.  There is nothing hanging on the   
   >> answer.   
   >>   
   >> Regards,   
   >> Rudy Wieser   
   >   
   > From MSDN:   
   >   
   > ERROR_LOST_WRITEBEHIND_DATA   
   > 596   
   >   
   > {Delayed Write Failed} Windows was unable to save all the data for the file   
   > %hs. The data has been lost. This error may be caused by a failure of your   
   > computer hardware or network connection. Please try to save this file   
   > elsewhere.   
   >   
   > ...   
   >   
   > My hunch tells me its due to hardware/firmware level I/O handling bug/glitch   
   > or limitation on the storage device side. If the device was plugged to the   
   > front panel port, try plugging it directly to the back panel port without   
   > using any extension cable to avoid any interference.   
   >   
      
   You can use any mechanism which slows down the ability to write,   
   to trigger that error. Running WinXP out of Pool Memory, with a   
   persistent pest, is enough to do it. Other later OSes, the Pool Memory   
   arch changed, and there are gobs of Pool Memory to go around. This   
   makes it a lot harder to attack later Windows using Pool as your lever.   
      
   It is otherwise, pretty difficult to get fine enough control,   
   to "engineer" a delay write failure. For example, if a hard drive   
   is struggling with a bad sector (doing retries for 7-10 seconds and   
   ignoring input), and a write is pending, between 10-second attempts on   
   the sector, the OS can slide in the write request and it gets done   
   before it is too late. With clever choices for timeout constants,   
   you won't be seeing the error you had hoped for.   
      
   It really requires a "path delay", a "velocity problem", to throw   
   that error. That's why the Pool Pressure method works so well.   
   The program applying the pressure, increases the pressure over   
   a 12 hour period, and eventually just the right amount of   
   tourniquet is applied to trigger a write failure (by the   
   write taking too long to complete).   
      
   *******   
      
   If you have the time to wait (heat death of the universe),   
   try and create 4 billion files in an NTFS folder. I've tried   
   up to the 4 million mark and noticed that NTFS is slowing   
   down significantly. How long would it take to get to four billion ?   
   Would you start seeing "Delay Write Fail" somewhere before you   
   get to four billion ? This would take a while to test. Since   
   NTFS files can live in the $MFT (1KB entries), four billion files   
   should fit into a 4TB hard drive holding nothing but an MFT.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)