add caveats and filesystems readme files

Author: oldmoe

CAVEATS.md

@@ -0,0 +1,18 @@
+# CAVEATS
+
+This is a document that lists some caveats that you need to consider when dealing with Litestack and SQLite applications
+
+## Single host (server) only 
+
+By design, SQLite can be accessed only (in a performant and safe way) from a single host machine. That means that you cannot have things like auto-scaling of app servers since there is but a single one of them. This app server can be a huge one, with many processes, but only one app server at a time. 
+
+## Containerization becomes a bit tricky
+
+Container technology was originally designed for stateless applications. Based on this, one of the core aspects of containers is that they are immutable, deploying an app to container means destroying one container and creating another. With statefull applications, like database servers and similarly SQLite based applications, this will potentially mean a down time will be perceived, which in some approaches is mitigate but not perfectly (yet). Expect some quirks when dealing with SQLite and containers.
+
+## Single writer / multi reader 
+
+In its default configuration, Litestack allows one writer at a time to write to the database file, while simultaneously allowing any number of readers to access the database. Generally SQLite is pretty fast in writes, but you should be aware that a long running write operation will prevent any other writers from proceeding, for example creating an index on a very large table will stop other writers until the index creation is finished. There is no concurrent index creation facility in SQLite, yet.
+
+
+ 

FILESYSTEMS.md

@@ -0,0 +1,55 @@
+# Filesystems & Litestack
+
+In the containerized world we live in, many layers of the hardware/software stacks are far abstracted that we no longer know they exist. For the filesystem enthusiasts out there this is a quick overview of how Litestack (and hence SQLite) can benefit from different filesytems 
+
+## XFS
+
+A very stable and trusted filesystem with excellent performance charactersitcs 
+
+- Fast reads / writes
+
+## EXT4
+
+Another stable and performant filesystem
+
+- Fast reads / writes
+
+## F2FS 
+
+Specially built for solid state storage, has an atomic write mode that is supported by SQLite
+
+- Fast reads
+- Reasonably fast durable writes in synchronous mode
+- Compression (not very useful)
+
+## ZFS
+
+Copy-on-write filesystem with a nifty set of features, very fast snapshotting but only for the FS as a whole, can send incremental snapshots to another host for backup. Naturally a lot more pages are written on write operations thus it is a bit slower in writes.
+
+- Fast reads
+- Slower writes
+- FS Snapshotting with send/recv
+- fast device cache
+- Compression
+
+## Btrfs 
+
+Another CoW filesystem that delivers snapshotting and incremental send/recv at a much granular level.
+
+- Fast reads
+- Slower writes
+- Fast copies (free backups)
+- Sub volume Snapshotting with send/recv
+- Compression
+
+## Bcachefs
+
+A new CoW filesystem built on the foundations of the bcache module. Improving rapidly but still lacks a few of the common CoW fs features
+
+- Fast reads
+- Slower writes
+- fast device cache
+
+
+
+