other page actions:
v9fs provides a Plan9 9P2000 resource sharing protocol client for the Linux 2.6 kernel. The source code has been maintained as part of the main-line kernel since 2.6.14 with bugtracking through bugzilla org. Normal plan9 servers will work with v9fs, but for folks looking for a Linux-based server we have moved towards support the npfs libraries and applications.
v9fs was originally developed by Ron Minnich(rminnich%lanl.gov) and Maya Gokhale(maya%lanl.gov). Additional development by Greg Watson(gwatson%lanl.gov) and most recently Eric Van Hensbergen(ericvh%gmail.com).
The 2.6 port of V9FS and performance analysis was supported in part by the Defense Advance Research Projects Agency under Contract No. NBCH30390004. The original V9FS research work by Ron Minnich was supported by DARPA Contract #F30602-96-C-0297.
Documentation can be found in the Linux kernel source under Documentation/filesystems/9p.txt with a snapshot captured here
The current source code for v9fs is maintained here: http://git.kernel.org/?p=linux/kernel/git/ericvh/v9fs.git;a=summary
The master branch contains the latest tested stable version. The v9fs-devel branch contains the current development branch.
GNU General Public License (GPL)
sorted by: recent | see :
popular
Content Tagged v9fs
9p/virtio Slides Available
The slides I presented at KVM forum on using 9p over virtio to provide a paravirtualized file service are available on the KVM wiki
xcpu quick start
xcpu quick start for impatient people like me
(aka xcpu quickstart) (More information about xcpu is available from http://www.xcpu.org) Make Sure You Have The Pre-Reqs (on Ubuntu 8.04) sudo apt-get install libelfg0-dev sudo apt-get install libssl-dev Acquire the Source
(aka xcpu quickstart) (More information about xcpu is available from http://www.xcpu.org) Make Sure You Have The Pre-Reqs (on Ubuntu 8.04) sudo apt-get install libelfg0-dev sudo apt-get install libssl-dev Acquire the Source
svn co svn://xcpu.org/sxcpu/trunk sxcpu
cd sxcpu
make
sudo make install
To try things out on the same host (single system, no client server) % su % ssh-keygen -t rsa -f admin_key % mkdir /etc/xcpu % cp admin_key* /etc/xcpu % xcpufs & % xgroupset 127.0.0.1 root 0 % xuserset 127.0.0.1 root 0 root /root/.ssh/id_rsa.pub % xrx 127.0.0.1 /bin/date To setup a pre-existing cluster with xcpu On the front end machine (as root): % ssh-keygen -t rsa -f admin_key % mkdir /etc/xcpu % cp admin_key* /etc/xcpu (copy admin_key to each back end node - below example with ssh) % ssh root@each_back_end_server mkdir /etc/xcpu % scp admin_key root@each_back_end_server:/etc/xcpu To setup just the compute node (back-end server) % xcpufs & Then back on front-end node: % sudo xgroupset % sudo xuserset ~/.ssh/id_rsa.pub
% xrx /bin/date
trans_fd_simple
Did some really basic performance checks on trans_fd_simple compared to the older code and comparing single lock with reader/writer lock protection on the socket. Turns out my thinking with reader/writer lock was flawed and there are race cases (hence only the single threaded result). Long and short of it appears to be sort of what we figured, that the simple approach does better on single threaded workload due to less overhead, but does much worse on multi-threaded due to added latency and what not. I ran against npfs as well just to check if earlier thinking about whether or not multi-threaded npfs added much -- it appears to add nothing but overhead in this case.
This particular case was from a qemu hosted linux talking to the simulation host server -- which isn't particularly good. I'm going to replicate this test on the blade regression cluster, but wanted to do a quick check before moving on to scatter/gather implementations.
This particular case was from a qemu hosted linux talking to the simulation host server -- which isn't particularly good. I'm going to replicate this test on the blade regression cluster, but wanted to do a quick check before moving on to scatter/gather implementations.
Service Oriented File Systems
Its fun to abstract and think about web2.0 concepts in terms of Plan 9 concepts. Abstract away the gorp that makes up their implementations and think about some of the fundamental concepts. When interfaces are files, mashups are binds.
The larger picture here is about keeping this simple, language independent, and client independent. I'd like an infrastructure that I could build simple web services out of that can be viewed with a browser, or with a rich-client (like acme plug-ins). I'd like the front-end of these services to be defined in the same way the Octopus approach defines normal GUI's (except from a web-browser, the widgets are implemented by Java script). I'd like the back-end of these to be akin to big table and the chubby lock service, with a back-back-end that is simply Venti versus a database or XML.
I'll admit I'm probably naive about all of this, not having really worked on client-facing applications for some time, but I think it would be a fun thought exercise to go through and perhaps a nice refresher to actually try and implement. While part of the goal is to keep things language independent, I'll probably do things under Inferno to keep them portable for me and open up the potential for interaction with the Octopus crowd.
Of course, this all falls under the copious spare time which I have a definite deficit of -- however, I think dedicating one day a week is doable and I should be able to combine this with my constant desire to get back and look at collaborative facilities (aka warren) under Plan 9 and Inferno.
The larger picture here is about keeping this simple, language independent, and client independent. I'd like an infrastructure that I could build simple web services out of that can be viewed with a browser, or with a rich-client (like acme plug-ins). I'd like the front-end of these services to be defined in the same way the Octopus approach defines normal GUI's (except from a web-browser, the widgets are implemented by Java script). I'd like the back-end of these to be akin to big table and the chubby lock service, with a back-back-end that is simply Venti versus a database or XML.
I'll admit I'm probably naive about all of this, not having really worked on client-facing applications for some time, but I think it would be a fun thought exercise to go through and perhaps a nice refresher to actually try and implement. While part of the goal is to keep things language independent, I'll probably do things under Inferno to keep them portable for me and open up the potential for interaction with the Octopus crowd.
Of course, this all falls under the copious spare time which I have a definite deficit of -- however, I think dedicating one day a week is doable and I should be able to combine this with my constant desire to get back and look at collaborative facilities (aka warren) under Plan 9 and Inferno.
v9fs updates
With the 2.6.25 merge window rapidly approaching, it looks like I'm going to have to hold off on merging the reorganization until 2.6.26. At the moment, I'm still fiddling with the transport API and specifically the rewrite of the file descriptor based transport which is used for sockets, named pipes, etc. With a 2.6.26 target, I should be able to get the async and scatter-gather rewrites complete as well as merge the in-kernel server code from lucho.
As part of the exercise I've created a "simple" version of the code which is synchronous and single threaded (to match spfs). My motivation was to scale back and figure out what the core pieces were in the fd transport, as well as to have a useful performance baseline to measure the overhead (and advantages) of a more asynchronous model. A nice side-effect is that I also have a really simple and straightforward transport module which can be used as an example for those wanted to write their own transports. I'm not quite certain whether I want to merge the simple transport mainline though -- although I may merge it into trans_fd in order to maintain it as a baseline case -- it really amounts to a different request member function which could easily be selected via an option.
In parallel I've setup a few blades in order to measure performance, and perhaps more importantly performance regression. When complete, I hope to publish historical performance regression results back to kernel 2.6.14. At the moment I'm trying to do all collection of results and graphs inside Google docs, which should make an easy place to keep things up to date and simultaneously publish the data. I need to look around to see if anyone has hooks for the Google Data API so I can have my regression framework update the results automatically instead of me having to go in and manually enter the data.
As part of the exercise I've created a "simple" version of the code which is synchronous and single threaded (to match spfs). My motivation was to scale back and figure out what the core pieces were in the fd transport, as well as to have a useful performance baseline to measure the overhead (and advantages) of a more asynchronous model. A nice side-effect is that I also have a really simple and straightforward transport module which can be used as an example for those wanted to write their own transports. I'm not quite certain whether I want to merge the simple transport mainline though -- although I may merge it into trans_fd in order to maintain it as a baseline case -- it really amounts to a different request member function which could easily be selected via an option.
In parallel I've setup a few blades in order to measure performance, and perhaps more importantly performance regression. When complete, I hope to publish historical performance regression results back to kernel 2.6.14. At the moment I'm trying to do all collection of results and graphs inside Google docs, which should make an easy place to keep things up to date and simultaneously publish the data. I need to look around to see if anyone has hooks for the Google Data API so I can have my regression framework update the results automatically instead of me having to go in and manually enter the data.
GSoC 2008 Ideas
My Plan 9/Inferno summer of code ideas (otherwise known as projects I wish I had more time for) - projects should take no longer than 5 weeks to complete (including ramp up, debug, and packaging) -- conservatively projects should be completable in 3 weeks by experienced P9/Inferno developers and 2 weeks by folks unfamiliar with p9/inferno development environments.
- mount.9P helper program for v9fs including packaging for debian and fedora -
- hueristic for determining transport type
- DNS support for resolving hostname <->ip address
- ssh-based tunneling support (will require server work as well)
- man pages
- debian packaging
- rpm packaging
- (stretch) authentication support (w/p9p)
- (stretch) authentication support (w/o p9p)
- (stretch) integration with idmap solution
- since this is relatively straightforward it will really need to be "super" version including support for ssh tunneling, authentication, etc.
- idmap solution for v9fs - maps local uids/gids/error-codes to strings
- userspace daemon to provide mapping
- hooks in v9fs to use mapping
- (stretch) synthetic file server approach to update mappings
- OLPC Inferno Environment
- fontfs - on-demand ttf solution
- metafs - abstract metadata from underlying file system
- (stretch) Integrate OLPC translation solution for Inferno
- (stretch) OLPC oriented GUI toolkit, window manager, and toolbar
- (stretch) Inferno approach to collaboration using file systems
- Source Control Management based on Venti backend
- single branch version tracking with associated log file
- add new files/directories
- commit changes
- checkout specific version #
- (stretch) support multiple branches
- (stretch) support repository sync (push/pull)
- (stretch) support three-way merge
- wrapper for p9p vbackup to make it more user friendly
- wrapper which tracks venti scores based on volume being backed up
- GUI admin tool
- which sets up venti in partition(s) or with files
- which assists in configuring backup intervals and volumes
- (stretch) time-traveler like GUI for navigating/searching backups
- (stretch) support for pruning and/or merging snapshots
- GSoCFS for managing future community involvement with GSoC
- synethtic file system and web interface
- posting project ideas
- voting for projects
- registering student interest in projects
- project milestone tracking
- project blogs and wikis
- post-summer project success metrics (subjective and objective)
- (stretch) syndication points for community monitoring
- (stretch) potential integration with SCM
- (stretch) potential integration with some form of chat
- (stretch) potential integration with name space sharing
Page 1 | Next >>