Re: HAMMER2 design in progress - 1-2 year time frame

看板DFBSD_kernel作者t+dfbsd.時間14年前 (2011/07/01 04:01)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串9/19 (看更多)

--000e0cd2dc5cd3640f04a6f32c7f Content-Type: text/plain; charset=ISO-8859-1 Hey Matt, Since you're doing this huge redesign, I was wondering if it would be feasible to incorporate a "virtual folder" capability into hammer? It wouldn't have to be as elaborate as, say, MacOS smart folders, but even just the ability to attach labels or tags to files and folders and have views based on that would be cool. 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> > --000e0cd2dc5cd3640f04a6f32c7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Matt, <div><di= v> </div><div>Since you're doing this huge redesign, I was wondering= if it would be feasible to incorporate a "virtual folder" capabi= lity into hammer? =A0It wouldn't have to be as elaborate as, say, MacOS= smart folders, but even just the ability to attach labels or tags to files= and folders and have views based on that would be cool.</div> <div> </div>Tim <div class=3D"gmail_quote">On Wed, May 11, 2011 at 10:44 AM, Matthe= w Dillon <<a href=3D"mailto:dillon@apollo.backplane.co= m" target=3D"_blank">dillon@apollo.backplane.com</a>> wrote: <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =A0 =A0I'm almost done with the design stage for the HAMMER2 filesyste= m and =A0 =A0will soon begin coding. =A0The basic design document is here: =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= > =A0 =A0 =A0 =A0Lots of tech-speak inside, attach heat sinks to your brain!= =A0 =A0I am going to caution that I expect it to take about a year to impl= ement =A0 =A0most of the features (including the clustering bits which will be f= ully =A0 =A0integrated into the filesystem), and probably 2 years for it to rea= ch =A0 =A0production stability. =A0HAMMER2 is not going to replace HAMMER1 an= y time =A0 =A0soon. =A0 =A0In addition, HAMMER2 is going to have two serious restrictions rela= tive =A0 =A0to other filesystems. =A0(1) HAMMER2 will not support hardlinks. = =A0 And =A0 =A0(2) HAMMER2 has no physical way to resolve '..' and will de= pend on the =A0 =A0operating system's namecache to handle '..' (which Drag= onFly's will). =A0 =A0There are many reasons for these restrictions, but it mostly comes = down =A0 =A0to the complexity of cluster cache coherency and mirroring protocol= s =A0 =A0(making hardlinks extremely difficult to implement) and support for= =A0 =A0writable snapshots (making inode_num->physical translations and = parent =A0 =A0pointers extremely difficult to implement). =A0It's kind of a<b= r> =A0 =A0one-or-the-other problem. =A0 =A0HAMMER2 will also do away with the PFS concept, and instead any =A0 =A0subdirectory tree can be treated as a PFS and independently mirrore= d, =A0 =A0and also account for space & inodes used. =A0 =A0So HAMMER2 is going to have a lot of cluster-friendly features. =A0= A =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 =A0 =A0I had to make the above two tradeoffs. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0-Matt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Matthew Dillon =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" target=3D"_blank">dillon= @backplane.com</a>> </blockquote></div> </div> --000e0cd2dc5cd3640f04a6f32c7f--

‣ 返回看板[ DFBSD_kernel ] DBSD

‣ 更多 t+dfbsd. 的文章

文章代碼(AID): #1E3DO2Q0 (DFBSD_kernel)