locked
Slow disk performance in certain scenarios RRS feed

  • Question

  • I have a particular program that generate files and during that process appear to read the file attributes of a lot of other recently created files. To be more specific it convert code to C# using Visual Studio 2005 and during the creation of the C# files it reads the attribute of some of the C# files it has already created.

     

    This process used to take about a minute on XP, but after the installation of Windows 7, it takes about 30 minutes.

     

    I should mention that I have a new, considerably faster hard drive since the Windows 7 installation. I my first thought was that something was wrong with the new hard drive, but all tests I can do have come up with says the new hard drive is working fine and is much faster than the old one. It certainly "feel" a lot faster when browsing folders in Explorer.

     

    When I attach and use the old hard drive using USB, it completes the job in one minute. From what I can tell all the chipset drivers etc are up to date.

     

    Monitoring the file access using Microsoft/Sysinternal Process Monitor, I see a clear difference. On the old, slow, USB drive (that is performing well), I get a single line per file access. On the internal, new drive, I get 4 lines:

     

    devenv.exe 4928 QueryOpen FAST IO DISALLOWED

    devenv.exe 4928 CreateFile SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

    devenv.exe 4928 QueryNetworkOpenInformationFile SUCCESS CreationTime: 2010-11-23 16:33:04, LastAccessTime: 2010-11-23 16:33:04, LastWriteTime: 2010-11-23 16:33:04, ChangeTime: 2010-11-23 16:33:04, AllocationSize: 1601-01-01 00:00:00, EndOfFile: 1601-01-01 00:00:00, FileAttributes: A

    devenv.exe 4928 CloseFile SUCCESS

     

    I have tried all the different options with enabling write caching and disabling caching entirely for the drive in the Device Manager, but with no significant difference.

     

    I'm running out of ideas to try, hence this post, and any suggestions would be most welcome.

    - Why would (or what could cause) my fast internal drive be so much slower (25-30 times slower) than my slower USB connected drive, when the internal physical drive is at least 50% faster and performs much faster in general usage?

     

     

    Friday, November 26, 2010 1:24 PM

Answers

  • Microsoft support have come back to me now and the cause of this is the luafv.sys driver or "Least User Access File Virtualization". You can almost certainly experience the same behaviour in Vista as well.

    Apparently the driver monitors the entire system drive instead of only the system directory.

    It's unlikely Microsoft will fix this.

    A workaround if you do suffer from this scenario with poor performance on the C:\ drive is to create a second partition and work against that. Even if it is the same disk, FAST IO will then work on the second partition.

    • Marked as answer by krliuk Friday, February 25, 2011 5:33 PM
    Friday, February 25, 2011 5:33 PM

