Hi- On Sun, 15 Jun 2008, Allen Petersen wrote: > I've been following the development of ceph for a while now. I see a lot > of potential and am quite interested in seeing it progress.
Thanks. > For this reason I've been looking at getting ceph to compile on windows. > Initially I would just need ability to run a storage node on Windows and > would use a Linux box to mount and reexport the filesystem via Samba. To > this end I've spent some time trying to understand the overall > architecture and working towards getting osd compiling. It is clear that > some key abstractions need to be made to isolate the POSIX specific > items to create a cross-platform core. How would you feel about > leveraging Boost or ACE to help in creating the system? There are only a few places where things diverge from POSIX, and until about a year ago I did some development under cygwin. The two things that come to mind are O_DIRECT in ebofs and get_current_dir_name(), which is just a simple wrapper around the standard getcwd(). I'm sure some new things have snuck in, though, and obviously fuse won't work. Have you tried building it? > Initially I thought the OSBDB might be a good option as the bdb api is > the same on both platforms but since it doesn't compile I assume this is > old code and probably isn't tested much and isn't the recommended path > to take. Right. OSBDB was a student quarter project and hasn't been updated as the ObjectStore API has evolved. > Now I notice that even Ebofs is losing favor to Btrfs, which > looks very cool BTW but doesn't really help my goal to getting this > running on Windows. The snapshot stuff I'm working on now is most easily supported with btrfs. Ebofs could also be extended, or the user can simply take the performance hit of duplicating an object instead of block-level copy-on-write. The latter is the fall-back behavior of FileStore, which simply stores objects as files in the directory you specify. This is actually what the btrfs OSDs will use too... FileStore has a few hooks for tagging transactions and doing the file/object "clone" ioctl, but that's about it. The main concern with using FileStore without btrfs is that the distributed object store currently relies on atomically committing a set of writes (data writes, and xattr updates) to disk in order to maintain certain logs. These are used during recovery, and if they get out of sync, could cause data loss when nodes fail and the system recovers. There are some ways the system could bend over backwards to behave on "normal" file systems, but I'm hoping to avoid the complexity and performance hit that entails.. If you are willing to tolerate slightly weaker safety for file data in the event of a crash, you could use a handful of linux+btrfs nodes for metadata storage, and a larger cloud of windows machines for file data... > If I had a better high level picture of the system, the current state > and where you are planning on taking it would help me, and anyone else, > trying to contribute. With the ceph information now missing from the > UCSC wiki there isn't much documentation and it does take a good bit of > effort getting your head around everything. I was thinking this might be > a better place for me to start out, getting some useful information in > src/doc as to how each of the components interact. Yes, the wiki definitely needs some love. :) Any feedback on specific things that you'd like to see documented would be helpful. Cheers- sage ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ceph-devel mailing list Ceph-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ceph-devel
