https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=DistOS_2021F_2021-11-11 2026-05-13T13:31:54Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2021F_2021-11-11&diff=23453&oldid=prev 2021-11-12T04:07:53Z

<p>Created page with &quot;==Notes== &lt;pre&gt; Lecture 16 ---------- Ceph&#039;s big win over GFS: - mostly POSIX semantics - recall GFS files are really weird and have to be big - records that could be d...&quot;</p> <p><b>New page</b></p><div>==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 16<br /> ----------<br /> Ceph&#039;s big win over GFS:<br /> - mostly POSIX semantics<br /> - recall GFS files are really weird and have to be big<br /> - records that could be duplicated, not<br /> a byte stream<br /> <br /> So Ceph is a UNIX-like filesystem scaled up to arbitrarily large workloads<br /> - scalability &amp; functionality, but at the<br /> cost of complexity<br /> <br /> Note how metadata is treated differently<br /> - GFS: in the master node (one node, with hot spares)<br /> - so can&#039;t have toooo much metadata, but<br /> can have lots of data (big files, not many files)<br /> <br /> - Ceph: metadata cluster that can scale<br /> - so as many files as you want, as large or small as<br /> you want<br /> - separate from data storage (OSDs)<br /> <br /> But how do you split up metadata access across a cluster?<br /> - consider hot spots, i.e., a directory with millions of files, or a directory that everyone keeps accessing<br /> - solution: dynamic subtree partitioning<br /> <br /> Note that solutions to filesystem metadata up to this point have been specialized<br /> - Ceph is generalized<br /> <br /> But dynamic subtree partitioning only works because they did simplify the metadata problem as well<br /> - normally file metadata includes where data is stored<br /> - Ceph replaces this with CRUSH<br /> <br /> CRUSH<br /> - lets clients figure out where data is stored<br /> (in objects in the OSD&#039;s)<br /> - just need info on topology and parameters from metadata servers<br /> <br /> Note that Ceph assumes a trusted environment<br /> - just like almost all of the other systems we&#039;ve discussed<br /> - clients need to be updated on topology changes<br /> (i.e., servers being added or removed)<br /> <br /> metadata in the form of a function with parameters,<br /> not a list of what&#039;s been used and where it is<br /> - this is cool and different<br /> <br /> Consider Postscript (&amp; Display Postscript)<br /> - programming language for printers<br /> - idea: computer sends a program to printer rather than raw bitmaps or other plain image info<br /> - programming language is a bit like forth<br /> <br /> <br /> Back in the days of the original Macintosh, the Laserwriter printers Apple made had more powerful CPUs and more RAM than the Macs that drove them<br /> - needed it to create images at 300dpi for paper<br /> <br /> CRUSH is in this spirit<br /> - use math rather than raw data<br /> <br /> PDF replaced postscript<br /> - because postscript couldn&#039;t be parallelized easily<br /> (sequential program after all)<br /> <br /> Original NeXT used display postscript<br /> (interface was implemented in postscript)<br /> <br /> And MacOS&#039;s Quartz was just display PDF<br /> - advantage for apple: no royalties for postscript<br /> <br /> Sending around code rather than data is a key way we overcome the latency inherent to distributed systems<br /> - this is Javascript!<br /> &lt;/pre&gt;</div>

Soma