Subject: Problems with "fss" (file system snapshot) device
To: None <tech-kern@netbsd.org>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 12/11/2003 00:30:53
--Apple-Mail-32-482456981
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
system).
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 <thorpej@wasabisystems.com>
--Apple-Mail-32-482456981
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQE/2Cs+OpVKkaBm8XkRAn3EAJ40vLpk3DjyacsKBN78l3IfZ7LNfgCfXVuS
3I9WJuOn625pfDxgfGsNlDE=
=6hbj
-----END PGP SIGNATURE-----
--Apple-Mail-32-482456981--