Win7 DVD+RW UDF 2.50 vs UDF 2.01 format and backup speed

[MtheK]

  This isn't an MASM question per se, but this is the only forum I've found
that gives many legit answers to questions.

  While reading about the geo-magnetic superstorm of 1859 that melted
telegraph lines, I wondered if such a storm would destroy all our electronic
storage media, such as SDHC, USB, etc. since they all have metals?

  I decided to back up my external media to DVD+RWs as well (no metals in
them?). I changed my MASM DSNTODAY program to show the # of bytes in each
main DIR on a drive, so I could easily pack them to 4.37G.

  However, when I formatted it (as a USB flash drive) and let the default
of UDF 2.01 be used, the backup ran fine, until it got to a certain limit,
when it got exponentially slower and slower, where it was taking MINUTES
to do a subDIR that WAS working in about 10 seconds (in this particular
case, these subDIRs are all about the same size). It was about 20,000
files and about 2G in size.

  Running PROCMON, I found that a WRITE to something called $VMCB$ was the
last I/O operation until it finished and another file was processed. About
a dozen or so files were done until this WRITE occured again and the
super-long wait associated w/it. This "loop" then continued.

  I Ctl-C'd the copy; the window wouldn't close. Explorer hung; I would
get "preparing to eject..." and it hung.

  I decided to try formatting w/different UDFs. In my case, UDF 2.50 worked
perfectly (the only other one I tried). There was no detected slowdown that
I could see.

  Are there compatability issues w/doing this? Any other ramifications?
Selected data all seemed readable. I just didn't want this backup to take
DAYS, which I projected based on how much slower it kept getting.

  Thankx...

[MtheK]

  Final test results:


  Ran .bat(robocopy) against newly-formatted disc as UDF 2.01 - ran 8hr 12min!!! Speed:  134944 bytes/sec,  7.721M/min, 289/42095/3.708G. Eject OK.

  Ran my ADMIN MASM FIND (reads every DSN on the drive) - 40min. Hear clicking by itself until halfway; same as when slowed down during backup, then brief pause every 34 DSNs (I write every DSNs' PATH to the same line).

  Ran ADMIN 'DIR /s': 42095 files, 3990081212 bytes. Again, fast until halfway,
then 3sec pause after each . subDIR.


  Ran same .bat against same newly-formatted disc as UDF 2.50 - ran 1hr 20min!!! Speed:  830287 bytes/sec, 47.509M/min, 289/42095/3.708G. Eject OK.
- 6x FASTER than 2.01!
 
  Ran ADMIN FIND - 30min. Hear little/no clicking by itself (less-spread arm movement?) B 4 halfway, and almost no pauses, especially after halfway.

  Ran ADMIN 'DIR /s': 42095 files, 3990081212 bytes (same as UDF 2.01).
No pauses.

[dedndave]

i think they do something in the way of changing the order of reads and writes to reduce the noise

like - read sectors partially in reverse order
4, 3, 2, 1, 8, 7, 6, 5
something like that

[FORTRANS]

Hi,

   Nice testing.  Thanks for posting it.

Regards,

Steve N.

[Farabi]

i think they do something in the way of changing the order of reads and writes to reduce the noise

like - read sectors partially in reverse order
4, 3, 2, 1, 8, 7, 6, 5
something like that

No wonder it was very slow. A sector beeing read on the other wise reverse order. If you want to read sector 5 and then 4, you will need the DVD to turn around about 1 cycle, even it only took 1/6000 second, it still stlow on a file about 2 Gigabytes, if you can create a driver that do the otherwise, it will be very fast. Except the newest DVD drive hardwarely turn backward.

[MichaelW]

Could the noise and run-time variations be due to read errors and the need to reread and/or reconstruct the data from a CRC, or some such? Is there any way to monitor these errors?

[MtheK]

  That's a good question. In IBM M/F, the NCP (hardware to communicate over the network) has a RETRY limit (so many retries, so many times in a cycle) and that
would play HAVOC when trying to determine slow response time 'cause if it fixed itself ("CRC" was OK), we would never know why response time was sporatic occasionally unless we adjusted that limit.

  I will say, in my tests, I always started w/a fresh disc; in my case, a SONY DVD+RW, but perhaps the disc itself was flakey. I do know that they wear out when I use them in my burner for video from a TV for time-shifting in about a year, tho the burner will say that it can't read the disc. Perhaps on the PC, a RETRY limit exits, which could mess up response time. However, when I was fighting w/2.01
B 4 I knew about it, I went thru 5 discs from the same box of 10 when each one was super-slow until I stumbled on 2.50 when, again, from the same box but a fresh disc, it was much faster.

[dedndave]

you'd have to tear into the drivers
it would seem reasonable that they have functions that provide information
even if intended for troubleshooting

[Magnum]

Thanks for the post about the geomagnetic storm.

Code Select Expand


the Colaba observatory near Bombay, India. It is estimated that Dst would have been approximately -1750 nT.[10] Telegraph wires in both the United States and Europe experienced induced emf, in some cases even shocking telegraph operators and causing fires. Aurorae were seen as far south as Hawaii, Mexico, Cuba, and Italy — phenomena that are usually only seen near the poles. Ice cores show evidence that events of similar intensity recur at an average rate of approximately once per 500 years.


[MtheK]

  As an FYI, every repeated update/eject costs about 20M in un-detectable(?) disc space. I found this out after a few months, when a copy had various errors (DOS: CRC error; explorer: invalid source, no more space). Explorer/Properties said I had a lot of free space, and a 'DIR /s' said the same. However, this is indicated if you
r-click/Properties, then sel the Recording tab, and then Global Settings. It's a default setting.

  In my case, I then have to re-format the disc (DVD+RW in my case) and re-copy it
from my master copy. Then I can update it again (until next time).