Rewriting speedup

Previous write throughputs are the measurements of writing new files to the mount point.

In fact, users often deal with writing to existent files, and we used “rsync” utility to enhance rewriting performance of AshFS. In this experiment, we evaluated how it much faster than original writing methods. First we wrote a directory containing many files with different sizes

to the mount point. After these files are all successfully propagated to the server, we modified every file with a small change: we used a text editor to open them and appended two new lines of text to each file. Our target file systems will perceive the changes of cached files and then synchronize them with server’s ones. (For the file systems with no persistent cache, the changes are directly replayed on the server’s files.) After the synchronization has been finished, we appended these files again. Similar actions were repeated for three times, and the results shown here are the averages. The consumed bandwidth of each write/rewrite operation was measured and we compared it with the original file size. Here we invoke a new terminology “Speedup” used in rsync and follow its original definition.

z Speedup = Original file size / total transferred packet size

We can think that the number Speedup is a bandwidth-preserving factor. Obviously everyone wants it to be as greater as possible, since we can use a little bandwidth to finish synchronization. In a normal case, Speedup is usually less than 1 because of the protocol overhead (It costs more than N bytes to transfer an N bytes file).

The results are shown in Figure 18, where AshFS (z on) means AshFS with compress-enabled rsync; i.e. AshFS will compress some data when synchronizing. When all of our target file systems uploaded new files to the server, they transferred all contents of files.

Hence all Speedups are a little less than 1, in a word, there is no speed improvement.

Traditional cache-enabled network file systems usually upload every changed file to the server in their entirety, but AshFS will perceive that these files already exist on the server and will find the differences between the newer version and older version. When writing the same file again, AshFS will only propagate the modified contents. Since only a small part of file is transferred, Speedup is much bigger than 1 in the rewriting operation. Intuitively, with the support of compression, AshFS (z on) has larger Speedup. Note that Speedup of NFS is a little greater than 1 for the rewriting operation, and it means that NFS may compress the file data for rewriting. Samba and Sshfs performs notably worse than writing new files: their Speedups

are almost a half of the original ones, and we noticed that the amounts of their receiving packets were almost equal to sending packets (and almost equal to total directory size). This looks strange because the receiving packets are usually much less than sending packets for writing operations. We think this may because of the temporary cached files: Samba and Sshfs found that the user was writing to an existent file and thought it may be rewritten for several times in the future, so they downloaded the file to their memory caches first. After getting the file and writing to it, these file systems then uploaded the file to the server. This can explain why the amounts of sending packets and receiving packets were almost equal to the file size.

But both of them don’t support persistent cache, so when the user wrote to the same file after a while (the cached file was invalidated or replaced), they needed to retrieve it from the server again. Therefore Samba and Sshfs transferred double amounts of packets in rewriting operations. Finally, lacking of synchronization algorithms similar to rsync, Coda’s Speedups are all the same in both write and rewrite benchmarks, because it transferred similar contents again and again.

Figure 18: Rewriting speedup

Chapter 6

Conclusion and Future work

In this thesis, we described the designs and implementations of AshFS, a personal network file system designed for the mobile networks. AshFS supports disconnected operations and automatic synchronization, so it can functions correctly under the different network environments. We chose SSH2 as our main protocol to develop AshFS since it is widely distributed and secure. In order to ease installation and deployment, no server-side changes were made.

AshFS is created based on FUSE, a user space file system framework. Although its functionalities are implemented in user space, experiments show that its performance is acceptable. Since the rise in computing power is led over the speed improvement in network equipments, it’s a feasible solution to create a network file system in user space.

AshFS has a higher throughput and a lower protocol overhead than the majority of network file systems in our experiments. For the rewriting operation, a frequently-executed action in the filesystem, AshFS can preserve much more bandwidth than others. Besides, its performance is not severely affected by available bandwidth. AshFS are also aware of the variation of network status soon. Future work is to adapt this experimental implementation to become more reliable and maneuverable.

References

[1] I. Voras and M. Zagar, “Network Distributed File System in User Space,” Information Technology Interfaces, 2006. 28^th International Conference on, 2006, pp. 669-674.

[2] P. J. Braam and P. A. Nelson, “Removing Bottlenecks in Distributed Filesystems: Coda &

