From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 24 Jan 2006 19:57:52 +0900 Message-Id: <20060124.195752.35529086.k.suzaki@aist.go.jp> To: 9fans@cse.psu.edu Subject: Re: [9fans] HTTP-FUSE Xenoppix(Experimental version) Release From: Kuniyasu Suzaki In-Reply-To: <20060123124229.B278A78FBB@dexter-peak.quanstro.net> References: <14ec7b180601222250q2f6cc2bdm2813633da3d675a2@mail.gmail.com> <20060123.155816.88498490.k.suzaki@aist.go.jp> <20060123124229.B278A78FBB@dexter-peak.quanstro.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: e5e8c09c-ead0-11e9-9d60-3106f5b1d025 The topic has moved to another thread... but I want to make clear my approach. # If my uderstanding is wrong, please tell me. HTTP-FUSE CLOOP is pragmatic. We don't want to use special protocol and special server software. We want to utilize established infrastructures, like Web server and proxy. # We developed SFS-KNOPPIX. SFS-KNOPPIX uses Self-certifying File # System to mount root file system. It failed because it requires # special server software and lacks scalability, I guess. # SFS KNOPPIX http://unit.aist.go.jp/itri/knoppix/sfs/index-en.html # Self-certifying File System http://www.fs.net/sfswww/ httpfs (httpfile on Plan9?) may be another solution but we want to make better performance and reused transferred block data. Usually transferred block dada by file system are volatile and aren't reusable for next boot. HTTP-FUSE CLOOP divides block device in small piece and saves them to small block files. The small files are downloaded and can be saved to a local storage. They are reusable for next boot. If necessary block files are saved to a local storage, HTTP-FUSE CLOOP enables to boot OS form the local storage. Furthermore the small block files also can be cached by proxy. I will make possible scalability. The current implementation uses Coral 2P2 proxy. Coral P2P proxy project http://www.coralcdn.org/ ------ suzaki >>From: erik quanstrom >>Subject: Re: [9fans] HTTP-FUSE Xenoppix(Experimental version) Release >> >>this is an interesting idea for linux. >> >>9p is in the standard linux kernel. have you considered using 9p instead of http? >>if you did you could directly mount the cd with only the 9p kernel >>module running in the kernel. >> >>you would give up compression and caching by using 9p directly. >>but you could write a 9p server that uses your block scheme to provide >>blocks to a second 9p server that serves up the original .iso. >>both 9p servers could be mounted. no loopback or fuse would be required. >> >>- erik >> >>Kuniyasu Suzaki writes >> >>| >>| >>| >>From: andrey mirtchovski >>| >>Subject: Re: [9fans] HTTP-FUSE Xenoppix(Experimental version) Release >>| >> >>| >>> HTTP-FUSE CLOOP is a network block devide which re-constructs a block >>| >>> device from many small block files of HTTP servers. It enables to get >>| >>> root file system of Xenoppix. Driver of HTTP-FUSE CLOOP is made from >>| >>> "cloop(Compressed Loopback block device)" and "FUSE(Filesystem USErspace)". >>| >> >>| >>that sounds really complicated. i hope it's just me. >>| >>| Please visit our home page. >>| http://unit.aist.go.jp/itri/knoppix/http-fuse/xen/index-en.html >>| >>| I home following figure will help your understand. >>| http://unit.aist.go.jp/itri/knoppix/http-fuse/xen/http-fuse-driver-h.GIF >>| >>| HTTP-FUSE CLOOP is similer to Venti, I think. >>| http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html#detail >>| >>| ------ >>| suzaki >>