A Five-Year Study of File-System MetadataNitin Agrawal University of Wisconsin,Madison nitina@ William J.Bolosky,John R.Douceur,Jacob R.LorchMicrosoft Research{bolosky,johndo,lorch}@AbstractForfive years,we collected annual snapshots offile-system metadata from over60,000Windows PCfile sys-tems in a large corporation.In this paper,we use these snapshots to study temporal changes infile size,file age,file-type frequency,directory size,namespace structure,file-system population,storage capacity and consump-tion,and degree offile modification.We present a gen-erative model that explains the namespace structure and the distribution of directory sizes.Wefind significant temporal trends relating to the popularity of certainfile types,the origin offile content,the way the namespace is used,and the degree of variation amongfile systems,as well as more pedestrian changes in sizes and capacities. We give examples of consequent lessons for designers of file systems and related software.1IntroductionEvery year from2000to2004,we collected snapshots of metadata from over ten thousandfile systems on the Windows desktop computers at Microsoft Corporation. We gathered this data by mass-emailing a scanning pro-gram to Microsoft’s employees,and we had a22%par-ticipation rate every year.Our resulting datasets con-tain metadata from63,398distinctfile systems,6457of which provided snapshots in multiple years.This project was a longitudinal extension of an ear-lier study we performed in1998[9],which was an order of magnitude larger than any prior study offile-system metadata.Our earlier study involved a single capture of file-system metadata,and it focused on lateral variation amongfile systems at a moment in time.By contrast, the present study focuses on longitudinal changes infile systems over afive-year time span.In particular,we study temporal changes in the size, age,and type frequency offiles;the size of directories; the structure of thefile-system namespace;and various characteristics offile systems,includingfile and direc-tory population,storage capacity,storage consumption, and degree offile modification.The contributions of this work are threefold.First,we contribute the collected data set,which we will sanitize and make available for general use later this year.This is the largest set offile-system metadata ever collected,and it spans the longest time period of any sizeable metadata collection.To obtain this data set,contact the Microsoft authors.Second,we contribute all of our research observations, including:•The space used infile systems has increased over the course of our study,not only because meanfile size has increased(from108KB to189KB),but also because the number offiles has increased(from 30K to90K).•Eightfile-name extensions account for over35%of files,and ninefile-name extensions account for over 35%of the bytes infiles.The same sets of exten-sions have remained popular for many years.•The fraction offile-system content created or modi-fied locally has decreased over time.In thefirst year of our study,the medianfile system had30%of its files created or modified locally,and four years later this percentage was22%.•Directory size distribution has not notably changed over the years of our study.In each year,directo-ries have had very few subdirectories and a modest number of entries.90%of them have had two or fewer subdirectories,and90%of them have had20 or fewer total entries.•The fraction offile system storage residing in the namespace subtree meant for user documents and settings has increased in every year of our study, starting at7%and rising to15%.The fraction re-siding in the subtree meant for systemfiles has also risen over the course of our study,from2%to11%.•File system capacity has increased dramatically dur-ing our study,with median capacity rising from 5GB to40GB.One might expect this to cause dras-tic reductions infile system fullness,but instead the reduction infile system fullness has been modest.Median fullness has only decreased from47%to 42%.•Over the course of a single year,80%offile systems become fuller and18%become less full.Third,we contribute a generative,probabilistic model for how directory trees are created.Our model explains the distribution of directories by depth in the namespace tree,and it also explains the distribution of the count of subdirectories per directory.This is thefirst genera-tive model that characterizes the process by whichfile-system namespaces are constructed.§2describes the methodology of our data collection, analysis,and presentation.§3,§4,and§5present our findings on,respectively,files,directories,and space us-age.§6surveys related work,and§7summarizes and concludes.2MethodologyThis section describes the methodology we applied to collecting,analyzing,and presenting the data.2.1Data collectionWe developed a simple program that traverses the di-rectory tree of each local,fixed-diskfile system mounted on a computer.The program records a snapshot of all metadata associated with eachfile or directory,includ-ing hiddenfiles and directories.This metadata includes name,size,timestamps,and attributes.The program also records the parent-child relationships of nodes in the namespace tree,as well as some system configuration information.The program recordsfile names in an en-crypted form.We wrote automated tools that decrypt the file names for computing aggregate statistics,but for pri-vacy reasons we do not look at the decryptedfile names directly,which places some limits on our analyses.In post-processing,we remove metadata relating to the sys-tem pagingfile,because this is part of the virtual memory system rather than thefile system.In the autumn of every year from2000to2004,we dis-tributed the scanning program via email to a large subset of the employees of Microsoft,with a request for the re-cipients to run the program on their desktop machines. As an incentive to participate,we held a lottery in whichYear Period Users Machs FSs 200013Sep–29Sep5396605111,654 20018Oct–2Nov7539936316,022 200230Sep–1Nov7158909115,011 200313Oct–14Nov7436926214,633 20045Oct–12Nov7180872913,505 Table1:Properties of each year’s datasetYear NTFS FAT32FAT Other Total 20007,0152,6961,943011,654 200111,7913,314915216,022 200212,3022,280429015,011 200312,8531,478302014,633 200412,364876264113,505 Total56,32510,6443,853370,825 Table2:File system types in datasetseach scanned machine counted as an entry,with a single prize of a night’s stay at a nearby resort hotel.The spe-cific subset of people we were permitted to poll varied from year to year based on a number of factors;however, despite variations in user population and in other distri-bution particulars,we observed a22%participation rate every year.We scanned desktops rather than servers because at Microsoft,files are typically stored on individual desk-tops rather than centralized servers.We collected the data via voluntary participation rather than random se-lection because the company only permitted the former approach;note that this voluntary approach may have produced selection bias.2.2Data propertiesTable1itemizes some properties of each year’s data collection.The primary collection period ran between the listed start and end dates,which mark the beginning of our emailing requests and the last eligible day for the lottery.Some snapshots continued to trickle in after the primary collection period;we used these in our analyses as well.Table2itemizes the breakdown of each year’s snap-shots according tofile-system type.80%of our snap-shots came from NTFS[27],the mainfile system for operating systems in the Windows NT family;5%from FAT[18],a16-bitfile system dating from DOS;and15% from FAT32[18],a32-bit upgrade of FAT developed for Windows95.Start12345200011,6549502346318200116,0221,833498144-200215,0111,852588--200314,6331,901---200413,505----Total70,8256,5361,32020718 Table3:Number offile systems for which we have snap-shots in the n consecutive years starting with each year. For instance,there are1,852file systems for which we have snapshots from both2002and2003.For some analyses,we needed a way to establish whether twofile-system snapshots from different years refer to the samefile system.“Sameness”is not actually a well-formed notion;for example,it is not clear whether afile system is still the same after its volume is extended. We defined two snapshots to refer to the samefile system if and only if they have the same user name,computer name,volume ID,drive letter,and total space.The need for some of these conditions was not obvious atfirst.For example,we added drive letter because some drives on some machines are multiply mapped,and we added total space so that a volume set would not be considered the same if a new volume were added to the set.Based on this definition,Table3shows the number of snapshots for which we have consecutive-year information.2.3Data presentationMany of our graphs have horizontal axes that span a large range of nonnegative numbers.To represent these ranges compactly,we use a logarithmic scale for non-zero values,but we also include an abscissa for the zero value,even though zero does not strictly belong on a log-arithmic scale.We plot most histograms with line graphs rather than bar graphs because,withfive or more datasets on a sin-gle plot,bar graphs can become difficult to read.For each bin in the histogram,we plot a point(x,y)where x is the midpoint of the bin and y is the size of the bin.We use the geometric midpoint when the x axis uses a log-arithmic scale.We often plot un-normalized histograms rather than probability density functions(PDFs)for two reasons:First,the graphs expose more data if we do not normalize them.Second,because the count offiles and directories perfile system has grown substantially over time,not normalizing allows us to plot multiple years’curves on the same chart without overlapping to the point of unreadability.Whenever we use the prefix K,as in KB,we mean210. Similarly,we use M for220and G for230.2.4Data analysisWe believe that analysis of longitudinalfile system data is of interest to many sets of people with diverse concerns aboutfile system usage.For instance:•developers offile systems,including desktop, server,and distributedfile systems•storage area network designers•developers offile system utilities,such as backup, anti-virus,content indexing,encryption,and disk space usage visualization•storage capacity planners•disk manufacturers,especially those using gray-box techniques to enable visibility into thefile system at the disk level[2]•multitier storage system developersIn each subsection,after discussing ourfindings and what we consider to be the most interesting summaries of thesefindings,we will present some examples of in-teresting implications for the people enumerated above.2.5LimitationsAll our data comes from a relatively homogenous sam-ple of machines:Microsoft desktops running Windows. Since past studies[23,28]have shown thatfile system characteristics can vary from one environment to another, our conclusions may not be applicable to substantially different environments.For instance,our conclusions are likely not applicable tofile system server workloads, and it is unclear to what extent they can be generalized to non-Windows operating systems.It may also be that artifacts of Microsoft policy,such as specific software distributions that are common or disallowed,may yield results that would not apply to other workloads.3Files3.1File count perfile systemFigure1plots cumulative distribution functions (CDFs)offile systems by count offiles.The count of files perfile system has increased steadily over ourfive-year sample period:The arithmetic mean has grown from 30K to90Kfiles and the median has grown from18K to 52Kfiles.The count offiles perfile system is going up from year to year,and,as we will discuss in§4.1,the same holds0 20 40 60 80 1004M 512K 64K 8K 1K 128162C u m u l a t i v e % o f f i l e s y s t e m sFile count (log scale)20002001200220032004Figure 1:CDFs of file systems by file count0 20004000 6000 8000 10000 12000128M 8M 512K 32K 2K 12880F i l e s p e r f i l e s y s t e mFile size (bytes, log scale, power-of-2 bins)20002001200220032004Figure 2:Histograms of files by sizefor directories.Thus,file system designers should en-sure their metadata tables scale to large file counts.Ad-ditionally,we can expect file system scans that examine data proportional to the number of files and/or directo-ries to take progressively longer.Examples of such scans include virus scans and metadata integrity checks fol-lowing block corruption.Thus,it will become increas-ingly useful to perform these checks efficiently,perhaps by scanning in an order that minimizes movement of the disk arm.3.2File sizeThis section describes our findings regarding file size.We report the size of actual content,ignoring the effects of internal fragmentation,file metadata,and any other overhead.We observe that the overall file size distribu-tion has changed slightly over the five years of our study.By contrast,the majority of stored bytes are found in in-creasingly larger files.Moreover,the latter distribution increasingly exhibits a double mode,due mainly to data-base and blob (binary large object)files.Figure 2plots histograms of files by size and Figure 3plots the corresponding CDFs.We see that the absolute count of files per file system has grown significantly over time,but the general shape of the distribution has not0 20 40 60 80 100256M16M 1M 64K 4K 256161C u m u l a t i v e % o f f i l e sFile size (bytes, log scale)20002001200220032004Figure 3:CDFs of files by size200 400 600 800 10001200 1400 1600180064G 8G 1G 128M 16M 2M 256K 32K 4K 512U s e d s p a c e p e r f i l e s y s t e m (M B )Containing file size (bytes, log scale, power-of-2 bins)20002001200220032004Figure 4:Histograms of bytes by containing file size changed significantly.Although it is not visible on the graph,the arithmetic mean file size has grown by 75%from 108KB to 189KB.In each year,1–1.5%of files have a size of zero.The growth in mean file size from 108KB to 189KB over four years suggests that this metric grows roughly 15%per year.Another way to estimate this growth rate is to compare our 2000result to the 1981result of 13.4KB obtained by Satyanarayanan [24].This comparison esti-mates the annual growth rate as 12%.Note that this latter estimate is somewhat flawed,since it compares file sizes from two rather different environments.0 20 40 60 80 100128G 16G 2G 256M 32M 4M 512K 64K 8K 1KC u m u l a t i v e % o f u s e d s p a c eContaining file size (bytes, log scale)20002001200220032004Figure 5:CDFs of bytes by containing file size20040060080010001200140016001800512-1K 4K-8K 32K-64K 256K-512K 2M-4M16M-32M 128M-256M 1G-2G8G-16G 64G-128GContaining file size (bytes, log scale, power-of-2 bins)U s e d s p a c e p e r F S (M B )Figure 6:Contribution of file types to Figure 4(2004).Video means files with extension avi ,dps ,mpeg ,mpg ,vob ,or wmv ;DB means files with extension ldf ,mad ,mdf ,ndf ,ost ,or pst ;and Blob means files named hiberfil.sys and files with extension bak ,bkf ,bkp ,dmp ,gho ,iso ,pqi ,rbf ,or vhd .Figure 4plots histograms of bytes by containing file size,alternately described as histograms of files weighted by file size.Figure 5plots CDFs of these distri-butions.We observe that the distribution of file size has shifted to the right over time,with the median weighted file size increasing from 3MB to 9MB.Also,the distri-bution exhibits a double mode that has become progres-sively more pronounced.The corresponding distribution in our 1998study did not show a true second mode,but it did show an inflection point around 64MB,which is near the local minimum in Figure 4.To study this second peak,we broke out several cate-gories of files according to file-name extension.Figure 6replots the 2004data from Figure 4as a stacked bar chart,with the contributions of video,database,and blob files indicated.We see that most of the bytes in large files are in video,database,and blob files,and that most of the video,database,and blob bytes are in large files.Our finding that different types of files have differ-ent size distributions echoes the findings of other stud-ies.In 1981,Satyanarayanan [24]found this to be the case on a shared file server in an academic environment.In 2001,Evans and Kuenning also noted this phenom-enon in their analysis of 22machines running various operating systems at Harvey Mudd College and Marine Biological Laboratories [11].The fact that this finding is consistent across various different environments and times suggests that it is fundamental.0 20004000 6000 8000 10000 12000 14000 1600014y1.8y81d 10d 31hr 3.8hr F i l e s p e r f i l e s y s t e mFile age (log scale, power-of-2 bins)20002001200220032004Figure 7:Histograms of files by age0 20 40 60 80 1007.1y 0.9y 41d 5d 15.2hr 2hrC u m u l a t i v e % o f f i l e sFile age (log scale, power-of-2 bins)20002001200220032004Figure 8:CDFs of files by ageThere are several implications of the fact that a large number of small files account for a small fraction of disk usage,such as the following.First,it may not take much space to colocate many of these files with their meta-data.This may be a reasonable way to reduce the disk seek time needed to access these files.Second,a file system that colocates several files in a single block,like ReiserFS [22],will have many opportunities to do so.This will save substantial space by eliminating internal fragmentation,especially if a large block size is used to improve performance.Third,designers of disk usage vi-sualization utilities may want to show not only directo-ries but also the names of certain large files.3.3File ageThis subsection describes our findings regarding file age.Because file timestamps can be modified by applica-tion programs [17],our conclusions should be regarded cautiously.Figure 7plots histograms of files by age,calculated as the elapsed time since the file was created or last modi-fied,relative to the time of the snapshot.Figure 8shows CDFs of this same data.The median file age ranges be-tween 80and 160days across datasets,with no clear trend over time.20002001200220032004% o f f i l e sFigure 9:Fraction of files with popular extensionsThe distribution of file age is not memoryless,so the age of a file is useful in predicting its remaining lifetime.So,systems such as archival backup systems can use this distribution to make predictions of how much longer afile will be needed based on how old it is.Since the dis-tribution of file age has not appreciably changed across the years,we can expect that a prediction algorithm de-veloped today based on the latest distribution will apply for several years to come.3.4File-name extensionsThis subsection describes our findings regarding pop-ular file types,as determined by file-name extension.Al-though the top few extensions have not changed dramat-ically over our five-year sample period,there has been some change,reflecting a decline in the relative preva-lence of web content and an increase in use of virtual machines.The top few extensions account for nearly half of all files and bytes in file systems.In old DOS systems with 8.3-style file names,the ex-tension was the zero to three characters following the single dot in the file name.Although Windows systems allow file names of nearly arbitrary length and contain-ing multiple dots,many applications continue to indicate their file types by means of extensions.For our analy-ses,we define an extension as the five-or-fewer charac-ters following the last dot in a file name.If a name has no dots or has more than five characters after the last dot,we consider that name to have no extension,which we repre-sent with the symbol Ø.As a special case,if a file name ends in .gz ,.bz2,and .Z ,then we ignore that suffix when determining extension.We do this because these are types of compressed files wherein the actual content type is indicated by the characters prior to the compres-sion extension.To understand the typical usage of the file extensions we discuss in this section,see Table 4.Extension Typical Usage cpp C++source code dll Dynamic link library exe Executablegif Image in Graphic Interchange Format h Source code headerhtm File in hypertext markup language jpg Image in JPEG format lib Code librarymp3Music file in MPEG Layer III format pch Precompiled headerpdb Source symbols for debugging pst Outlook personal folder txt Textvhd Virtual hard drive for virtual machine wma Windows Media AudioTable 4:Typical usage of popular file extensionssionsFigure 9plots,for the nine extensions that are the most popular in terms of file count,the fraction of files with that extension.The fractions are plotted longitudinally over our five-year sample period.The most notable thing we observe is that these extensions’popularity is rela-tively stable—the top five extensions have remained the top five for this entire time.However,the relative popu-larity of gif files and htm files has gone down steadily since 2001,suggesting a decline in the popularity of web content relative to other ways to fill one’s file system.Figure 10plots,for the ten extensions that are the most popular in terms of summed file size,the fraction of file bytes residing in files with that extension.Across all years,dynamic link libraries (dll files)contain more bytes than any other file type.Extension vhd ,which is used for virtual hard drives,is consuming a rapidly increasing fraction of file-system space,suggesting that5 10 15 20100806040200% o f f i l e s y s t e m s% of files unwritten (5-percentage-point bins)20002001200220032004Figure 11:Histograms of file systems by percentage of files unwritten0 20 40 60 80 10010080604020C u m u l a t i v e % o f f i l e s y s t e m s% of files unwritten20002001200220032004Figure 12:CDFs of file systems by percentage of files unwrittenvirtual machine use is increasing.The null extension ex-hibits a notable anomaly in 2003,but we cannot investi-gate the cause without decrypting the file names in our datasets,which would violate our privacy policy.Since files with the same extension have similar prop-erties and requirements,some file system management policies can be improved by including special-case treat-ment for particular extensions.Such special-case treat-ment can be built into the file system or autonomically and dynamically learned [16].Since nearly half the files,and nearly half the bytes,belong to files with a few pop-ular extensions,developing such special-case treatment for only a few particular extensions can optimize perfor-mance for a large fraction of the file system.Further-more,since the same extensions continue to be popular year after year,one can develop special-case treatments for today’s popular extensions and expect that they will still be useful years from now.3.5Unwritten filesFigures 11and 12plot histograms and CDFs,respec-tively,of file systems by percentage of files that have not been written since they were copied onto the file sys-0 20 40 60 80 10064K 8K 1K 128162C u m u l a t i v e % o f f i l e s y s t e m sDirectory count (log scale, power-of-2 bins)20002001200220032004Figure 13:CDFs of file systems by directory count tem.We identify such files as ones whose modification timestamps are earlier than their creation timestamps,since the creation timestamp of a copied file is set to the time at which the copy was made,but its modifica-tion timestamp is copied from the original file.Over our sample period,the arithmetic mean of the percentage of locally unwritten files has grown from 66%to 76%,and the median has grown from 70%to 78%.This suggests that users locally contribute to a decreasing fraction of their systems’content.This may in part be due to the increasing amount of total content over time.Since more and more files are being copied across file systems rather than generated locally,we can expect identifying and coalescing identical copies to become in-creasingly important in systems that aggregate file sys-tems.Examples of systems with such support are the FARSITE distributed file system [1],the Pastiche peer-to-peer backup system [8],and the Single Instance Store in Windows file servers [5].4Directories4.1Directory count per file systemFigure 13plots CDFs of file systems by count of di-rectories.The count of directories per file system has increased steadily over our five-year sample period:The arithmetic mean has grown from 2400to 8900directories and the median has grown from 1K to 4K directories.We discussed implications of the rising number of di-rectories per file system earlier,in §3.1.4.2Directory sizeThis section describes our findings regarding direc-tory size,measured by count of contained files,count of contained subdirectories,and total entry count.None of these size distributions has changed appreciably over our sample period,but the mean count of files per directory has decreased slightly.0 20 40 60 80 100 01020 30 40 50C u m u l a t i v e % o f d i r e c t o r i e sCount of contained files20002001200220032004Figure 14:CDFs of directories by file count0 20 40 60 80 100 024 6810C u m u l a t i v e % o f d i r e c t o r i e sCount of subdirectories200020012002200320042004 modelFigure 15:CDFs of directories by subdirectory count Figure 14plots CDFs of directories by size,as mea-sured by count of files in the directory.It shows that al-though the absolute count of directories per file system has grown significantly over time,the distribution has not changed appreciably.Across all years,23–25%of directories contain no files,which marks a change from 1998,in which only 18%contained no files and there were more directories containing one file than those con-taining none.The arithmetic mean directory size has decreased slightly and steadily from 12.5to 10.2over the sample period,but the median directory size has re-mained steady at 2files.Figure 15plots CDFs of directories by size,as mea-sured by count of subdirectories in the directory.It in-cludes a model approximation we will discuss later in §4.5.This distribution has remained unchanged over our sample period.Across all years,65–67%of directories contain no subdirectories,which is similar to the 69%found in 1998.Figure 16plots CDFs of directories by size,as mea-sured by count of total entries in the directory.This dis-tribution has remained largely unchanged over our sam-ple period.Across all years,46–49%of directories con-tain two or fewer entries.Since there are so many directories with a small num-ber of files,it would not take much space to colocate0 20 40 60 80 100 01020 30 4050C u m u l a t i v e % o f d i r e c t o r i e sCount of entries20002001200220032004Figure 16:CDFs of directories by entrycountW i n d o w sP r o g r a m F i l e sD o c u m e n t s a n d S e t t i n g sW i n d o w sP r o g r a m F i l e sD o c u m e n t s a n d S e t t i n g sFiles Bytes% o f f i l e s o r b y t e s2000200120032004Figure 17:Fraction of files and bytes in special subtrees the metadata for most of those files with those directo-ries.Such a layout would reduce seeks associated with file accesses.Therefore,it might be useful to preallocate a small amount of space near a new directory to hold a modest amount of child metadata.Similarly,most direc-tories contain fewer than twenty entries,suggesting using an on-disk structure for directories that optimizes for this common case.4.3Special directoriesThis section describes our findings regarding the usage of Windows special directories.We find that an increas-ing fraction of file-system storage is in the namespace subtree devoted to system files,and the same holds for the subtree devoted to user documents and settings.Figure 17plots the fraction of file-system files that reside within subtrees rooted in each of three spe-cial directories:Windows ,Program Files ,and Documents and Settings .This figure also plots the fraction of file-system bytes contained within each of these special subtrees.For the Windows subtree,the fractions of files and bytes have both risen from 2–3%to 11%over our sam-ple period,suggesting that an increasingly large fraction of file-system storage is devoted to system files.In par-。
