From 4ebd0f57c08d91d2cd63fc7581a9c22a4e521590 Mon Sep 17 00:00:00 2001
From: neilsjefferies <37909475+neilsjefferies@users.noreply.github.com>
Date: Thu, 18 Oct 2018 23:13:34 +0100
Subject: [PATCH] Filesystem features brought over from 0.1 (#246)

---
 draft/implementation-notes/index.html | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/draft/implementation-notes/index.html b/draft/implementation-notes/index.html
index a2e27441..6c4e2569 100644
--- a/draft/implementation-notes/index.html
+++ b/draft/implementation-notes/index.html
@@ -190,6 +190,24 @@ <h2>Data and Metadata</h2>
       validation and management.
     </p>
   </section>
+    
+  <section>
+    <h2>Filesystem Features</h2>
+    <p>
+      In order to be portable across as many filesystems as possible, OCFL makes use of a subset of filesystem features 
+      that are very broadly supported. It is therefore strongly advised to not use additional features in OCFL Storage
+      Roots since OCFL clients and other filesystem tools that need to operate between different filesystems may
+      exhibit unpredictable behaviour when feature sets do not match. In particular, using features such as hard and 
+      soft (symbolic) links for deduplication can work at odds with OCFL's own mechanisms and should be avoided. 
+    </p>
+    <p>
+      Consideration should also be given to calculations of storage usage when migrating between filesystems. Many 
+      back-end filesystem features, which are essentially invisible to user-space code, can have a significant
+      impact on the actual consumption of storage space compared with the a simple sum of file sizes. Compression,
+      extents and block sub-allocation are examples of such features which, while providing benefits in terms of
+      storage efficiency, do require care when considering issues of capacity planning or migration. 
+    </p>
+  </section>
 
   <section>
     <h2>Storage</h2>