Re: silent semantic changes with reiser4

[David Masover <ninja@slaphack.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans Reiser wrote:
| David Masover wrote:
|
|>
|>
|> And I did mention before about how it'd be nice for it to be an fs
|> chunk...
|
|
| Please define fs chunk. My mind has an open door.;-)

I think this is sort of like dump/restore, but for a subset of the tree.
~ So it's faster for all the reasons dump/restore are faster than tar for
a whole filesystem.  But I don't know all that much about either
dump/restore or reiser4 format plugins.

I'm defining an "fs chunk" as a complete, read-only reiser4 filesystem
of the data in question.  As a snapshot.  I'm imagining it being faster
to create and ultimately smaller and more intelligently packed than a
tarball.

What if you could get a blocklist for a directory?  Of course some
things would have to be changed to completely divorce it from the parent
filesystem and have it still be usable.

I'm imagining that literally grabbing a chunk of the filesystem -- using
its own storage layer -- would be faster than tarring.  Think like if
directories had blocklists as well as files.  It would also be smaller
- -- see below.  And it completely eliminates the question of "what may I
never back up" -- the fs already knows that.  Without having to be told
by plugins.  If the fs stores it to disk, the backup stores it, unless
it's part of the "cache" proposal.

This is a rough idea, and has issues.  For instance, how do we know
what's cache and what's not?  If you have foo.gz/ugz cached and someone
writes to foo.gz/ugz, I think that should be written to the cache and
the original foo.gz should be removed -- regenerated if necessary from
foo.gz/ugz.  But the reverse is true -- write to foo.gz and foo.gz/ugz
should go away, to be regenerated if necessary.  Only one should go into
the backup, though.  I think foo.gz goes into the backup and is
regenerated from foo.gz/ugz if necessary.  More generally, when you have
two redundant streams, backup the smaller one.

|>
|> Imagine 5000 tiny little files that, by the time reiser's done with
|> them, fit inside 5 blocks or so. It's insanely cheaper to copy the five
|> blocks than to tar them up. It also means that we don't have to worry
|> about supporting tar on other platforms -- if they don't have reiser4,
|> they need a separate converter. If apps are going to use reiser4
|> metadata for anything significant, they probably would link against some
|> sort of userland implementation of reiser4 as a Windows library, say, to
|> access the files elsewhere.
|>
|> That's extreme, but you get the idea.
|
|

P.S.  Sorry for the dupe, Hans, accidently hit "reply" instead of
"reply-to-all"...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQTUuS3gHNmZLgCUhAQKWCQ/+LTNqHvndRAMqzdAJ0rugZl30bqqPmrFs
vNqSwEx09RUxN6caOd+C4F7oVj/as0AJrNqyN5YR6/t6BKGxh+xEDnKdKiIRR5qp
/TJmsMSkh54MSqaZZPL5EB6/DjWscBN7zKCaaCN6f8xB6KU2BCOK5pNSHDvYhISA
uyD8AXrsOLRGC82dNtmh68KdrG+7VcTZMohulXNnosLLRJSuKeYEphB0i5HrvXQn
nZ010yb6LnmKtNKD+w7bFxt3ul+lQo8gti7zBJqb7mV4pa1MnQNhGZRgvey/Pq/l
ahXrrABauUFNwM4PfFWUoY9zjOdCufQpWev/mNGuoo9BS2ZiRg8LXoUpf2bOvi6I
yOTMRb37w6+w37Jv8B0vYPehW3bmuJpb+jDyZ5AYS0GygJmm3bEIFZYupYt2pU/v
7EBIzLszCEnqPbm0glGdWT5jyYiZGucvDK+W4qQ3ymEqaBIdGIti4G56mQ7bTQer
DPVT4dv38OE/PEtKb6xLQUaos7hBg+sWM5+mT9B+7kX/cYDhtdBkZpYqf10jAg34
4ufl2NS48CxqCcml7RayPVAuKT1ZN9sDcfXVYnPw33R94/lziZnfJrIInbnf9MZK
+P9v6WlFi6+9GZjwqFK9ZCJBoTCKRq1lGiy5flTDf1APAgpmU6CS/0Da4s1QiLLI
YRoeX8Nv8Us=
=WFSh
-----END PGP SIGNATURE-----