diff options
| author | Chris Lu <chrislusf@users.noreply.github.com> | 2025-12-04 14:52:03 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-12-04 14:52:03 -0800 |
| commit | fdb888729b66c8deeed28cbe92767afa4f5a0207 (patch) | |
| tree | b0c548fbc09acc0f36bfd49ea8ace1bd720c04e8 /weed/shell/command_fs_meta_cat.go | |
| parent | 716f21fbd3fcfd424edb5517ace24d3f3696b867 (diff) | |
| download | seaweedfs-fdb888729b66c8deeed28cbe92767afa4f5a0207.tar.xz seaweedfs-fdb888729b66c8deeed28cbe92767afa4f5a0207.zip | |
fix: properly handle errors in writeToFile to prevent 0-byte EC shards (#7620)
Fixes #7619
The writeToFile function had two critical bugs that could cause data loss
during EC shard evacuation when the destination disk is full:
Bug 1: When os.OpenFile fails (e.g., disk full), the error was silently
ignored and nil was returned. This caused the caller to think the copy
succeeded.
Bug 2: When dst.Write fails (e.g., 'no space left on device'), the error
was completely ignored because the return value was not checked.
When evacuating EC shards to a full volume server (especially on BTRFS):
1. OpenFile may succeed (creates 0-byte file inode)
2. Write fails with 'no space left on device'
3. Errors were ignored, function returned nil
4. Caller thinks copy succeeded and deletes source shard
5. Result: 0-byte shard on destination, data loss!
This fix ensures both errors are properly returned, preventing data loss.
Added unit tests to verify the fix.
Diffstat (limited to 'weed/shell/command_fs_meta_cat.go')
0 files changed, 0 insertions, 0 deletions