<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://transactional.blog/how-to-learn/disk-io"/>
	<rdf:li rdf:resource="https://aws.amazon.com/s3/features/mountpoint/"/>
	<rdf:li rdf:resource="https://github.com/Feh/nocache"/>
	<rdf:li rdf:resource="https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance"/>
	<rdf:li rdf:resource="https://github.com/8051Enthusiast/regex2fat"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/"/>
	<rdf:li rdf:resource="https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f"/>
	<rdf:li rdf:resource="https://medium.com/making-instapaper/instapaper-outage-cause-recovery-3c32a7e9cc5f#.39bn4xjas"/>
	<rdf:li rdf:resource="http://pl.atyp.us/2016-06-torus.html"/>
	<rdf:li rdf:resource="http://www.scylladb.com/2016/02/16/fault-injection-filesystem-software-testing/"/>
	<rdf:li rdf:resource="http://danluu.com/file-consistency/"/>
	<rdf:li rdf:resource="http://epickrram.blogspot.co.uk/2015/12/journalling-revisited.html"/>
	<rdf:li rdf:resource="https://bitbucket.org/nikratio/s3ql"/>
	<rdf:li rdf:resource="https://github.com/danilop/yas3fs"/>
	<rdf:li rdf:resource="http://jpetazzo.github.io/assets/2015-07-01-deep-dive-into-docker-storage-drivers.html#43"/>
	<rdf:li rdf:resource="http://blog.cloud66.com/docker-with-overlayfs-first-impression/"/>
	<rdf:li rdf:resource="http://en.wikipedia.org/wiki//dev/full"/>
	<rdf:li rdf:resource="https://clusterhq.com/blog/state-zfs-on-linux/"/>
	<rdf:li rdf:resource="http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html"/>
	<rdf:li rdf:resource="https://bitbucket.org/nikratio/s3ql/overview"/>
	<rdf:li rdf:resource="http://hoytech.com/vmtouch/"/>
	<rdf:li rdf:resource="http://glinden.blogspot.com/2010/03/gfs-and-its-evolution.html"/>
	<rdf:li rdf:resource="http://lwn.net/Articles/342892/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://transactional.blog/how-to-learn/disk-io">
    <title>How to Learn: Userland Disk I/O</title>
    <dc:date>2024-11-08T13:21:19+00:00</dc:date>
    <link>https://transactional.blog/how-to-learn/disk-io</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is an interesting hodge-podge of key bits of information about disk I/O, file integrity and durability, buffering or unbuffered writes, async I/O, and which filesystems to use for high-I/O database operation on Linux, MacOS and Windows.  One thing that was new to me: "You can periodically scrape /proc/diskstats to self-report on disk metrics".]]></description>
<dc:subject>databases filesystems linux macos fsync durability coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:95771a126b07/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:macos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fsync"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:durability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/s3/features/mountpoint/">
    <title>Mountpoint for S3</title>
    <dc:date>2023-08-09T15:58:39+00:00</dc:date>
    <link>https://aws.amazon.com/s3/features/mountpoint/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An officially-supported Linux filesystem client for Amazon S3, now GA]]></description>
<dc:subject>s3 clients oss linux aws filesystems unix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f96c68c04ef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clients"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Feh/nocache">
    <title>Feh/nocache</title>
    <dc:date>2020-09-23T10:43:42+00:00</dc:date>
    <link>https://github.com/Feh/nocache</link>
    <dc:creator>jm</dc:creator><description><![CDATA[minimize filesystem caching effects:

<blockquote>
The nocache tool tries to minimize the effect an application has on the Linux file system cache. This is done by intercepting the open and close system calls and calling posix_fadvise() with the POSIX_FADV_DONTNEED parameter. Because the library remembers which pages (ie., 4K-blocks of the file) were already in file system cache when the file was opened, these will not be marked as "don't need", because other applications might need that, although they are not actively used (think: hot standby).</blockquote>

]]></description>
<dc:subject>cache linux memory performance filesystems backup k8s unix fadvise</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bd12d7ea46ac/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fadvise"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance">
    <title>Raspberry Pi USB Boot - UASP, TRIM, and performance</title>
    <dc:date>2020-09-21T10:38:32+00:00</dc:date>
    <link>https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>In the past few weeks, I reviewed USB drive performance on the Raspberry Pi 4, and the importance of UASP support for USB drive performance.
