Subject: Problems with "fss" (file system snapshot) device
To: None <>
From: Jason Thorpe <>
List: tech-kern
Date: 12/11/2003 00:30:53
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

This is a message for the record about some of the fundamental problems 
with the new "fss" device that was checked into the tree.  I brought 
these up before it was checked in, but unfortunately, a delay in my 
e-mail going out (caused by being on an airplane) meant that the code 
went in the tree before my messages arrived.

Anyway, here are the major issues, as I see them:

1. Snapshot backing-store cannot be allocated on the file system being 
snapshotted.  Interestingly enough, most file system snapshot 
implementations *require* the snapshots to be stored on the snapshotted 
file system.

2. Snapshot backing-store must be completely pre-allocated.  Sparse 
backing-store files are not supported.  This could be quite problematic 
for long-lived snapshots that could end up requiring more space to 
store than was pre-allocated for them.

3. Snapshots do not persist across reboots.  This is because there is 
no way of knowing if a file system was modified while the "fss" 
instance was not attached to it.  Again, this is a problem for 
long-lived snapshots.  There are plenty of scenarios where long-lived 
snapshots might be desirable (e.g. long-running back-up, policy-based 
tiered storage management, etc.).

These 3 reasons are why I generally oppose a "snapshot device" approach 
vs. a "file system implements the snapshots" approach (the latter being 
the approach taken by e.g. FreeBSD and other, proprietary file 
systems).  Issue #2 can be solved within the "device" approach, but #1 
and #3 are very difficult to solve in the "device" approach.  Solving 
#3 also probably means inverting the restriction of #1 (i.e. requiring 
that snapshot backing-store be allocated within the snapshotted file 

I really wish that the approach taken would have been more widely 
discussed e.g. here on tech-kern.  I think it's also unfortunate that 
the code was committed while I was on a plane, even though I 
specifically sent an email first saying "I'll review this while on the 
plane today".

         -- Jason R. Thorpe <>

content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

Version: GnuPG v1.2.3 (Darwin)