4 ms·

HAMMER2 I really hope the work to port HAMMER2 to OpenBSD lands in -current (and someone will own/maintain it). https://github.com/kusumi/openbsd_hammer2 http

HAMMER2 I really hope the work to port HAMMER2 to OpenBSD lands in -current (and someone will own/maintain it). https://github.com/kusumi/openbsd_hammer2 https://github.com/kusumi/openbsd_hammer2 OpenBSD lacking a modern filesystem has been an achilles heel for it. EDIT: why the downvotes?

blodorn 3y ago
There is also gefs https://orib.dev/gefs.pdf https://orib.dev/gefs.pdf with the other thinking about porting it to OpenBSD.
anonymous_union 3y ago
did you see the notes? it is confusing. Notes This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest.
SoftTalker 3y ago
It might be a stopper for some potential users, but gaining users/being popular is not a goal of the project. https://www.openbsd.org/goals.html https://www.openbsd.org/goals.html
doublepg23 3y ago
I agree, a modern FS is the biggest oversight in OpenBSD for me. I can overlook a lot of things, but filesystem corruption isn't one of them.
- tiffanyh 3y ago
  100% My concern though is this line from the readme > "This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest."
- crest 3y ago
  UFS/FFS is well tested code and won't corrupt itself, but it lacks the checksumming to detect data corruption from unreliable hardware/firmware/drivers.
  - doublepg23 3y ago
    I had a power outage corrupt UFS and another indecent due to a kernel panic while debugging a WiFi driver. I've run Linux on various filesystems for significantly longer and have never seen filesystem corruption - (excluding me not reading btrfs documentation right).
    - pnpnp 3y ago
      Did you have softupdates turned on?
      - bw86 3y ago
        As of this update, softupdates will be a NO-OP (and has been for a while in -CURRENT). This won't help you in the near future.
        pnpnp 3y ago
        I won’t go over their history, but they’ve saved me in the past. Here’s to hoping we get a modern FS soon!
deleted 3y ago
[deleted]
sillywalk 3y ago
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?
- tiffanyh 3y ago
  > 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 https://github.com/kusumi
  - sillywalk 3y ago
    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 https://wiki.freebsd.org/PortingHAMMERFS

blodorn 3y ago

There is also gefs https://orib.dev/gefs.pdf https://orib.dev/gefs.pdf with the other thinking about porting it to OpenBSD.

anonymous_union 3y ago

did you see the notes? it is confusing. Notes This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest.

SoftTalker 3y ago

It might be a stopper for some potential users, but gaining users/being popular is not a goal of the project. https://www.openbsd.org/goals.html https://www.openbsd.org/goals.html

doublepg23 3y ago

I agree, a modern FS is the biggest oversight in OpenBSD for me. I can overlook a lot of things, but filesystem corruption isn't one of them.

tiffanyh 3y ago
100% My concern though is this line from the readme > "This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest."
crest 3y ago
UFS/FFS is well tested code and won't corrupt itself, but it lacks the checksumming to detect data corruption from unreliable hardware/firmware/drivers.
- doublepg23 3y ago
  I had a power outage corrupt UFS and another indecent due to a kernel panic while debugging a WiFi driver. I've run Linux on various filesystems for significantly longer and have never seen filesystem corruption - (excluding me not reading btrfs documentation right).
  - pnpnp 3y ago
    Did you have softupdates turned on?
    - bw86 3y ago
      As of this update, softupdates will be a NO-OP (and has been for a while in -CURRENT). This won't help you in the near future.
      - pnpnp 3y ago
        I won’t go over their history, but they’ve saved me in the past. Here’s to hoping we get a modern FS soon!

deleted 3y ago

[deleted]

sillywalk 3y ago

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?

tiffanyh 3y ago
> 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 https://github.com/kusumi
- sillywalk 3y ago
  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 https://wiki.freebsd.org/PortingHAMMERFS