[ ... ] > Is there a filesystem that's really suitable for EC2? What > about workloads? my impression is that EC2 is fine for > whatever doesn't need any QoS. Prototyping, for instance. That's one use, but it is wider than that. Services like that are good for "emarassingly parallel" workloads, where the QoS of *a single* element does not matter, or even the *performance* (or the *reliability*) of a single element is less important, at least compared to the ability to throw a lot of cheap ones at a problem. Largely the same domain of application as the Google platform, where their "embarassingly parallel" workload is log generation and analysis. Which advises that on EC2 simpler is better, and 'ext2' might be most appropriate for non-shared applications. XFS, being like JFS a rather general purpose design, looks appropriate, even if as mentioned in another reply, it is aimed at massive and highly parallel storage layers with highly threaded applications. Aside note: I think that on most VM systems using "virtual disks" of any sort except to store he OS filetree which is mostly RO is a bad idea, and I suffered a lot last year dealing with a rather hastily thrown together setup of that sort. In that case I eliminated all but the root filetree VM disks and replaced them with filetrees exported via NFS from XFS on the underlying VM host itself (that is not over the network). This improved performance tremendously (in part because in most VM layers virtual NICs are more efficient than virtual disk adapters) but in particular much faster check/repair and much reduced crazy latencies during backups, because I could run check/repair and the backups *on the real machine*, where XFS performed a lot better without the VM overheads and "skewed" latencies. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
