I would break it down like this: 1) FS-core: provide FS-like semantics on top of D (or Colossus/D). Apart from data format and GC challenges, the piece that is

I would break it down like this: 1) FS-core: provide FS-like semantics on top of D (or Colossus/D). Apart from data format and GC challenges, the piece that is missing is fast DC-level locking service. 2) Then, for VMs you can do FS driver, jump to VMM and booms, you are done, multiple legacy levels of re-packing and redirection are gone. For shared access cases you do NFS/Samba interceptor and then same code path as above. This system would be highly beneficial not only for Cloud, but for other Google properties as well: it would provide normal posix FS to Borg jobs. Amounts of equilibristics required to use any open-source package is enormous and by this time exceeded costs of developing FS multiple times, ask YouTube, MySQL, package management, etc groups. Another example of Google’s storage craziness is cross-dc storage. This should be low-level Colossus responsibility. Instead godzillion of teams implement their own, GCS, PD, Spanner, Placer, etc. Crazy.