diff --git a/images/smb_create_iats_cdf.png b/images/smb_create_iats_cdf.png index 3b2954b..70a7702 100644 Binary files a/images/smb_create_iats_cdf.png and b/images/smb_create_iats_cdf.png differ diff --git a/images/smb_create_iats_pdf.png b/images/smb_create_iats_pdf.png index ab854f1..6385ad5 100644 Binary files a/images/smb_create_iats_pdf.png and b/images/smb_create_iats_pdf.png differ diff --git a/images/smb_create_rts_cdf.png b/images/smb_create_rts_cdf.png index 9720b6d..1bca71e 100644 Binary files a/images/smb_create_rts_cdf.png and b/images/smb_create_rts_cdf.png differ diff --git a/images/smb_create_rts_pdf.png b/images/smb_create_rts_pdf.png index d00602a..3124e9a 100644 Binary files a/images/smb_create_rts_pdf.png and b/images/smb_create_rts_pdf.png differ diff --git a/images/smb_general_iats_cdf.png b/images/smb_general_iats_cdf.png index 2663321..ae683e2 100644 Binary files a/images/smb_general_iats_cdf.png and b/images/smb_general_iats_cdf.png differ diff --git a/images/smb_general_iats_pdf.png b/images/smb_general_iats_pdf.png index 43ae6b2..e2c70c3 100644 Binary files a/images/smb_general_iats_pdf.png and b/images/smb_general_iats_pdf.png differ diff --git a/images/smb_general_rts_cdf.png b/images/smb_general_rts_cdf.png index 892d3c7..eafa498 100644 Binary files a/images/smb_general_rts_cdf.png and b/images/smb_general_rts_cdf.png differ diff --git a/images/smb_general_rts_pdf.png b/images/smb_general_rts_pdf.png index aed19b2..f7573a0 100644 Binary files a/images/smb_general_rts_pdf.png and b/images/smb_general_rts_pdf.png differ diff --git a/images/smb_read_bytes_cdf.png b/images/smb_read_bytes_cdf.png index cc02d79..2a8f4ea 100644 Binary files a/images/smb_read_bytes_cdf.png and b/images/smb_read_bytes_cdf.png differ diff --git a/images/smb_read_bytes_pdf.png b/images/smb_read_bytes_pdf.png index 4e45a2b..221039b 100644 Binary files a/images/smb_read_bytes_pdf.png and b/images/smb_read_bytes_pdf.png differ diff --git a/images/smb_read_iats_cdf.png b/images/smb_read_iats_cdf.png index 9b56e66..590f8cd 100644 Binary files a/images/smb_read_iats_cdf.png and b/images/smb_read_iats_cdf.png differ diff --git a/images/smb_read_iats_pdf.png b/images/smb_read_iats_pdf.png index 023c835..c435a47 100644 Binary files a/images/smb_read_iats_pdf.png and b/images/smb_read_iats_pdf.png differ diff --git a/images/smb_read_rts_cdf.png b/images/smb_read_rts_cdf.png index 8f98351..334a8bf 100644 Binary files a/images/smb_read_rts_cdf.png and b/images/smb_read_rts_cdf.png differ diff --git a/images/smb_read_rts_pdf.png b/images/smb_read_rts_pdf.png index ca6c943..519a294 100644 Binary files a/images/smb_read_rts_pdf.png and b/images/smb_read_rts_pdf.png differ diff --git a/images/smb_write_bytes_cdf.png b/images/smb_write_bytes_cdf.png index 01e4dba..a3ae6f6 100644 Binary files a/images/smb_write_bytes_cdf.png and b/images/smb_write_bytes_cdf.png differ diff --git a/images/smb_write_bytes_pdf.png b/images/smb_write_bytes_pdf.png index 0195ad5..12dd811 100644 Binary files a/images/smb_write_bytes_pdf.png and b/images/smb_write_bytes_pdf.png differ diff --git a/images/smb_write_iats_cdf.png b/images/smb_write_iats_cdf.png index e015314..38e2a2c 100644 Binary files a/images/smb_write_iats_cdf.png and b/images/smb_write_iats_cdf.png differ diff --git a/images/smb_write_iats_pdf.png b/images/smb_write_iats_pdf.png index bcb3d1a..56148d5 100644 Binary files a/images/smb_write_iats_pdf.png and b/images/smb_write_iats_pdf.png differ diff --git a/images/smb_write_rts_cdf.png b/images/smb_write_rts_cdf.png index 0c504c4..e229fdb 100644 Binary files a/images/smb_write_rts_cdf.png and b/images/smb_write_rts_cdf.png differ diff --git a/images/smb_write_rts_pdf.png b/images/smb_write_rts_pdf.png index 2d8608c..110acd4 100644 Binary files a/images/smb_write_rts_pdf.png and b/images/smb_write_rts_pdf.png differ diff --git a/trackingPaper.tex b/trackingPaper.tex index c151d7e..9219449 100644 --- a/trackingPaper.tex +++ b/trackingPaper.tex @@ -131,7 +131,7 @@ While file system traces have been well-studied in earlier work, it has been som The purpose of this work is to continue previous SMB studies to better understand the use of the protocol in a real-world production system in use at the University of Connecticut. The main contribution of our work is the exploration of I/O behavior in modern file system workloads as well as new examinations of the inter-arrival times and run times for I/O events. We further investigate if the recent standard models for traffic remain accurate. -Our findings reveal interesting data relating to the number of read and write events. We notice that the number of read events far exceeds writes and that the average of bytes transferred over the wire is greater for reads as well. Furthermore we find an increase in the use of metadata for overall network communication that can be taken advantage of through the use of smart storage devices. +Our findings reveal interesting data relating to the number of read and write events. We notice that the number of read events exceeds writes and that the average of bytes transferred over the wire is greater for reads as well. Furthermore we find an increase in the use of metadata for overall network communication that can be taken advantage of through the use of smart storage devices. \end{abstract} \section{Introduction} @@ -191,7 +191,7 @@ DataSeries was modified to filter specific SMB protocol fields along with the wr The DataSeries data format allowed us to create data analysis code that focuses on I/O events and ID tracking (TID/UID). The future vision for this information is to combine ID tracking with the OpLock information in order to track resource sharing of the different clients on the network. As well as using IP information to recreate communication in a larger network trace to establish a better benchmark. %Focus should be aboiut analysis and new traces -The contributions of this work are the new traces of SMB traffic over a larger university network as well as new analysis of this traffic. Our new examination of the captured data reveals that despite the streamlining of the CIFS/SMB protocol to be less "chatty", the majority of SMB communication is still metadata based I/O rather than actual data I/O. We found that read operations occur in greater numbers and cause a larger overall number of bytes to pass over the network. However, the average number of bytes transferred for each write I/O is greater than that of the average read operation. We also find that the current standard for modeling network I/O holds for the majority of operations, while a more representative model needs to be developed for reads. +The contributions of this work are the new traces of SMB traffic over a larger university network as well as new analysis of this traffic. Our new examination of the captured data reveals that despite the streamlining of the CIFS/SMB protocol to be less "chatty", the majority of SMB communication is still metadata based I/O rather than actual data I/O. We found that read operations occur in greater numbers and cause a larger overall number of bytes to pass over the network. Additionally, the average number of bytes transferred for each write I/O is smaller than that of the average read operation. We also find that the current standard for modeling network I/O holds for the majority of operations, while a more representative model needs to be developed for reads. \subsection{Related Work} In this section we discuss previous studies examining traces and testing that has advanced benchmark development. We summarize major works in trace study in Table~\ref{tbl:studySummary}. In addition we examine issues that occur with traces and the assumptions in their study. @@ -249,7 +249,7 @@ As seen in previous trace work~\cite{leung2008measurement,roselli2000comparison, \subsection{Server Message Block} The Server Message Block (SMB) is an application-layer network protocol mainly used for providing shared access to files, shared access to printers, shared access to serial ports, miscellaneous communications between nodes on the network, as well as providing an authenticated inter-process communication mechanism. %The majority of usage for the SMB protocol involves Microsfot Windows. Almost all implementations of SMB servers use NT Domain authentication to validate user-access to resources -The SMB 1.0 protocol~\cite{SMB1Spec} has been found to have high/significant impact on performance due to latency issues. Monitoring revealed a high degree of ``chattiness'' and disregard of network latency between hosts. Solutions to this problem were included in the updated SMB 2.0 protocol which decreases ``chattiness'' by reducing commands and sub-commands from over a hundred to nineteen. Additional changes, most significantly being increased security, were implemented in SMB 3.0 protocol (previously named SMB 2.2)~\cite{SMB2Spec}. % XXX citations for SMB specs for different versions? +The SMB 1.0 protocol~\cite{SMB1Spec} has been found to have high/significant impact on performance due to latency issues. Monitoring revealed a high degree of ``chattiness'' and disregard of network latency between hosts. Solutions to this problem were included in the updated SMB 2.0 protocol which decreases ``chattiness'' by reducing commands and sub-commands from over a hundred to nineteen~\cite{SMB2Spec}. Additional changes, most significantly being increased security, were implemented in SMB 3.0 protocol (previously named SMB 2.2). % XXX citations for SMB specs for different versions? %\textcolor{red}{\textbf{Add information about SMB 2.X/3?}} The rough order of communication for SMB session file interaction contains about five steps. First is a negotiation where a Microsoft SMB Protocol dialect is determined. Next a session is established to determine the share-level security. After this the Tree ID (TID) is determined for the share to be connected to as well as a file ID (FID) for a file requested by the client. From this establishment, I/O operations are performed using the FID given in the previous step. @@ -257,7 +257,7 @@ The rough order of communication for SMB session file interaction contains about % Information relating to the capturing of SMB information The only data that needs to be tracked from the SMB traces are the UID (User ID) and TID for each session. The SMB commands also include a MID (Multiplex ID) value that is used for tracking individual packets in each established session, and a PID (Process ID) that tracks the process running the command or series of commands on a host. For the purposes of our tracing, we do not track the MID or PID information. - +% Some nuances of SMB protocol I/O to note are that SMB/SMB2 write requests are the actions that push bytes over the wire while for SMB/SMB2 read operations it is the response packets. %\begin{itemize} % \item SMB/SMB2 write request is the command that pushes bytes over the wire. \textbf{Note:} the response packet only confirms their arrival and use (e.g. writing). @@ -289,7 +289,7 @@ In this section, we describe the packet capturing system as well as decisions ma \begin{figure*} \includegraphics[width=\textwidth]{./images/packetcapturetopology.png} - \caption{\textcolor{red}{Visualization of Packet Capturing System}} + \caption{Visualization of Packet Capturing System} \label{fig:captureTopology} \end{figure*} @@ -363,21 +363,19 @@ Average Write Size (B) & 63 \\ \hline %Total R:W Byte Ratio & 166.446693744549 \\ %\hline %Average R:W Byte Ratio & 0.253996031053668 \\ \hline \end{tabular} -\label{tbl:TraceSummaryTotal} -\caption{Summary of Trace I/O Statistics for the time of April 30th, 2019 to May 20th, 2019} +\caption{\label{tbl:TraceSummaryTotal}Summary of Trace I/O Statistics for the time of April 30th, 2019 to May 20th, 2019} \vspace{-2em} \end{table} % NOTE: Not sure but this reference keeps referencing the WRONG table -Table~\ref{tbl:TraceSummaryTotal} -shows a summary of the I/O operations, response times, and inter arrival times observed for the network filesystem. This table illustrates that the majority of I/O operations are general (74.87\%). As shown in the bottom part of Table~\ref{tbl:TraceSummaryTotal} general includes metadata commands such as \texttt{connect}, close, query info, etc. +Tables~\ref{tbl:TraceSummaryTotal} +show a summary of the SMB traffic captured, statistics of the I/O operations, and read/write data exchange observed for the network filesystem. This information is further detailed in Table~\ref{tbl:SMBCommands}, which illustrates that the majority of I/O operations are general (74.87\%). As shown in the bottom part of Table~\ref{tbl:SMBCommands} general includes metadata commands such as \texttt{connect}, close, query info, etc. Our examination of the collected network filesystem data revealed interesting patterns for the current use of CIFS/SMB in a large engineering academic setting. The first is that there is a major shift away from read and write operations towards more metadata-based ones. This matches the last CIFS observations made by Leung et.~al.~that files were being generated and accessed infrequently. The change in operations are due to a movement of use activity from reading and writing data to simply checking file and directory metadata. However, since the earlier study, SMB has transitioned to the SMB2 protocol which was supposed to be less "chatty" and thus we would expect fewer general SMB operations. Table~\ref{tbl:SMBCommands} shows a breakdown of SMB and SMB2 usage over the time period of May. From this table, one can see that the SMB2 protocol makes up $99.14$\% of total network operations compared to just $0.86$\% for SMB, indicating that most clients have upgraded to SMB2. However, $74.66$\% of SMB2 I/O are still general operations. Contrary to the purpose of implementing the SMB2 protocol, there is still a large amount of general I/O. %While CIFS/SMB protocol has less metadata operations, this is due to a depreciation of the SMB protocol commands, therefore we would expect to see less total operations (e.g. $0.04$\% of total operations). %The infrequency of file activity is further strengthened by our finding that within a week long window of time there are no Read or Write inter arrival times that can be calculated. %\textcolor{red}{XXX we are going to get questioned on this. its not likely that there are no IATs for reads and writes} - -General operations happen at very high frequency with inter arrival times that were found to be relatively short (1317$\mu$s on average). +General operations happen at very high frequency with inter arrival times that were found to be relatively short (1317$\mu$s on average), as shown in Table~\ref{tbl:PercentageTraceSummary}. Taking a deeper look at the SMB2 operations, shown in the bottom half of Table~\ref{tbl:SMBCommands}, we see that $9.06$\% of the general operations are negotiate commands. These are commands sent by the client to notify the server which dialects of the SMB2 protocol the client can understand. The three most common commands are close, tree connect, and query info. The latter two relate to metadata information of shares and files accessed, however the close operation relates to the create operations relayed over the network. Note that the create command is also used as an open file. The first thing one will notice is that the number of closes is greater than the total number of create operations; by $9.35$\%. These extra close operations are most likely due to applications doing multiple closes that do not need to be done. @@ -441,7 +439,7 @@ Oplock Break & \multicolumn{2}{|c|}{22397} & 0.008\% \\ \hline % \label{fig:IO-R+W} %\end{figure} Each SMB Read and Write command is associated with a data request size that indicates how many bytes are to be read or written as part of that command. -Figures~\ref{fig:PDF-Bytes-Read} and~\ref{fig:PDF-Bytes-Write} show the probability density function (PDF) of the different sizes of bytes transferred for read and write I/O operations respectively. The most noticeable aspect of these graphs are that the majority of bytes transferred for read and write operations is around 64 bytes. It is worth noting that write I/O also have a larger number of very small transfer amounts. This is unexpected in terms of the amount of data passed in a frame. Our belief is that this is due to a large number of long term calculations/scripts being run that only require small but frequent updates. This assumption was later validated in part when examining the files transferred, as some were related to running scripts creating a large volume of files, however the more affirming finding was the behavior observed with common applications. For example, it was seen that Microsoft Word would perform a large number of small reads at ever growing offsets. This was interpreted as when a user is viewing a document over the network and Word would load the next few lines of text as the user scrolled down the document; causing ``loading times'' amid use. +Figures~\ref{fig:PDF-Bytes-Read} and~\ref{fig:PDF-Bytes-Write} show the probability density function (PDF) of the different sizes of bytes transferred for read and write I/O operations respectively. The most noticeable aspect of these graphs are that the majority of bytes transferred for read and write operations is around 64 bytes. It is worth noting that write I/O also have a larger number of very small transfer amounts. This is unexpected in terms of the amount of data passed in a frame. Our belief is that this is due to a large number of long term calculations/scripts being run that only require small but frequent updates. This assumption was later validated in part when examining the files transferred, as some were related to running scripts creating a large volume of files, however the more affirming finding was the behavior observed with common applications. For example, it was seen that Microsoft Word would perform a large number of small reads at ever growing offsets. This was interpreted as when a user is viewing a document over the network and Word would load the next few lines of text as the user scrolled down the document; causing ``loading times'' amid use. A large degree of small writes were observed to be related to application cookies or other such smaller data communications. %This could also be attributed to simple reads relating to metadata\textcolor{red}{???} %\begin{figure} @@ -458,24 +456,28 @@ Figures~\ref{fig:PDF-Bytes-Read} and~\ref{fig:PDF-Bytes-Write} show the probabil \begin{figure}[t] \includegraphics[width=0.5\textwidth]{./images/smb_read_bytes_pdf.png} + \vspace{-2em} \caption{PDF of Bytes Transferred for Read I/O} \label{fig:PDF-Bytes-Read} \end{figure} \begin{figure}[t] \includegraphics[width=0.5\textwidth]{./images/smb_read_bytes_cdf.png} + \vspace{-2em} \caption{CDF of Bytes Transferred for Read I/O} \label{fig:CDF-Bytes-Read} \end{figure} \begin{figure}[t] \includegraphics[width=0.5\textwidth]{./images/smb_write_bytes_pdf.png} + \vspace{-2em} \caption{PDF of Bytes Transferred for Write I/O} \label{fig:PDF-Bytes-Write} \end{figure} \begin{figure}[t] \includegraphics[width=0.5\textwidth]{./images/smb_write_bytes_cdf.png} + \vspace{-2em} \caption{CDF of Bytes Transferred for Write I/O} \label{fig:CDF-Bytes-Write} \end{figure} @@ -490,7 +492,7 @@ This read data differs from the size of reads observed by Leung et al. by a fact %This read data is similar to what was observed by Leung et al, however at an order of magnitude smaller. Writes observed also differ from previous inspection of the protocol's usage. % are very different. Leung et al. showed that $60$-$70$\% of writes were less than 4K in size and $90$\% less than 64K in size. In our data, however, we see that only $11.16$\% of writes are less than 4 bytes, $52.41$\% are 64 byte requests, and only $43.63$\% of requests are less than 64 byte writes. -In the ten years since the last study, it is clear that writes have become significantly larger. This may be explained by the fact that large files, and multiple files, are being written as standardized blocks more fitting to the larger data-sets and disk space available. This could be as an effort to improve the fidelity of data across the network, allow for better realtime data consistency between client and backup locations, or could just be due to a large number of scripts being run that create and update a series of relatively smaller documents. +In the ten years since the last study, it is clear that writes have become significantly smaller. This may be explained by the fact that large files, and multiple files, are being written as standardized blocks more fitting to the frequent update of larger data-sets and disk space available. This could be as an effort to improve the fidelity of data across the network, allow for better realtime data consistency between client and backup locations, or could just be due to a large number of scripts being run that create and update a series of relatively smaller documents. %\textbf{Note: It seems like a change in the order of magnitude that is being passed per packet. What would this indicate?}\textcolor{red}{Answer the question. Shorter reads/writes = better?} \begin{table}[] @@ -694,82 +696,94 @@ However, one should notice that the response time on read operations grows at a \begin{figure}[tp!] \includegraphics[width=0.5\textwidth]{./images/smb_read_iats_cdf.png} + \vspace{-2em} \caption{CDF of Inter Arrival Time for Read I/O} \label{fig:CDF-IAT-Read} \end{figure} \begin{figure}[tp!] \includegraphics[width=0.5\textwidth]{./images/smb_read_iats_pdf.png} + \vspace{-2em} \caption{PDF of Inter Arrival Time for Read I/O} \label{fig:PDF-IAT-Read} \end{figure} \begin{figure}[tp!] \includegraphics[width=0.5\textwidth]{./images/smb_read_rts_cdf.png} + \vspace{-2em} \caption{CDF of Response Time for Read I/O} \label{fig:CDF-RT-Read} - \vspace{-2em} +% \vspace{-2em} \end{figure} \begin{figure}[tp!] \includegraphics[width=0.5\textwidth]{./images/smb_read_rts_pdf.png} + \vspace{-2em} \caption{PDF of Response Time for Read I/O} \label{fig:PDF-RT-Read} - \vspace{-2em} +% \vspace{-2em} \end{figure} % RTs information \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_write_iats_cdf.png} + \vspace{-2em} \caption{CDF of Inter Arrival Time for Write I/O} \label{fig:CDF-IAT-Write} \end{figure} \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_write_iats_pdf.png} + \vspace{-2em} \caption{PDF of Inter Arrival Time for Write I/O} \label{fig:PDF-IAT-Write} \end{figure} \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_write_rts_cdf.png} + \vspace{-2em} \caption{CDF of Return Time for Write IO} \label{fig:CDF-RT-Write} - \vspace{-2em} +% \vspace{-2em} \end{figure} \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_write_rts_pdf.png} + \vspace{-2em} \caption{PDF of Return Time for Write IO} \label{fig:PDF-RT-Write} - \vspace{-2em} +% \vspace{-2em} \end{figure} \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_create_iats_cdf.png} \caption{CDF of Inter Arrival Time for Create I/O} + \vspace{-2em} \label{fig:CDF-IAT-Create} \end{figure} \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_create_iats_pdf.png} + \vspace{-2em} \caption{PDF of Inter Arrival Time for Create I/O} \label{fig:PDF-IAT-Create} \end{figure} \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_create_rts_cdf.png} + \vspace{-2em} \caption{CDF of Response Time for Create I/O} \label{fig:CDF-RT-Create} - \vspace{-2em} +% \vspace{-2em} \end{figure} \begin{figure}[t!] \includegraphics[width=0.5\textwidth]{./images/smb_create_rts_pdf.png} + \vspace{-2em} \caption{PDF of Response Time for Create I/O} \label{fig:PDF-RT-Create} - \vspace{-2em} +% \vspace{-2em} \end{figure} %\begin{figure} @@ -821,7 +835,7 @@ l & 2321338 & 1.06 \\ x & 2108279 & 0.96 \\ h & 2019714 & 0.92 \\ \hline \end{tabular} -\caption{\textcolor{red}{Top 10 File Extensions Seen Over Three Week Period}} +\caption{Top 10 File Extensions Seen Over Three Week Period} \label{tab:top10SMB2FileExts} \end{table} @@ -841,7 +855,7 @@ pdf & 375601 & 0.17 \\ xml & 1192840 & 0.54 \\ txt & 167827 & 0.08 \\ \hline \end{tabular} -\caption{\textcolor{red}{Common File Extensions Seen Over Three Week Period}} +\caption{Common File Extensions Seen Over Three Week Period} \label{tab:commonSMB2FileExts} \end{table} @@ -855,7 +869,7 @@ txt & 167827 & 0.08 \\ \hline For simulations and analytic modeling, it is often useful to have models that describe storage systems I/O behavior. In this section, we attempt to map traditional probabilistic distributions to the data that we have observed. Specifically, taking the developed CDF graphs, we perform curve fitting to determine the applicability of Gaussian and Weibull distributions to the the network filesystem I/O behavior. Note that an exponential distribution, typically used to model interarrival times and response times, is a special case of a Weibull distribution where $k=1$. -Table~\ref{tbl:curveFitting} shows best-fit parametrized distributions for the measured. % along with $R^2$ fitness values. +Table~\ref{tbl:curveFitting} shows best-fit parametrized distributions for the measured data. % along with $R^2$ fitness values. %Based on the collected IAT and RT data, the following are the best fit curve representation equations with supporting $R^{2}$ values. In the case of each, it was found that the equation used to model the I/O behavior was a Gaussian equation with a single term. %\begin{equation} f(x) = a_1 * e^{-((x-b_1)/c_1)^2)} \end{equation} @@ -963,7 +977,7 @@ A complication of this process is that the DataSeries code makes use of a push-p Normally, one could simply re-perform the conversion process to a DataSeries file, but due to the rate of the packets being captured and security concerns of the data being captured, we are unable to re-run any captured information. \section{Conclusions and Future Work} -Our analysis of this university network filesystem illustrated the current implementation and use of the CIFS/SMB protocol in a large academic setting. We notice the effect of caches on the ability of the filesystem to limit the number of accesses to persistant storage. The effect of enterprise storage disks access time can seen in the response time for read and write I/O. The majority of network communication is dominated by metadata operation, which is of less surprise since SMB is a known chatty protocol. We do notice that the CIFS/SMB protocol continues to be chatty with metadata I/O operations regardless of the version of SMB being implemented; $74.66$\% of I/O being metadata operations for SMB2. +Our analysis of this university network filesystem illustrated the current implementation and use of the CIFS/SMB protocol in a large academic setting. We notice the effect of caches on the ability of the filesystem to limit the number of accesses to persistant storage. The effect of enterprise storage disks access time can be seen in the response time for read and write I/O. The majority of network communication is dominated by metadata operation, which is of less surprise since SMB is a known chatty protocol. We do notice that the CIFS/SMB protocol continues to be chatty with metadata I/O operations regardless of the version of SMB being implemented; $74.66$\% of I/O being metadata operations for SMB2. We also find that read operations happen in greater number than write operations (at a ratio of 1.06) and the size of their transfers are is also greater by a factor of about 2. However, the average write operation includes a larger number of relatively smaller writes. Examination of the return times for these different I/O operations shows that exponential distribution curve fitting equation is most accurate at modeling the CDF of the various I/O operations. This shows that the current model is still effective for the majority of I/O, but that for read operations there needs to be further research in modeling their behavior. %Our work finds that a single term Gaussian distribution has an $R^2$ value of $0.7797$, but further work needs to be made in order to refine the model.