Re: Resize HAMMER filesystem

[Alex Burke <alexjeffburke@xxxxxxxxx>]

--089e011769cd1ea94004dbd5c197
Content-Type: text/plain; charset=UTF-8

Hi Matt,

Hope you will forgive a potentially silly question, but how do you perceive
the relationship between HAMMER1 and HAMMER2 in the future? Will the second
incarnation entirely supersede and replace the original?

At the point at which HAMMER2 is released, is it your intention that people
automatically upgrade older HAMMER to it? The feature set is certainly
compelling!

I ask because I saw a few messages per the past 6 months or so where people
were talking about perhaps contributing fixes to the utilities e.g. the
PFS softlink handling and I wondered what your feeling were about effort
being spent in that direction.

Thanks, Alex J Burke.

On Friday, 3 May 2013, Matthew Dillon wrote:

>     HAMMER1 has a number of deficiencies in this area.  It is possible
>     to add additional block devices to a HAMMER1 filesystem but it's never
>     been well tested and I don't recommend it.
>
>     HAMMER1's best feature is mirror-copy and mirror-stream.  There are
>     deficiencies here as well, particularly the issue with the root
>     filesystem not being a PFS.  Mirroring slaves can be upgraded to
> masters
>     but they cannot be downgraded again, so their best use is to track
>     near real-time backups.
>
>     Snapshots also work extremely well and the fine-grained history works
>     quite well too.
>
>     The multi-volume feature doesn't work as well as we would like, and
>     HAMMER1 doesn't have any redundancy so if you lose a HD that filesystem
>     is basically dead (would have to be rebuilt from one of the mirror
>     slaves being used as a backup).
>
>     HAMMER2 will solve a lot of these problems.  HAMMER2 has a 'super-root'
>     directory level above the root mount so mount points are basically just
>     PFS's, including the root mount.  Snapshots are writable, and there
> will
>     be a copies mechanism that treats multiple volumes as separate logical
>     filesystems (i.e. real redundancy), and will also be able to take on
> the
>     duty of adding/removing storage from a live filesystem.
>
>     HAMMER2 is not even remotely close to being production ready yet
> though.
>
>     At this point in time I am only doing minor maintainance work on
> HAMMER1.
>     All my efforts are going into HAMMER2.
>
>                                                 -Matt
>

--089e011769cd1ea94004dbd5c197
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Matt,<div><br></div><div>Hope you will forgive a potentially silly quest=
ion, but how do you perceive the relationship between HAMMER1 and HAMMER2 i=
n the future?=C2=A0Will the second incarnation entirely supersede and repla=
ce the original?</div>
<div><br></div>At the point at which HAMMER2 is released, is it your intent=
ion that people automatically=C2=A0upgrade older HAMMER to it? The=C2=A0fea=
ture set is certainly compelling!<span></span><div><br></div><div>I ask bec=
ause I saw a few messages per the past 6 months or so where people were tal=
king about=C2=A0perhaps contributing fixes to the utilities e.g. the PFS=C2=
=A0softlink handling and I wondered what your feeling were about effort bei=
ng spent in=C2=A0that direction.</div>
<div><br></div>Thanks, Alex J Burke.<br><div></div><div><br><div>On Friday,=
 3 May 2013, Matthew Dillon  wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=C2=
=A0 =C2=A0 HAMMER1 has a number of deficiencies in this area. =C2=A0It is p=
ossible<br>

=C2=A0 =C2=A0 to add additional block devices to a HAMMER1 filesystem but i=
t&#39;s never<br>
=C2=A0 =C2=A0 been well tested and I don&#39;t recommend it.<br>
<br>
=C2=A0 =C2=A0 HAMMER1&#39;s best feature is mirror-copy and mirror-stream. =
=C2=A0There are<br>
=C2=A0 =C2=A0 deficiencies here as well, particularly the issue with the ro=
ot<br>
=C2=A0 =C2=A0 filesystem not being a PFS. =C2=A0Mirroring slaves can be upg=
raded to masters<br>
=C2=A0 =C2=A0 but they cannot be downgraded again, so their best use is to =
track<br>
=C2=A0 =C2=A0 near real-time backups.<br>
<br>
=C2=A0 =C2=A0 Snapshots also work extremely well and the fine-grained histo=
ry works<br>
=C2=A0 =C2=A0 quite well too.<br>
<br>
=C2=A0 =C2=A0 The multi-volume feature doesn&#39;t work as well as we would=
 like, and<br>
=C2=A0 =C2=A0 HAMMER1 doesn&#39;t have any redundancy so if you lose a HD t=
hat filesystem<br>
=C2=A0 =C2=A0 is basically dead (would have to be rebuilt from one of the m=
irror<br>
=C2=A0 =C2=A0 slaves being used as a backup).<br>
<br>
=C2=A0 =C2=A0 HAMMER2 will solve a lot of these problems. =C2=A0HAMMER2 has=
 a &#39;super-root&#39;<br>
=C2=A0 =C2=A0 directory level above the root mount so mount points are basi=
cally just<br>
=C2=A0 =C2=A0 PFS&#39;s, including the root mount. =C2=A0Snapshots are writ=
able, and there will<br>
=C2=A0 =C2=A0 be a copies mechanism that treats multiple volumes as separat=
e logical<br>
=C2=A0 =C2=A0 filesystems (i.e. real redundancy), and will also be able to =
take on the<br>
=C2=A0 =C2=A0 duty of adding/removing storage from a live filesystem.<br>
<br>
=C2=A0 =C2=A0 HAMMER2 is not even remotely close to being production ready =
yet though.<br>
<br>
=C2=A0 =C2=A0 At this point in time I am only doing minor maintainance work=
 on HAMMER1.<br>
=C2=A0 =C2=A0 All my efforts are going into HAMMER2.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 -Matt<br>
</blockquote></div></div>

--089e011769cd1ea94004dbd5c197--