Abstract Attribute-Based Prediction of File Properties(5)

The?rst pass reconstructs as much as it can of the ?le system hierarchy,primarily by observing the param-eters and responses from lookup,getattr,create, mkdir,rename,remove,and link calls.The idea of discovering the?le system hierarchy by snooping NFS calls is not new and has been in widespread use since the technique was described by Blaze[3].Unfortunately,as other researchers have noted,this method is imperfect–some of the information may be absent from the trace because of missed packets or because it is cached on the client during the trace period and thus never visible in the trace.To compensate for this missing data,we keep track of each?le or directory that is accessed during the trace, but whose metadata we cannot infer.When the?rst pass

is?nished,we may either?ll in the missing values with reasonable defaults or discard the incomplete items.

Because we are using attribute-based models,we can-not simply invent?le attributes and hope that they will work.However,there is a danger that if we discard all the objects for which we have incomplete information, we may lose a signi?cant portion of workload.For the experiment described in this section,we use only name attributes.After examining the traces we cannot?nd names for fewer than than5%of the?les mentioned in the workload(and typically much less).Therefore we believe that discarding these“anonymous?les”does not alter the workload to an important degree.

Files or directories for which we cannot infer the par-ent are attached to the root directory,because from our own experiments we have found that this is the direc-tory most likely to be cached on the client.For example, we rarely see lookups for/home/username,because home directories are frequently accessed and rarely in-validated.

The output of the?rst pass is a table of pathnames of each?le and directory observed in the trace along with a unique identi?er for each object,and the size,mode,and other relevant information necessary to reconstruct the object.The purpose of the new identi?er is to provide

a convenient substitute for the?le handle that is inde-

pendent of the actual implementation of the?le system.

(File handles usually encode the mount point and inode numbers,and we cannot ensure that we will get the same values when we reconstruct the?le system.)

The second pass through the trace replaces all of the ?le handles in the trace with the unique identi?ers cre-ated in the?rst pass,and removes references to?les for which no information could be inferred.

Based on the table created after the?rst pass,we then create a?le system that matches the rewritten trace,and replay the new trace on that?le system.The result is both realistic and repeatable.

Using this method,we constructed several sub-snapshots for each workload.A typical hour of ac-tivity on these systems accesses?les containing only ?ve to ten GB of data(although there are hours when many directories are scanned,resulting in enormous and unwieldy sub-snapshots).One of the challenges with DEAS03and EECS03is that there are apparently some jobs that periodically scan large parts of the directory hierarchy,checking the modi?cation time of each?le.

Since most of these?les are never actually read or writ-ten,we could modify our sub-snapshot builder to recog-nize this and treat these?les differently(only creating a short or empty?le,instead of a?le the same size as the 11

We present evidence that attributes that are known to the file system when a file is created, such as its name, permission mode, and owner, are often strongly related to future properties of the file such as its ultimate size, lifespan, and access pattern.

original).This would permit us to create sub-snapshots for a much larger fraction of the underlying?le system.

6.2Increasing Locality of Reference

As an example application,we explore the use of attribute-based hints to control the locality of block ref-erence by anticipating which blocks are likely to be hot and grouping them in the same cylinder.

We use two methods to identify hot data blocks. The?rst method,which we call HotName,automatically classi?es as hot any?le that we predict will be short-lived and/or zero-length.For this type of?le,the overhead of creating and maintaining the inode and name the?le (i.e.,the directory entry for the?le)can be a large frac-tion of the cost incurred by the?le,and therefore there may be bene?t to reducing this overhead.The second method,which we call HotDir,predicts which directo-ries are most likely to contain?les that have the Hot-Name property.Since these directories are where the names for the HotName?les will be entered,there may be bene?t from identifying them as well.

The model that we use for HotDir is constructed via a method similar to ABLE,but unfortunately in our pro-totype requires some external logic because ABLE is fo-cused on?les and does not currently gather as much in-formation about directories.In general,the HotDir rules are that directories identi?ed as home directories,mail spool directories,and directories named Cache are clas-si?ed as hot directories.(ABLE is capable of identifying the mail and Cache directories as interesting,but does not currently have a“is-home-directory”attribute.) To test the effect of HotDir and HotName,we have modi?ed the FreeBSD implementation of FFS so that it uses a simpli?ed predictor(similar in nature to the ABLE predictor,but employing only name attributes, and re-coded to live in the kernel environment)to predict whether each new directory has the HotDir property and whether each new?le has the HotName property.If so, it attempts to allocate blocks for that?le or directory in a designated area of the disk.Our goal is to measure the increase in the number of accesses to this area of the disk when we use policies guided by HotDir and HotName.

We use two systems as our testbed.Both have …… 此处隐藏：6190字，全部文档内容请下载后查看。喜欢就下载吧 ……