> It sounds like you're looking at a clustered file system. Where on the > Fast/Cheap/Reliable triangle do you want to land?
Well, of course, all three. ;-) Fast and cheap are requirements. For reliability, it is acceptable to use simple disk mirroring on a single host. It needs to be protected against a single disk failure, but does not need to be protected against a machine failure or scsi/sata bus failure. At present, each machine's /scratch disk is either a mirror or a raid5, depending on which machine in question. > Keep in mind: you > should accept that if you want to have all systems see the same unified > file system and not have a shared storage media (fibre, iSCSI, etc), > then you will have your reads and writes go across the network. The goal I'm trying to accomplish - it's expected that some amount of network traffic is required, but it should be minimal. If a 1G file is created on some machine, then a few packets should fly across the network, just to say the file exists. But 1G should not go anywhere. > If you're looking for fast/cheap, then you might want to look at Lustre > (http://www.lustre.org/). It works well on RHEL & SUSE derivatives, > makes use of distributed resources. It does have support for > Infiniband if you've got that. Lustre writes across multiple nodes and > multiple partitions in order to gain speed. I think you're saying - it writes across more than one machine, which would slow down the write operation, but then when a read request comes in, the read could go faster because there's more than one machine available. So "in order to gain speed" assumes a usage pattern of reading more times than you write. Similar to the google gfs behavior. Unfortunately not accurate for the users I support. :-( Perhaps it's a configuration parameter? Perhaps you could, if you want to, tell the system to write files on a single host, and then when some other host reads the file, it finally goes across the network? I've heard of lustre, but never seen it or read anything about it before. > Additionally, it uses > block-level locking instead of file-level locking which can also speed > things up. Be warned: there is a fairly steep learning curve for > Lustre. Acknowledged. Thanks for the heads-up. _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
