016
Twenty-four hours of Live Optics is not a workload profile
Second in the series. The collection window is the single input that most often invalidates a sizing, and it is the one nobody negotiates.
Storage
Arrays, protocols, latency, and honest numbers.
015
Reading Live Optics storage numbers without being led
Third in the series. IOPS, block size, read/write mix and the compression estimate — what each one is actually measuring, and where the sizing goes wrong.
014
What a parallel file system actually is
It is not a faster NAS. The architectural difference is that clients talk to many storage servers at once, and almost every operational surprise follows from that.
013
Metadata is the bottleneck, not bandwidth
Every parallel file system is sold on GB/s. Almost every one that disappoints in production is disappointing because of operations per second on small files.
012
Stripe count, stripe size, and the defaults that cost you most of your bandwidth
Two numbers control whether your parallel file system behaves like dozens of servers or like one. Most sites never change them.
011
Lustre in the real world: what operators actually complain about
The performance is not the issue. The issues are upgrades, client evictions, one slow target poisoning everything, and the fact that it assumes you employ someone who knows it.
010
IBM Storage Scale: what it does well, and the licensing conversation
GPFS by its older name. Technically excellent, operationally more forgiving than Lustre, and sold in a way that requires you to read carefully.
009
BeeGFS and the cluster that is too big for NFS and too small for Lustre
There is a real gap in the middle of this market, and the thing that fills it is usually the one nobody shortlisted.
008
All-flash parallel file systems: what changed and what did not
Flash removed the seek penalty that shaped twenty years of design. It did not remove the metadata bottleneck, the network limit, or the need to think about layout.
007
Sizing a parallel file system: start with bandwidth, not terabytes
Capacity is the easy number and the wrong one to start from. Here is the order that produces a design somebody can defend.
006
The small-file problem, and how machine learning made it worse
Every shared file system struggles with millions of tiny files. Training pipelines produce exactly that, and the fix is in the pipeline rather than the storage.
005
How parallel file systems fail: the modes nobody warns you about
They rarely stop. They degrade, partially and confusingly, in ways that present to users as 'the storage is slow' with no pattern.
004
You cannot back up a parallel file system the way you think
Walking a namespace of a billion files with a conventional backup agent will not finish. The strategies that work look nothing like enterprise backup.
003
Parallel file system or scale-out NAS: the decision most teams get backwards
The default answer for an enterprise AI cluster should be NAS, and the burden of proof should sit with the parallel file system. Usually it is the other way round.
002
Object storage for AI datasets: cheaper, slower, and often the right answer
Not everything needs to sit on the fast tier. The interesting design question is what moves between tiers and who decides.
001
NVMe/TCP quietly won the mid-range while everyone argued about Fibre Channel
Not because it is faster. Because it removed a team, a skill set and a second network from the build sheet.