On Sat, Sep 15, 2007 at 10:35:16AM -0400, Jeff Garzik wrote:many (most?) Lustre deployments are with SATA and md raid5 and GigE - can't get much cheaper than that. if you want storage node failover capabilities (which larger sites often do) or want to saturate an IB link then the price of the storage goes up but this is a consequence of wanting more reliability or performance, not anything to do with lustre. interestingly, one of the ways to provide dual-attached storage behind a failover pair of lustre servers (apart from buying SAS) would be via a networked-raid-1 device like Evgeniy's, so I don't see distributed block devices and distributed filesystems as being mutually exclusive. iSER (almost in http://stgt.berlios.de/) is also intriguing. quite likely. from what I understand (hopefully I am mistaken) they consider a merge task to be too daunting as the number of kernel subsystems that any scalable distributed filesystem touches is necessarily large. roadmaps indicate that parts of lustre are likely to move to userspace (partly to ease solaris and ZFS ports) so perhaps those performance critical parts that remain kernel space will be easier to merge. cheers, robin -
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Linus Torvalds | Linux 2.6.27-rc5 |
| Ingo Molnar | [announce] "kill the Big Kernel Lock (BKL)" tree |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Ben Hutchings | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH iproute2] Re: HTB accuracy for high speed |