InterMezzo as esamples,” Proceedings of Linux Expo 1999, May 1999.

[3] J. Tolvanen, T. Suihko, J. Lipasti, and N. Asokan, “Remote Storage for Mobile Devices,”

Communication System Software and Middleware, 2006. Comsware 2006. First International Conference on, Jan 2006, pp. 1-9.

[4] M. Satyanarayanan, “Coda: A Highly Available File System for a Distributed Workstation Environment,” in Proceedings of the Second IEEE Workshop on Workstation Operating

Systems, 1989.

[5] B. Atkin, and K.P. Birman, “Network-Aware Adaptation Techniques for Mobile File Systems,” Network Computing and Applications, 2006. NCA 2006. Fifth IEEE

International Symposium on, July 2006, pp. 181-188.

[6] P. J. Braam, “File Systems for Clusters from a Protocol Perspective,” Second Extreme Linux Topic Workshop, Monterey CA, 1999.

[7] I-Hsuan Huang, Wei-Jin Tzeng, Szu-Wei Wang, and Cheng-Zen Yang, “Design and Implementation of a Mobile SSH Protocol,” TENCON 2006. 2006 IEEE Region 10

Conference, November 2006, pp. 1-4.

[8] OpenSSH, project home http://www.openssh.com/ .

[9] Christopher Smith, “Linux NFS-HOWTO,” online publication, May 2006, http://nfs.sourceforge.net/nfs-howto/ .

[10] A. Josey, chair, “POSIX Threads,” IEEE Standard 1003.1, 2004 Edition.

[11] FUSE: Filesystem in Userspace, project home

[13] Brian Pawlowski, Spencer Shepler, Carl Beame, Brent Callaghan, Michael Eisler, David Noveck, David Robinson, Robert Thurlow, “The NFS Version 4 Protocol,” 2^nd International SANE Conference, May 22-25 2000 MECC, Maastricht, The Netherlands.

[14] Jelmer R. Vernooij, John H. Terpstra, and Gerald (Jerry) Carter, “The Official Samba 3.2.x HOWTO and Reference Guide,” online publication.

http://us3.samba.org/samba/docs/man/Samba-HOWTO-Collection/ .

[15] John D. Blair, “Samba: Integrating Unix and Windows,” Specialized Systems Consultants Inc, Seattle, 1998.

[16] Matthew E. Hoskins, "SSHFS: Super Easy File Access over SSH," Linux Journal, April 28^th 2006.

[17] SSH Filesystem,

http://fuse.sourceforge.net/sshfs.html .

[18] J. Postel and J. Reynolds, “File Transfer Protocol (FTP)”, IETF RFC Document #959, 1985.

[19] bonnie++(8) - Linux man page, online publication http://linux.die.net/man/8/bonnie++/ .

[20] Tim Bray and Russell Coker, “bonnie++ readme,” online publication, 1999, http://www.coker.com.au/bonnie++/readme.html .

[21] time(1) - Linux man page, online publication http://linux.die.net/man/1/time .

[22] Tomasz Chmielewski, “Bandwidth Limiting HOWTO,” online publication, Nov 20th 2001,

[23] Paul Warren and Chris Lightfoot, “iftop: Display bandwidth usage on an interface,”

online publication, Feb 12th 2006, http://www.ex-parrot.com/~pdw/iftop/ .

[24] John C.S. Lui, Oldfield K.Y. So, and T.S. Tam, “NFS/M: An Open Platform Mobile File System,” The 18^th International Conference on Distributed Computing Systems (ICDCS’98), May 1998.

[25] Braam and P.J., “The Coda Distributed File System,” Linux Journal, #50, June 1998.

[26] Athicha Muthitacharoen, Benjie Chen, and David Mazieres, “A Low-bandwidth Network File System,” Proceedings of the eighteenth ACM symposium on Operating systems

principles, 2001, pp. 174-187.

[27] Michael Holve, “A Tutorial on Using rsync,” online publication, Nov 12th 1999, http://everythinglinux.org/rsync/ .

[28] Rsync man page, Jun 29^th 2008,

http://samba.anu.edu.au/ftp/rsync/rsync.html .