Re: [9fans] HTTP-FUSE Xenoppix(Experimental version) Release

[Kuniyasu Suzaki <k.suzaki@aist.go.jp>]

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 <quanstro@quanstro.net>
 >>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 <k.suzaki@aist.go.jp> writes
 >>
 >>| 
 >>| 
 >>|  >>From: andrey mirtchovski <mirtchovski@gmail.com>
 >>|  >>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
 >>