--20cf305641ef758ded04a3044f78
Content-Type: text/plain; charset=ISO-8859-1
Just before steam shot out of my ears, I was thinking that this all sounded
really cool. I really like the new concept for PFS functionality.
Tim
On Wed, May 11, 2011 at 10:44 AM, Matthew Dillon <
dillon@apollo.backplane.com> wrote:
> I'm almost done with the design stage for the HAMMER2 filesystem and
> will soon begin coding. The basic design document is here:
>
> http://apollo.backplane.com/DFlyMisc/hammer2.txt
>
> Lots of tech-speak inside, attach heat sinks to your brain!
>
> I am going to caution that I expect it to take about a year to implement
> most of the features (including the clustering bits which will be fully
> integrated into the filesystem), and probably 2 years for it to reach
> production stability. HAMMER2 is not going to replace HAMMER1 any time
> soon.
>
> In addition, HAMMER2 is going to have two serious restrictions relative
> to other filesystems. (1) HAMMER2 will not support hardlinks. And
> (2) HAMMER2 has no physical way to resolve '..' and will depend on the
> operating system's namecache to handle '..' (which DragonFly's will).
>
> There are many reasons for these restrictions, but it mostly comes down
> to the complexity of cluster cache coherency and mirroring protocols
> (making hardlinks extremely difficult to implement) and support for
> writable snapshots (making inode_num->physical translations and parent
> pointers extremely difficult to implement). It's kind of a
> one-or-the-other problem.
>
> HAMMER2 will also do away with the PFS concept, and instead any
> subdirectory tree can be treated as a PFS and independently mirrored,
> and also account for space & inodes used.
>
> So HAMMER2 is going to have a lot of cluster-friendly features. A
> veritable ton, but in order to be able to implement those features
> in a reasonable time frame with a reasonably low degree of complexity
> I had to make the above two tradeoffs.
>
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
>
--20cf305641ef758ded04a3044f78
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<font face=3D"tahoma,sans-serif">Just before steam shot out of my ears, I w=
as thinking that this all sounded really cool. =A0I really like the new con=
cept for PFS functionality.<br clear=3D"all"></font><div><br></div>Tim<br>
<br><br><div class=3D"gmail_quote">On Wed, May 11, 2011 at 10:44 AM, Matthe=
w Dillon <span dir=3D"ltr"><<a href=3D"mailto:dillon@apollo.backplane.co=
m">dillon@apollo.backplane.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
=A0 =A0I'm almost done with the design stage for the HAMMER2 filesyste=
m and<br>
=A0 =A0will soon begin coding. =A0The basic design document is here:<br>
<br>
=A0 =A0 =A0 =A0<a href=3D"http://apollo.backplane.com/DFlyMisc/hammer2.txt=
" target=3D"_blank">http://apollo.backplane.com/DFlyMisc/hammer2.txt</a><br=
>
<br>
=A0 =A0 =A0 =A0Lots of tech-speak inside, attach heat sinks to your brain!=
<br>
<br>
=A0 =A0I am going to caution that I expect it to take about a year to impl=
ement<br>
=A0 =A0most of the features (including the clustering bits which will be f=
ully<br>
=A0 =A0integrated into the filesystem), and probably 2 years for it to rea=
ch<br>
=A0 =A0production stability. =A0HAMMER2 is not going to replace HAMMER1 an=
y time<br>
=A0 =A0soon.<br>
<br>
=A0 =A0In addition, HAMMER2 is going to have two serious restrictions rela=
tive<br>
=A0 =A0to other filesystems. =A0(1) HAMMER2 will not support hardlinks. =
=A0 And<br>
=A0 =A0(2) HAMMER2 has no physical way to resolve '..' and will de=
pend on the<br>
=A0 =A0operating system's namecache to handle '..' (which Drag=
onFly's will).<br>
<br>
=A0 =A0There are many reasons for these restrictions, but it mostly comes =
down<br>
=A0 =A0to the complexity of cluster cache coherency and mirroring protocol=
s<br>
=A0 =A0(making hardlinks extremely difficult to implement) and support for=
<br>
=A0 =A0writable snapshots (making inode_num->physical translations and =
parent<br>
=A0 =A0pointers extremely difficult to implement). =A0It's kind of a<b=
r>
=A0 =A0one-or-the-other problem.<br>
<br>
=A0 =A0HAMMER2 will also do away with the PFS concept, and instead any<br>
=A0 =A0subdirectory tree can be treated as a PFS and independently mirrore=
d,<br>
=A0 =A0and also account for space & inodes used.<br>
<br>
=A0 =A0So HAMMER2 is going to have a lot of cluster-friendly features. =A0=
A<br>
=A0 =A0veritable ton, but in order to be able to implement those features<=
br>
=A0 =A0in a reasonable time frame with a reasonably low degree of complexi=
ty<br>
=A0 =A0I had to make the above two tradeoffs.<br>
<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0-Matt<br>
<font color=3D"#888888"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Matthew Dillon<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0<<a href=3D"mailto:dillon@backplane.com">dillon@backplane.com</a>=
><br>
</font></blockquote></div><br>
--20cf305641ef758ded04a3044f78--