TLER is the Western Digital “feature” for making a hard drive give up trying to read/write before it normally would. This can be useful in a RAID environment in that a RAID controller is able to recover from a read/write error faster than an individual disk would since the RAID controller can consult the redundant data stored on the other (healthy) disks of the RAID array. Other manufactures have similar features, ERC in Seagate-speak, and CCTL on Samsung and Hitachi drives. For a more in-depth look check out the Wikipedia page for Time-Limited Error Recovery.

If a drive in a RAID array sits too long trying to read or write to a faulty area of the hard drive, the RAID controller may decide that life’s too short to wait for this obviously failing disk, and it will resolve this conflict by dropping the disk out of the array. Failing disks out of an array of course, is not a welcome behavior if that drive is not truly garbage, as additional drive failures could result in a complete loss of data. Unfortunately many things can trigger a hard disk drive to error and cause a delay returning information to the RAID controller. Drives that would be considered “good”, by most any other measure may be discarded and forced to be rebuilt into the array (assuming someone manually intervenes to accomplish this before the degraded RAID dies completely).

There is some debate, and a good deal of unhelpful information regarding how the GNU md (mdadm) RAID benefits or detriments from TLER. Here is an example of what I mean:
http://kerneltrap.org/mailarchive/linux-raid/2009/9/8/6389653. My take on it is that enabling TLER, although not required, may make the system move along smoother/quicker in the event of an error, and probably not cause me much worry in terms of data corruption.

Western Digital used to make available a tool named WDTLER.EXE that would allow you to enable and tweak this feature on your drives. They have since pulled the file from their website, but as with most things on the Internet, it’s still out there some where. A quick Google search for “WDTLER.ZIP” turns up promising results. Like many low level firmware utilities for hard disks or BIOS flashing, we’ll need to run WDTLER.EXE from a DOS boot disk. I don’t have a floppy drive, and even if I did, I’m really not sure where to find a floppy disk (last time I tried was amusing, then very annoying, and then slightly amusing again when I finally found a dusty box in a drug store).

Here are some instructions that I hope will be handy for people seeking a bootable DOS CD-ROM with WDTLER.EXE utilities.
Things you’ll need:

  • Vmware Server or Workstation (or VirtualBox, etc provided you know how to use it applicably)
  • A copy of WDTLER.ZIP (Try Google)
  • The file fdbasews.iso from http://www.freedos.org/freedos/files/
  • 7-Zip from http://www.7-zip.org/ (or something else that can extract files from an ISO image
  • The version of the executables in WDTLER.ZIP that I’m working with can be identified with the following hashes.

    WDTLER.EXE
    MD5 : f74947e95d4d416b15eb8c9ed4210477
    SHA1 : e56b42244da70e1df03860b3505bac667f122ad6
    SHA256: 9401d94fc514aa8128bbba743f92e28eeb84a7365c71e91a091d02c2b46b6bce

    HDACCESS.EXE
    MD5 : 2ced2d76106d3d52b3885a0f1d9225bf
    SHA1 : 8fdfc31707d6f3b391cf498a7de494424866529a
    SHA256: b6eb1edb56c9c481335ff4a7e0f9f0009c1ad3a7fb6e6593071cd5488e01ca52

    Make a temporary directory to work in. I’m using C:\makecd in the examples below.

    Create a CD-ROM containing the WDTLER utilities:

  • Make the directory C:\makecd
  • With 7-zip extract the file \isolinux\buildcd\mkisofs.exe from the FreeDos ISO (fdbasews.iso) and place it in C:\makecd
  • Make a sub-directory called contents in C:\makecd\contents
  • Extract the contents of WDTLER.ZIP into C:\makecd\contents
  • You should now have something like this:


    Open a command prompt, and change into the C:\makecd directory, then run mkisofs as show below.

    C:\>cd\makecd
    C:\makecd>mkisofs -o freedostler.iso -l ./contents/*
    Total translation table size: 0
    Total rockridge attributes bytes: 0
    Total directory bytes: 0
    Path table size(bytes): 10
    Max brk space used df30
    272 extents written () MB)

    If you like, open the newly created freedostler.iso file in 7-Zip to make sure everything looks ok.

    Now open VMWare and create a new Virtual machine (the type shouldn’t really matter). Adjust the virtual machine settings to use an ISO image in the virtual CD-ROM drive. Use the fdbasews.iso we downloaded from FreeDOS (and not the ISO file we just created).

    Next add a virtual Floppy drive. When prompted choose “Create a blank floppy image”.

    Save the blank floppy image as “freedos_tler.img” in the C:\makecd directory.

    Boot the new Virtual Machine. You should end up at the FreeDOS boot screen. Hit enter (or 1, followed by enter), to continue.

    At the next FreeDOS boot menu choose option 5 “FreeDOS Live CD only”.

    At the FreeDOS DOS prompt type format B: and hit enter. The A: drive is actually the El ToritoCD-ROM boot image pretending to be a floppy drive, B: should be our virtual VMWare floppy drive. You will get prompted for a volume label, I went with “FREEDOS”, although you could just hit enter.

    Next type sys B: and hit enter. The “sys” command creates a boot record on the target drive and copies COMMAND.COM to the root directory (Ah!, old DOS knowledge earning it’s space in my brain).

    OK, leave the FreeDOS virtual machine running, but go back to the VMWare settings, and change the CD-ROM ISO image to C:\makecd\freedostler.iso (the ISO file we created earlier).

    At the FreeDOS command prompt type copy X:\*.* B: and hit enter.

    Now reboot the Virtual Machine, since freedostler.iso isn’t yet a bootable image, we should boot off the newly created floppy disk image. On systems without an AUTOEXEC.BAT file, you’ll get this annoying prompt for date and time on each boot. You can fix that by creating an empty AUTOEXEC.BAT file. I show off my arcane DOS knowledge below to accomplish this.

    AUTOEXEC.BAT or no AUTOEXEC.BAT, the important thing is we tested that we have a bootable floppy disk image. Here’s the big idea at this point. we just created a bootable floppy disk image that contains the WDTLER utilities. We first created the non-bootable CD-ROM ISO with the WDTLER utilities so that we’d have an easy way of copying them to a floppy image in VMWare without having to mess with networking drivers and software. With the WDTLER files copied to the bootable floppy disk we no longer need the non-bootable freedostler.iso, so go ahead and erase it.

    We’re now going to re-create freedostler.iso using our “freedos_tler.img” disk image as our bootable Torito image.

    C:\makecd>mkisofs -r -b freedos_tler.img -o freedostler.iso -l *
    Size of boot image is 2880 sectors -> Emulating a 1440 kB floppy
    Total translation table size: 2048
    Total rockridge attributes bytes: 341
    Total directory bytes: 0
    Path table size(bytes): 10
    Max brk space used e980
    897 extents written (1 MB)

    This copies a backup of our work to the the CD-ROM ISO as well. Since we’re going to waste a whole CD writing data that could easily fit on a floppy, we might as well make something slightly more useful. You should now have a bootable freedostler.iso file. Test it in VMWare to make sure everything is working. The WDTLER utility files should show up in the A:\ directory.

    Here’s a much more convenient approach using Ultimate Boot CD that leaves me wondering why I bother blogging anything at all: http://shifteightgeneration.com/content/wdtler-fix-tler-setting-wd-desktop-hard-drives, nice job Steve.

    Published on :Posted on

    Post your comment

    Your email address will not be published. Required fields are marked *

    This site uses Akismet to reduce spam. Learn how your comment data is processed.