Hello Sage, Thank you for your answers. Thanks go also to Brian.
> > It depends on how you define production ready. I hope to deploy it in a > semi-production environment (non customer facing machines) by years end, > but I also expect there to be problems. Even then I would absolutly not > recommend going without regular backups for important data. > > What is appropriate for your situation really depends on your requirements > for availability and durability... I agree that there are different requirements. Distributed systems in general have attracted people for different reasons - by example division of work in economic/management theory promised increased efficiency of production, while the military favor distributed systems, because they are very hard to destroy. Similarly, in the area of distributed file systems - HPC people generally prefer performance, while in commercial computing (web serving, telco, multimedia streaming) reliability and availability are the most important qualities. The latter is what concerns me rather then the former. I'll probably wait until Ceph is deployed in real-world production environment, I cannot afford to lose any data. > There is a fuse client that is fully supported. > > pNFS is something we've thought about. The problem is that moving to pNFS > throws out many of Ceph's architectural advantages. The biggest one is > the metadata clustering. AFAICS clustered pNFS metadata servers is in a > pretty early state of planning (though I'd love to see pointers to info on > pNFS metadata clustering if I'm missing something). The other is that > pNFS still keeps NFS's pretty weak consistency semantics. > > Not knowing more about pNFS metadata clustering, it's hard for me to say > how disruptive grafting a pNFS front-end on the mds would be. > > If someone really wants to use pNFS and just needs the scalable storage > backend, the simplest thing might be to write a pNFS storage driver for > Ceph's distributed object storage layer (RADOS), and forgo the Ceph MDS > entirely. You'd lose Ceph's metadata clustering, embedded inodes, > recursive accounting, and directory based snapshots, but it'd be a much > simpler system. > > sage I understand that the developer staff is rather small, as Brian said. I do not expect that someone will start pNFS frontend without Ceph backend being solid enough to be ready for production, especially when pNFS itself is far from being well-established standard (final RFC expected this year). This might change in the future, but for now it is only a future. Then again, the advantage of things like NFS and maybe pNFS is that it is standard. This might also help Ceph gaining ground on the market - support of standard protocol might attract lot more customers, especially within, rather conservative, commercial sphere. And indeed, the idea of pNFS came from HPC people, so having pNFS support might also be advantage there. The lack of metadata clustering in pNFS - oh well, I was not aware of that, thank you for pointing that out. For smaller/simpler installations with only one metadata server the pNFS might be good enough, though. Anyway please keep the FUSE client there - for the HPC (which is mostly running Linux anyway) with low-latency interconnects the in-kernel client might be of some advantage, for everything else the FUSE is good enough and most of all it is portable. One day even the still missing FUSE layer for reluctant Windows might get fixed. Regards Ales Blaha ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ceph-devel mailing list Ceph-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ceph-devel
