* Posts by rmurphy

2 publicly visible posts • joined 1 Aug 2016

Building iRODS to take load off scientists' back

rmurphy

This doesn't work

Hi Chris,

The architecture described here does not have a "single file namespace".

Each iRODS zone has its own namespace and is its own administrative entity, so there are 3 separate namespaces in this deployment as shown - one for each storage system.

Further (incredibly), metadata does not get transferred when files are copied between zones.

Given these constraints, the usefulness of this architecture seems dubious.

Hasta la vista Lustre, so long Spectrum Scale: Everyday HPC is here

rmurphy

Parallel File Systems were not developed for IOPS

Hi Chris,

Lustre and GPFS were developed to be a shared storage resource for a cluster of computers, they were not "developed to overcome delays servers experienced when accessing files on disk storage systems".

They have always been best at providing HIGH THROUGHPUT and CAPACITY, neither of which FLASH is better at economically (YET). Further, parallel file systems have been predominantly deployed with lower speed, higher capacity disk media supporting this use case.

Your assertion: "Flash arrays get rid of disk access latencies and so weaken the need for parallel file systems" misunderstands the predominant shared resource, high throughput, high capacity deployment model for parallel file systems and incorrectly conflates their supposed demise to the ascendancy of flash for high IOPS use cases. They solve two different problems.