Both posts generated great discussion, and there were three things I wanted to cover in this follow-up, namely: Which drives support UASP; Real-world performance benchmarks; TRIM support.</blockquote>

]]></description>
<dc:subject>raspberry-pi optimization linux trim ssd filesystems usb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:36695789d680/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raspberry-pi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trim"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/8051Enthusiast/regex2fat">
    <title>8051Enthusiast/regex2fat</title>
    <dc:date>2020-04-15T12:03:35+00:00</dc:date>
    <link>https://github.com/8051Enthusiast/regex2fat</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Turn your favourite regex into FAT32.  'Haha OS-driven regex engine go brrrrr'
]]></description>
<dc:subject>insane stupid funny fat32 drivers filesystems regexps regex</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:44aedb42f788/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:insane"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stupid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fat32"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:drivers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regexps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regex"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/">
    <title>Amazon EBS Multi-Attach now available on Provisioned IOPS io1 volumes</title>
    <dc:date>2020-02-17T10:49:05+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Attach multiple EC2 instances to the same EBS volume.  Now that is pretty cool]]></description>
<dc:subject>ebs ec2 filesystems networking ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f99d09d89c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f">
    <title>Another reason why your Docker containers may be slow</title>
    <dc:date>2018-04-06T11:33:20+00:00</dc:date>
    <link>https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f</link>
    <dc:creator>jm</dc:creator><description><![CDATA[TL;DR: fadvise() is a bottleneck on Linux machines running many containers]]></description>
<dc:subject>linux fadvise filesystems performance docker containers ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9015116d6c92/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fadvise"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/making-instapaper/instapaper-outage-cause-recovery-3c32a7e9cc5f#.39bn4xjas">
    <title>Instapaper Outage Cause &amp; Recovery</title>
    <dc:date>2017-02-14T10:42:03+00:00</dc:date>
    <link>https://medium.com/making-instapaper/instapaper-outage-cause-recovery-3c32a7e9cc5f#.39bn4xjas</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Hard to see this as anything other than a pretty awful documentation fail by the AWS RDS service:

<blockquote>Without knowledge of the pre-April 2014 file size limit, it was difficult to foresee and prevent this issue. As far as we can tell, there’s no information in the RDS console in the form of monitoring, alerts or logging that would have let us know we were approaching the 2TB file size limit, or that we were subject to it in the first place. Even now, there’s nothing to indicate that our hosted database has a critical issue.</blockquote>

]]></description>
<dc:subject>limits aws rds databases mysql filesystems ops instapaper risks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:70ad5bf26582/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:limits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instapaper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:risks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://pl.atyp.us/2016-06-torus.html">
    <title>Collecting my thoughts about Torus</title>
    <dc:date>2016-06-07T10:42:01+00:00</dc:date>
    <link>http://pl.atyp.us/2016-06-torus.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Worryingly-optimistic communications about CoreOS' recently-announced distributed storage system. I had similar thoughts, but Jeff Darcy is actually an expert on this stuff so he's way more worth listening to on the topic ;)]]></description>
<dc:subject>jeff-darcy distcomp filesystems coreos torus storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9e388f6ae979/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jeff-darcy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coreos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:torus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.scylladb.com/2016/02/16/fault-injection-filesystem-software-testing/">
    <title>CharybdeFS: a new fault-injecting filesystem for software testing</title>
    <dc:date>2016-02-17T14:40:52+00:00</dc:date>
    <link>http://www.scylladb.com/2016/02/16/fault-injection-filesystem-software-testing/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a FUSE-based filesystem from ScyllaDB to test filesystem-related failure scenarios. great idea
]]></description>
<dc:subject>fuse software testing scylladb filesystems disk charybdefs fault-injection tests</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f13d512cee10/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fuse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scylladb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:charybdefs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-injection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tests"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://danluu.com/file-consistency/">
    <title>Files Are Hard</title>
    <dc:date>2015-12-14T11:15:12+00:00</dc:date>
    <link>http://danluu.com/file-consistency/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is basically terrifying.  A catalog of race conditions and reliability horrors around the POSIX filesystem abstraction in Linux -- it's a wonder anything works.