All replies

  • As a reference, this is what Process Monitor gives for the old drive:

     

    devenv.exe 4260 QueryOpen SUCCESS CreationTime: 2010-11-26 13:32:59, LastAccessTime: 2010-11-26 13:32:59, LastWriteTime: 2010-11-26 13:32:59, ChangeTime: 2010-11-26 13:32:59, AllocationSize: 8,192, EndOfFile: 5,939, FileAttributes: ANCI

    Friday, November 26, 2010 1:46 PM
  • Hi,

    Have you tried any Disk tools to cherk your Disk healthy status?

    You may try to update your Disk Firmware firstly or mainboard's driver, and Try it in Safe Mode.

    If the issue persists, please post your thread at MSND Forums.

    Tuesday, November 30, 2010 9:15 AM
  • Have you tried any Disk tools to cherk your Disk healthy status?

    You may try to update your Disk Firmware firstly or mainboard's driver, and Try it in Safe Mode.

    Yes, I have checked the health of the drive and there are no issues with the disk itself from what I can see. The disk performs excellent in everyday operations.

    I connected an identical (same SKU, same batch) drive via USB and it performed just fine, i.e about 25 times faster than the internal drive.

    Tuesday, November 30, 2010 1:38 PM
  • Further information:

    I have cloned my hard drive to an SSD (Crucial C300 with the latest firmware), but it too fails to access the files using FAST IO. Due to the raw speed of the SSD my task completes in 2.5 minutes, which although acceptable, is still double the time it took on a 5400 RPM disk on Windows XP.

    I have also removed my 7200 drive (30 minutes) and put it in an USB cradle and it now completed in a bit over 1.5 minutes and again I can see the FAST IO is working fine.

    To me this indicate there is an issue between Windows 7 and some driver for the internal SATA disk. Which driver would/could this be? The chipset driver? Some Microsoft driver?

     

    Monday, December 13, 2010 4:46 PM
  • Hi,

    make a xperf trace [1] to diagnostic HDD activity. You can find an alternative download link for xperf/WPT in my topic on msfn [2]. Please upload the XperfSlowIOcir.etl to your SkyDrive [3] and post a link here.

    I'll take a look at it.

    André

    [1] http://blogs.msdn.com/b/ntdebugging/archive/2009/08/17/xperf-to-investigate-slow-i-o-issues.aspx
    [2] http://www.msfn.org/board/index.php?showtopic=146919
    [3] http://social.technet.microsoft.com/Forums/en-US/w7itproui/thread/4fc10639-02db-4665-993a-08d865088d65
    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Monday, December 13, 2010 9:46 PM
  • I did two traces, one with the USB 7200 RPM disk and one with the SATA SSD. Both can be found here:

     

    http://cid-96848b1a69667c58.skydrive.live.com/redir.aspx?resid=96848B1A69667C58!141

     

    Thanks!

     

     

    Tuesday, December 14, 2010 11:13 AM
  • Try to disable Superfetch when the SSD is installed.

    What is this exe? ppj_ui.exe It causes a lot of IO activity.

    Also the Searchindexer (Windows Search) is doing a lot of READ_USN_JOURNAL Operations which take very long on the SSD.

    Are you using the Intel driver for your Intel(R) ICH8M-E/M SATA AHCI Controller or the MS drivers which are included in Windows? is the SSD running in AHCI oder IDE mode?


    André


    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Tuesday, December 14, 2010 2:58 PM
  • Disabled SupoerFetch and SearchIndexer - made no noticable difference.

    ppj_ui.exe is "Ice Porter", the program that convert SAL code to C#. It uses Visual Studio (devenv.exe) to do that. It is expected to cause lots of IO activity.

    I'm using the latest Intel drivers (Intel Rapid Storage. 9.6.0.1014, upgraded from 8.9.2.1002).

    The SSD is running in AHCI mode as was the previous disks. I could try changing it to IDE mode if the SSD supports that.

    Wednesday, December 15, 2010 3:56 PM
  • Running with the SSD in IDE mode made no significant difference.
    Wednesday, December 15, 2010 4:33 PM
  • I'm using the latest Intel drivers (Intel Rapid Storage. 9.6.0.1014, upgraded from 8.9.2.1002).
    try it with the included MS AHCI drivers.

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Wednesday, December 15, 2010 11:26 PM
  • Hmm, I'm not sure where to find the MS AHCI drivers or what the file is called.

    I tried to uninstall the device in the device manager and ticked the "delete driver software for this device", but when I rebooted, Windows reinstalled the latest Intel drivers automatically.

     

    Thursday, December 16, 2010 1:18 PM
  • Remove the Intel drivers, so that Windows uses the includes drivers.
    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Thursday, December 16, 2010 1:34 PM
  • The MS AHCI drivers didn't make any difference. Still slow.
    Thursday, December 16, 2010 5:38 PM
  • you should contact the MS support:

    http://support.microsoft.com/gethelp/default.aspx?content=ph;en-us;14019

    and request that an escalation engineer should look at the xperf traces.


    André


    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Thursday, December 16, 2010 8:20 PM
  • A case has been logged with Microsoft support and they are looking into it.

     

    It appears this is related to the C:\ partition only.

    If I create a second partition on the same physical hard drive, or on another internal or external disk, that partition is fast, and FAST IO is working. Even a Virtual hard drive located on C:\ is faster than accessing C:\ directly...

    I have tried variations of this on 5 different Windows 7 PCs now (different hardware and both 32 bit and 64 bit installations), and they all seem to have the same behaviour: FAST IO is not working on C:\ on Windows 7.

    Tuesday, January 25, 2011 1:27 PM
  • FAST/IO is not always possible. It is used when the data is in the Cache. This avoids the normal IO access (IRP generation). Fast/IO is described in the Windows Internals Book 5th Edition on page 873 if you  want to know more.

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Tuesday, January 25, 2011 3:20 PM
  • Yes, I understand that. In this case though, the files are created a fraction of a second before the first access (check if the file exists) is performed, so will (most likely) be cached.

    And the exact same scenario is working fine and using FAST IO on all the other partitions on all my test PCs, but not on the C:\ partition on any of the PCs.

    Tuesday, January 25, 2011 4:04 PM
  • Is the Multimedia Class Scheduler running during your tests?

     

    Tuesday, January 25, 2011 6:51 PM
  • I haven't stopped it and it starts automatically, so I assume it has been running.

    I stopped it now (and Windows Audio stopped at the same time), but there was no change in the file access performance and FAST IO was not being used.

    Wednesday, January 26, 2011 5:04 PM
  • Microsoft support have come back to me now and the cause of this is the luafv.sys driver or "Least User Access File Virtualization". You can almost certainly experience the same behaviour in Vista as well.

    Apparently the driver monitors the entire system drive instead of only the system directory.

    It's unlikely Microsoft will fix this.

    A workaround if you do suffer from this scenario with poor performance on the C:\ drive is to create a second partition and work against that. Even if it is the same disk, FAST IO will then work on the second partition.

    • Marked as answer by krliuk Friday, February 25, 2011 5:33 PM
    Friday, February 25, 2011 5:33 PM
  • This won't fix it? 

    sc config luafv start= disabled

    I rebooted successfully with it disabled.

     

    Friday, February 25, 2011 6:28 PM
  • this disables the Registry and File Virtualization and breaks the UAC.

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Friday, February 25, 2011 9:30 PM
  • I have been experiencing abysmal git speeds on Windows and recently tracked the source down to luafv.sys.  After completely disabling, my performance now is great.  The following script will completely disable luafv via a registry edit.  I would only do this on a development machine and I will not take responsibility if this breaks something on your machine -

    https://gist.github.com/cchamberlain/33e958177ed4d7174936

    Thursday, July 9, 2015 7:04 PM