bcachefs
bmap-tools
bcachefs | bmap-tools | |
---|---|---|
5 | 2 | |
601 | 222 | |
- | - | |
10.0 | 5.5 | |
4 days ago | about 1 month ago | |
C | Python | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
bcachefs
-
A data corruption bug in OpenZFS?
I'm keeping an eye on it but it's not there yet e.g. https://github.com/koverstreet/bcachefs/issues/619#issuecomm...
-
Bcachefs File-System Plans to Try Again to Land in Linux 6.6
Bcachefs does not yet implement scrubs. Corrupted data can be detected, reading instead from a copy (if available). But the problems get neither reported nor fixed. So does not seem production ready yet...
https://github.com/koverstreet/bcachefs/issues/146
-
Proxmox (7.3). Bcachefs do not work. [v6.0]. filesystem may have incompatible bkey formats; run fsck from the compat branch to fix
Clone a stable kernel-pve git tree, add as remote https://github.com/koverstreet/bcachefs Then merge the correct tree into the latest stable kernel-pve release.
- Is a dkms technically possible?
-
Sorry to annoy but How to create bcachefs disk image or install it inside qemu running into error?
I compiled https://github.com/koverstreet/bcachefs with the suggested instructions and did apt install -y bcachefs-tools linux-bcachefs after adding the bcachefs ppa. I then ran this script and was unable to mount https://gist.github.com/docfate111/135c130d38dd185c71d0b24ed41eb646 also when i was able to mount bcachefs qemu shows a segmentation fault and error about not recognizing filesystem
bmap-tools
-
A data corruption bug in OpenZFS?
> But I recall reading elsewhere a discussion about some userspace program which did depend on holes being present in the filesystem as actual holes (visible to SEEK_HOLE and so on) and not as runs of zeros.
> treatment of on-disk segments as "what was written by programs" can cause areas of 0 to not be written by bmaptool copy
https://github.com/intel/bmap-tools/issues/75
IMO, the issue here isn't filesystem or zfs behavior, it's that bmap-tool wants an extra "don't care bit" per block, which filesystems (traditionally) don't track, and programs interacting with filesystem don't expect to exist.
Some of the comments I've made in this issue describe options to make things better.
-
ZFS silent corruption bug found: replaces chunks inside copied files by zeroes
(>_<) Oh man, I knew about [0] when I posted (which is why I said it just reduces the chance of hitting the bug (by a lot)). But after spending all Saturday JST on it, I went to bed before [1] was posted.
Skimming through #6958 though, it seems like it's the lesser of evils, compared to #15526... I think? It's less obvious (to me) what the impact of #6958 is. Is it silent undetectable corruption of your precious data potentially over years, or more likely to cause a crash or runtime error?
Reports like https://github.com/intel/bmap-tools/issues/65 make it seem more like the latter.
But I have to read more. But since the zfs_dmu_offset_next_sync setting was disabled by default until recently, I still suspect (but yeah, don't know for sure) that disabling is the safest thing we can currently do on unmodified ZFS systems.
What are some alternatives?
zfs - OpenZFS on Linux and FreeBSD
linux-tkg - linux-tkg custom kernels
httm - Interactive, file-level Time Machine-like tool for ZFS/btrfs/nilfs2 (and even actual Time Machine backups!)
hn-search - Hacker News Search
zfs-issue-15526-check-file