'Where’s this documented? Oh, in some mailing list post 6-8 years ago (which makes it 12-14 years from today). The fs devs whose posts I’ve read are quite polite compared to LKML’s reputation, and they generously spend a lot of time responding to basic questions, but it’s hard for outsiders to troll [sic] through a decade and a half of mailing list postings to figure out which ones are still valid and which ones have been obsoleted! I don’t mean to pick on filesystem devs.  In their OSDI 2014 talk, the authors of the paper we’re discussing noted that when they reported bugs they’d found, developers would often respond “POSIX doesn’t let filesystems do that”, without being able to point to any specific POSIX documentation to support their statement. If you’ve followed Kyle Kingsbury’s Jepsen work, this may sound familiar, except devs respond with “filesystems don’t do that” instead of “networks don’t do that”.I think this is understandable, given how much misinformation is out there. Not being a filesystem dev myself, I’d be a bit surprised if I don’t have at least one bug in this post.']]></description>
<dc:subject>filesystems linux unix files operating-systems posix fsync osdi papers reliability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a449535f1673/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:files"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:operating-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:posix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fsync"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osdi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://epickrram.blogspot.co.uk/2015/12/journalling-revisited.html">
    <title>Low-latency journalling file write latency on Linux</title>
    <dc:date>2015-12-09T14:58:39+00:00</dc:date>
    <link>http://epickrram.blogspot.co.uk/2015/12/journalling-revisited.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[great research from LMAX: xfs/ext4 are the best choices, and they explain why in detail, referring to the code]]></description>
<dc:subject>linux xfs ext3 ext4 filesystems lmax performance latency journalling ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9b225ebb15c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ext3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ext4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lmax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:journalling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://bitbucket.org/nikratio/s3ql">
    <title>S3QL</title>
    <dc:date>2015-09-01T14:34:18+00:00</dc:date>
    <link>https://bitbucket.org/nikratio/s3ql</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a file system that stores all its data online using storage services like Google Storage, Amazon S3, or OpenStack. S3QL effectively provides a hard disk of dynamic, infinite capacity that can be accessed from any computer with internet access running Linux, FreeBSD or OS-X.
S3QL is a standard conforming, full featured UNIX file system that is conceptually indistinguishable from any local file system. Furthermore, S3QL has additional features like compression, encryption, data de-duplication, immutable trees and snapshotting which make it especially suitable for online backup and archival.
S3QL is designed to favor simplicity and elegance over performance and feature-creep. Care has been taken to make the source code as readable and serviceable as possible. Solid error detection and error handling have been included from the very first line, and S3QL comes with extensive automated test cases for all its components.</blockquote>

]]></description>
<dc:subject>filesystems aws s3 storage unix google-storage openstack</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7f4f3290c9ff/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openstack"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/danilop/yas3fs">
    <title>danilop/yas3fs · GitHub</title>
    <dc:date>2015-07-30T21:54:08+00:00</dc:date>
    <link>https://github.com/danilop/yas3fs</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>YAS3FS (Yet Another S3-backed File System) is a Filesystem in Userspace (FUSE) interface to Amazon S3. It was inspired by s3fs but rewritten from scratch to implement a distributed cache synchronized by Amazon SNS notifications. A web console is provided to easily monitor the nodes of a cluster.</blockquote>

]]></description>
<dc:subject>aws s3 s3fs yas3fs filesystems fuse sns</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fee4884e5c7f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3fs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yas3fs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fuse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sns"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jpetazzo.github.io/assets/2015-07-01-deep-dive-into-docker-storage-drivers.html#43">
    <title>Deep Dive Into Docker Storage Drivers</title>
    <dc:date>2015-07-20T17:08:55+00:00</dc:date>
    <link>http://jpetazzo.github.io/assets/2015-07-01-deep-dive-into-docker-storage-drivers.html#43</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good detail in this presentation]]></description>
<dc:subject>docker overlayfs aufs btrfs filesystems ops linux containers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8e7e75a8ed4e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:overlayfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aufs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:btrfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cloud66.com/docker-with-overlayfs-first-impression/">
    <title>Docker with OverlayFS first impressions</title>
    <dc:date>2015-07-15T15:44:26+00:00</dc:date>
    <link>http://blog.cloud66.com/docker-with-overlayfs-first-impression/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a brief howto]]></description>
<dc:subject>overlayfs docker filesystems ops linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:abef57e1c7ee/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:overlayfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://en.wikipedia.org/wiki//dev/full">
    <title>/dev/full - Wikipedia, the free encyclopedia</title>
    <dc:date>2014-11-14T11:17:18+00:00</dc:date>
    <link>http://en.wikipedia.org/wiki//dev/full</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is handy!

