onlyjob

Thanks for quick reply. I also hope that it is not a bug but I'm not convinced yet. As I've said, few months passed but it seems that orphaned chunks...

I also experienced this issue. Metalogger with `BACK_LOGS = 25` and `BACK_META_KEEP_PREVIOUS = 1` grew `changelog_ml.tmp` and `changelog_ml_back.0.mfs` to over 25 GiB each and consumed all remaining free space in...

FYI @stevew-Purdue, "Latest source" `4.57.1` have not been tagged/released yet. Perhaps you just compiled head of `master` branch? Let's not make misleading comments please.

It would be nice to publish new minor release if only for this change, @chogata. Commit 260abbf does not apply cleanly on top of 4.56.6 so backporting this change seems...

Changing Storage Class of empty file to `ec41` did not create any "empty" chunks but split all chunks to five EC parts, each with `blocks: 256 ; checksum digest: 660F33C664FA6A76B24A90D2590A3790`....

I tried the following, unsuccessfully: ``` $ fallocate -v --dig-holes 8GiB.empty fallocate: fallocate failed: keep size mode is unsupported ``` `virt-sparsify --in-place 8GiB.empty` finished without errors but no "empty" chunks...

IMHO removing corrupted chunks is safe, *if they are truly corrupted*. (See #641 for bug-report of issue when `mfschunktool` incorrectly report valid chunks of size `8192` as corrupted in fast...

Thanks! Explicit argument `-b 512` to `mfsbdev map` seems to help.

Debian 12 "bookworm" (amd64). Put my workstation to sleep overnight. Always get reproducible issue with unmap/map required after resume, in order to make block device readable.

I'm not sure about the cause... I have no multiserver configuration but I may have changed something after upgrade that caused it... The issue seems to have gone once I've...