bmap-tools
zfs
bmap-tools | zfs | |
---|---|---|
2 | 722 | |
222 | 10,172 | |
- | 1.1% | |
5.5 | 9.7 | |
about 2 months ago | 1 day ago | |
Python | C | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
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.
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.
zfs
- OpenZFS 2.2.4 – Linux and FreeBSD – Advanced file system and volume manager
-
Ubuntu 24.04 LTS is so buggy you can't install the OS [video]
Be careful if you use ZFS-on-root, make sure not to snapshot bpool or it will brick your system and require a complete reinstall.
https://github.com/openzfs/zfs/issues/13873
-
Radxa's SATA HAT makes compact Pi 5 NAS
> The only non-junk PCIe3 option that's even advertised here recently is the overpriced WD Red SN700.
Those WD drives seem to have some real issues, at least with ZFS and btrfs. :(
https://github.com/openzfs/zfs/discussions/14793
- OpenZFS: Fix corruption caused by MMAP flushing problems
- ZFS: Some copied files are still corrupted (chunks replaced by zeros)
-
DiskClick: Ever wanted to hear Old Hard drive sounds
IMO the "next fs" is just zfs. They somewhat recently merged RAIDZ expansion feature https://github.com/openzfs/zfs/pull/12225 and make regular improvements. If no file system has what you need today, zfs will probably be the first one to have it "tomorrow," imo.
- OpenZFS bug reports for native encryption
-
A data corruption bug in OpenZFS?
https://github.com/openzfs/zfs/issues/15526#issuecomment-181...
> zpool get all tank | grep bclone
> kc3000 bcloneused 442M
> kc3000 bclonesaved 1.42G
> kc3000 bcloneratio 4.30x
> My understanding is this: If the result is 0 for both bcloneused and bclonesaved then it's safe to say that you don't have silent corruption.
-
Ask HN: What's your "it's not stupid if it works" story?
A couple years ago, I had an idea for convincing a filesystem to go faster using 2 compression steps instead of one. I couldn't see why it wouldn't work, and I also couldn't convince myself it should.
It seems to have worked out. [1]
[1] - https://github.com/openzfs/zfs/commit/f375b23c026aec00cc9527...
-
ZFS Profiling on Arch Linux
https://github.com/openzfs/zfs/issues/7631
This is a long-standing issue with zvols which affects overall system stability, and has no real solution as of yet.
What are some alternatives?
httm - Interactive, file-level Time Machine-like tool for ZFS/btrfs/nilfs2 (and even actual Time Machine backups!)
zstd - Zstandard - Fast real-time compression algorithm
zfs-issue-15526-check-file
7-Zip-zstd - 7-Zip with support for Brotli, Fast-LZMA2, Lizard, LZ4, LZ5 and Zstandard
sanoid - These are policy-driven snapshot management and replication tools which use OpenZFS for underlying next-gen storage. (Btrfs support plans are shelved unless and until btrfs becomes reliable.)
RocksDB - A library that provides an embeddable, persistent key-value store for fast storage.
snapper - Manage filesystem snapshots and allow undo of system modifications
zfsbootmenu - ZFS Bootloader for root-on-ZFS systems with support for snapshots and native full disk encryption
zrepl - One-stop ZFS backup & replication solution
systemd - The systemd System and Service Manager
centos-stream
Netdata - The open-source observability platform everyone needs