'In Linux, /dev/full or the always full device[1][2] is a special file that always returns the error code ENOSPC (meaning "No space left on device") on writing, and provides an infinite number of null characters to any process that reads from it (similar to /dev/zero). This device is usually used when testing the behaviour of a program when it encounters a "disk full" error.']]></description>
<dc:subject>dev /dev/full filesystems devices linux testing enospc error-handling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:169c08da2b2d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:/dev/full"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:enospc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:error-handling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://clusterhq.com/blog/state-zfs-on-linux/">
    <title>The State of ZFS on Linux</title>
    <dc:date>2014-09-15T09:05:14+00:00</dc:date>
    <link>https://clusterhq.com/blog/state-zfs-on-linux/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Linux users familiar with other filesystems or ZFS users from other platforms will often ask whether ZFS on Linux (ZoL) is “stable”. The short answer is yes, depending on your definition of stable. The term stable itself is somewhat ambiguous.</blockquote>

Oh dear. that's not a good start. Good reference page, though]]></description>
<dc:subject>zfs linux filesystems ops solaris</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:15912aa744a6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:solaris"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html">
    <title>Revisiting How We Put Together Linux Systems</title>
    <dc:date>2014-09-01T22:26:39+00:00</dc:date>
    <link>http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Building a running OS out of layered btrfs filesystems.  This sounds awesome.

<blockquote>Instantiating a new system or OS container (which is exactly the same in this scheme) just consists of creating a new appropriately named root sub-volume. Completely naturally you can share one vendor OS copy in one specific version with a multitude of container instances.

Everything is double-buffered (or actually, n-fold-buffered), because usr, runtime, framework, app sub-volumes can exist in multiple versions. Of course, by default the execution logic should always pick the newest release of each sub-volume, but it is up to the user keep multiple versions around, and possibly execute older versions, if he desires to do so. In fact, like on ChromeOS this could even be handled automatically: if a system fails to boot with a newer snapshot, the boot loader can automatically revert back to an older version of the OS.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf linux docker btrfs filesystems unionfs copy-on-write os hacking unix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b9563993a8c5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:btrfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unionfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:copy-on-write"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:os"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://bitbucket.org/nikratio/s3ql/overview">
    <title>S3QL</title>
    <dc:date>2014-03-18T21:29:53+00:00</dc:date>
    <link>https://bitbucket.org/nikratio/s3ql/overview</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a file system that stores all its data online using storage services like Google Storage, Amazon S3, or OpenStack. S3QL effectively provides a hard disk of dynamic, infinite capacity that can be accessed from any computer with internet access running Linux, FreeBSD or OS-X.

S3QL is a standard conforming, full featured UNIX file system that is conceptually indistinguishable from any local file system. Furthermore, S3QL has additional features like compression, encryption, data de-duplication, immutable trees and snapshotting which make it especially suitable for online backup and archival.</blockquote>

]]></description>
<dc:subject>s3 s3ql backup aws filesystems linux freebsd osx ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ebbb82ef8807/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3ql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:freebsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://hoytech.com/vmtouch/">
    <title>vmtouch - the Virtual Memory Toucher</title>
    <dc:date>2011-12-04T22:51:37+00:00</dc:date>
    <link>http://hoytech.com/vmtouch/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['vmtouch is a tool for learning about and controlling the file system cache of unix and unix-like systems. It is BSD licensed.']]></description>
<dc:subject>vmtouch vm linux unix fs filesystems instagram</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9b2b286e0d35/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vmtouch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instagram"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://glinden.blogspot.com/2010/03/gfs-and-its-evolution.html">
    <title>Geeking with Greg: GFS and its evolution</title>
    <dc:date>2010-03-15T23:30:21+00:00</dc:date>
    <link>http://glinden.blogspot.com/2010/03/gfs-and-its-evolution.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[GFS, warts and all]]></description>
<dc:subject>google gfs filesystems networking</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:38ba2cbced7c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lwn.net/Articles/342892/">
    <title>A short history of btrfs [LWN.net]</title>
    <dc:date>2009-08-01T10:31:58+00:00</dc:date>
    <link>http://lwn.net/Articles/342892/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[wow, sounds good! looking forward to this hitting production-ready status]]></description>
<dc:subject>btrfs history zfs linux open-source licensing storage sysadmin b-trees b+trees algorithms fs filesystems</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:eabded4de881/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:btrfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:licensing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:b-trees"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:b+trees"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>