Announcement

Collapse
No announcement yet.

Disable 8.3

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Disable 8.3

    I just ran across this in StackOverFlow ...

    NTFS actually will perform fine with many more than 10,000 files in a directory as long as you tell it to stop creating alternative file names compatible with 16 bit Windows platforms. By default NTFS automatically creates an '8 dot 3' file name for every file that is created. This becomes a problem when there are many files in a directory because Windows looks at the files in the directory to make sure the name they are creating isn't already in use. You can disable '8 dot 3' naming by setting the NtfsDisable8dot3NameCreation registry value to 1. The value is found in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem registry path. It is safe to make this change as '8 dot 3' name files are only required by programs written for very old versions of Windows.

    A reboot is required before this setting will take effect.
    I've seen the performance hit of having as many as 50K files in a directory. But this is the first time I've ever seen the performance hit tied to the 8.3 file name creation.

    Has anyone done what was suggested above, and found that performance improved significantly?

    As I recall, deleting a folder with many files was particularly slow. I don't see how removing 8.3 names would change that?

  • #2
    Now that I've seen the disable-8.3 suggestion, it seems to be suggested more often than I thought.

    Here's another thread, from StackExchange, that gives the 8.3 suggestio, and others.... increasing the ntfs mtz size and disabling last access time on all files

    Comment


    • #3
      Interesting notes. Thanks, Gary!

      I'm going to have to try some of my "standard" file timestamp code to see what happens if 8.3 is turned off, and then set a file's "access time".

      I'm traveling for a few days, so can't commit to WHEN I'll get to it...
      -John

      Comment


      • #4
        I can not answer whether it will speed thing up, but be aware that it may break other programs that still use 8dot3

        Namely PBwin 9 see last post where OP realizes he disabled 8dot3

        https://forum.powerbasic.com/forum/u...-code-filename

        Comment


        • #5
          What a perfect job for SQLite
          Table t1 with 3-columns named c1,c2,c3
          All data in the file test.db3
          Code:
          #INCLUDE "sqlitening.inc"   'or use Chris or Jose routines
          
          FUNCTION PBMAIN AS LONG
          
           LOCAL x,maximum AS LONG
           DIM s(1 TO 3) AS STRING             'columns: c1=filename c2=time c3=data
          
           slopen "test.db3","C"               'open database, "C"reate if doesn't exist
           slexe  "create table if not exists t1(c1,c2,c3)"
          
           maximum = 50000                     'records to insert
           slexe "begin exclusive"             'lock database test.db3 (much, much faster)
          
           FOR x = 1 TO maximum
            s(1) ="some file name"             'c1 filename
            s(2) = TIME$                       'c2 time written to table
            s(3) = "all the data"              'c3 file data
            FileToTable s()                    'insert a record
           NEXT
          
           slexe "end" 'unlock database test.db3
          
          END FUNCTION
          
          FUNCTION FileToTable(s() AS STRING) AS LONG
           slexeBind "insert into t1 values(?,?,?)", _ 'placeholders
            slBuildBindDat(s(1),"T") +_  'fill placeholder1 file name
            slbuildBindDat(s(2),"T") +_  'file placeholder2 time
            slBuildBindDat(s(3),"T"),"E0"'E0= don't show error
            IF slGetChangeCount <> 1 THEN FUNCTION = slGetErrorNumber
          END FUNCTION
          https://duckduckgo.com instead of google

          Comment


          • #6
            Gary,

            I can think of another good reason to retain 8.3 filenames.

            The scenario is this:
            You're trying to delete a folder containing excessively long nested paths and filenames - but you get a strange error - and the delete fails.
            It fails because the Windows maximum file + path limit has been exceeded.

            A little known technique to delete such files/folders is to delete them using their 8.3 filename/path(s).


            But if SPEED is the issue - just clone your old spinning drive to an SSD with proper alignment (4Kb) and disk access will happen many times faster.
            In my case,I went from 100MBytes/sec on a Seagate HDD to ~520MB/s on a Samsung Evo Sata 3 SSD. Excellent price/performance ratio too. Not expensive to buy.
            Just be sure you have Sata 3 on your mainboard to get the best results using the SATA interface.

            NVMe M.2 slots on the mainboard are faster still. Last week I setup a client's new HP EliteDesk Pro and benchmarked his NVMe drive at over 2000MB/s.
            The Samsung 970EvoPlus NVMe 512Gbyte drive cost about AU$170. In the US it would be less than US$120... but you need a mainboard that supports it.

            The latest mainboards with PCIe v4.0 support up to 5000MB/s - not sure what the real-world performance is like.

            Anyway, just FYI.....




            Comment


            • #7
              Hi Ross!

              Even with the SSD I'm using (Samsung, I believe), large directory actions take quite a while..My main board is from 2007.

              With a non-SSD, I'm liable to have more grandchildren before things finish!

              Comment


              • #8
                Insert or Replace

                This is very fast and does everything
                Code:
                #INCLUDE "sqlitening.inc"  'or other sql routines
                
                FUNCTION PBMAIN AS LONG
                 LOCAL x        AS LONG
                 LOCAL c1       AS STRING
                 LOCAL c2       AS STRING
                 LOCAL c3       AS STRING
                 LOCAL sql      AS STRING
                 LOCAL sbind    AS STRING
                
                 slopen "test.db3","C"
                 slexe "create table if not exists table1(c1 UNIQUE,c2,c3)
                
                 slexe "begin exclusive"
                 sql = "insert or replace into table1 values(?,?,?)"
                 FOR x = 1 TO 50000
                  c1 = USING$("file#.dat",x)
                  c2 = TIME$
                  c3 = "all the file"
                  sbind = CHR$(slbuildbinddat(c1,"T"),slbuildbinddat(c2,"T"),slbuildbinddat(c3,"T"))
                  slexebind sql,sbind
                 NEXT
                 slexe "end"
                
                END FUNCTION
                Last edited by Mike Doty; 14 Jul 2019, 08:36 AM.
                https://duckduckgo.com instead of google

                Comment


                • #9
                  Gary, unfortunately the answer is not always cut-n-dry. Given that you don't have an app that requires it, then yes, disabling 8.3 can speed things up, but will you actually notice. Similar comment for last access time.

                  We have a couple production application servers with many millions of files. We routinely disable both settings (and strip 8.3) when these types of servers are created. We have other servers with low 10s-of-thousand files. For consistency, they are all set the same, but I doubt we'd ever notice the performance difference. We last tested this in maybe 2008. I looked but could not find the test results. I remember that the settings had a benefit, but I don't remember the magnitude. There were no SSDs in the servers back then, all spinning rust, so I'm not sure if the results would be the same if we retested.

                  One of the best benchmarks I could find on 8.3 is TCAT Shelbyville's blog. Notice the volumes though.

                  Last Access Time is actually a stranger duck, because it doesn't always mean "Actual Last Access". Its a lazy update and can vary by version of Windows. Microsoft suggests it is faster so long as you don't have software that requires it. This article suggests the 'lazy' part of my comment, so the performance might not be as bad as you'd initially think. An article on ars technica suggests about 6% benefit. YMMV.

                  Comment


                  • #10
                    The "lazy write" method used by Windows versions is hard to get around, I have recently had a problem with very large files in 64 bit because when a very large file is written (32 gig and greater) the OS takes minutes to lazy write it all back to disk from installed memory. It appears to work the same way when deleting very large count file lists. If you take the path of changing the file naming system in the OS, I would make sure you never produce code that requires the old 8.3 names.
                    hutch at movsd dot com
                    The MASM Forum

                    www.masm32.com

                    Comment


                    • #11
                      Originally posted by Gary Beene View Post
                      Hi Ross!

                      Even with the SSD I'm using (Samsung, I believe), large directory actions take quite a while..My main board is from 2007.

                      With a non-SSD, I'm liable to have more grandchildren before things finish!
                      Absolutely!

                      With a 2007 vintage mainboard you'd be lucky to have Sata 2 support, and probably running old DDR1 RAM - so the throughput would definitely be throttled way back.
                      There's a site https://www.userbenchmark.com with a free (safe) download to test your PC. Could be interesting to get an idea of your actual throughput.

                      Back in the 80's my work PC was an IBM PS Model 80. It cost about $16,000 - had an 80MB drive and 8MB of RAM. It was soooo slow - time would go backwards while waiting for a compile to finish. I started working there at the age of 27 and when I left 12 years later, I was age 34.

                      But seriously, it might be time to upgrade ye olde hardware.

                      Comment

                      Working...
                      X