Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure about the downvotes, but:

"One does not simply own/maintain a new filesystem".

Also, I wonder how much of HAMMER2 is tailored towards the DF-BSD kernel?



> I wonder how much of HAMMER2 is tailored towards the DF-BSD kernel?

Given that the same developer is porting HAMMER2 to not only OpenBSD, but also NetBSD and FreeBSD - not much.

https://github.com/kusumi


This deals with the 'original' Hammer, this is way above my head, and I don't know how much applies to either OS or the HAMMER2 so this is just me posting another link but:

"There are several major differences:

   * All VOP operations related to the namecache... those using named
     path elements like lookup, rename, etc... those are completely
     different.

     The biggest one is that our VOP_NRESOLVE() API is completely different
     from the old VOP_LOOKUP() API.  The old VOP_LOOKUP() API had to handle
     numerous side effects and I don't recall the FreeBSD namecache
     subsystem doing any namespace locking (beyond locking vnodes, that
     is).

     Also our VOP_NREMOVE() is fairly radically different... it's an all
     in one call whereas the older VOP_REMOVE was paired with a VOP_LOOKUP
     that stored side-effects (not sure if FreeBSD has cleaned that up yet).
     i.e. old was LOOKUP(save side effects) + REMOVE(use side effects).
     And DragonFly's is just NREMOVE().

   * HAMMER uses a far more sophisticated buffer cache call-back interface
     which allows HAMMER to veto write requests from the buf_daemon's (to
     enforce certain write ordering requirements).

   * DragonFly uses a locking model that I don't think FreeBSD has an API
     for (our token locking model which releases held locks within the
     model when a thread switches out and reacquires them when the thread
     switches back in).  If FreeBSD also has an API for this model this
     would be easy to port (if not for all of the above issues).

   * DragonFly uses a slightly different stacked BUF/BIO mechanic for I/O.
     This would be easy to port (if not for all of the above issues).

   * DragonFly's BUF/BIO allows for different buffer sizes within the
     file buffers (not just the device buffers).  Generally speaking
     there can be significant mixing of buffer sizes and the cluster code
     has to be able to deal with it given appropriate argumetns.  I don't
     think FreeBSD's cluster code could handle it.

   Personally I think it might be too much for a GSOC project.

                                       -Matt"

https://wiki.freebsd.org/PortingHAMMERFS




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: