8000 [BUG] No "empty" chinks in empty file. · Issue #644 · moosefs/moosefs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[BUG] No "empty" chinks in empty file. #644

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
onlyjob opened this issue Feb 26, 2025 · 4 comments
Open

[BUG] No "empty" chinks in empty file. #644

onlyjob opened this issue Feb 26, 2025 · 4 comments

Comments

@onlyjob
Copy link
Contributor
onlyjob commented Feb 26, 2025 •
edited
Loading

I have a (old) large mostly empty file created on MooseFS v3. mfsfileinfo shows that it have "empty" chunks like this:

        chunk 7: empty
        chunk 8: empty
        chunk 9: empty

On current MooseFS 4.56.6, I'm trying to reproduce that by making a large empty file:

$ fallocate -l 8g 8GiB_empty.raw
fallocate: fallocate failed: Operation not supported

Ops, I wish that worked but no worries, I've made that empty file on local file system then moved it to MFS.
(File is in storage class 2.)

Now:

$ mfsfileinfo -c  8GiB_empty.raw
8GiB.empty:
        chunk 0: 000000004C04AB65_00000001 / (id:1275374437 ver:1) ; mtime:1740547377 (2025-02-26 16:22:57)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 1: 000000004C04AB66_00000001 / (id:1275374438 ver:1) ; mtime:1740547377 (2025-02-26 16:22:57)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 2: 000000004C04AB67_00000001 / (id:1275374439 ver:1) ; mtime:1740547377 (2025-02-26 16:22:57)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 3: 000000004C04AB68_00000001 / (id:1275374440 ver:1) ; mtime:1740547377 (2025-02-26 16:22:57)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 4: 000000004C04AB69_00000001 / (id:1275374441 ver:1) ; mtime:1740547378 (2025-02-26 16:22:58)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 5: 000000004C04AB6A_00000001 / (id:1275374442 ver:1) ; mtime:1740547378 (2025-02-26 16:22:58)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 6: 000000004C04AB6B_00000001 / (id:1275374443 ver:1) ; mtime:1740547378 (2025-02-26 16:22:58)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 7: 000000004C04AB6C_00000001 / (id:1275374444 ver:1) ; mtime:1740547378 (2025-02-26 16:22:58)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 8: 000000004C04AB6D_00000001 / (id:1275374445 ver:1) ; mtime:1740547378 (2025-02-26 16:22:58)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 9: 000000004C04AB6E_00000001 / (id:1275374446 ver:1) ; mtime:1740547378 (2025-02-26 16:22:58)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
        chunk 10: 000000004C04AB6F_00000001 / (id:1275374447 ver:1) ; mtime:1740547379 (2025-02-26 16:22:59)
                copy 1: 192.168.0.204:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
                copy 2: 192.168.0.250:9422 ; status:VALID ; blocks: 1024 ; checksum digest: 0486CB73567D30B815495C919B929A9E
... etc.

But all those chunks should be "empty", without any chunk files.

(For what it's worth, all my chunkservers are configured with HDD_SPARSIFY_ON_WRITE = 1 but that shouldn't matter.)
@onlyjob
Copy link
Contributor Author
onlyjob commented Feb 26, 2025 •
edited
Loading

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.

So here lies potential for obvious optimisation improvement: to detect "empty" chunks and process them accordingly, instead of burdening chunkservers with unnecessary tasks.

@chogata
Copy link
Member
chogata commented Feb 27, 2025

It's not a bug per se, it's just how the system behaves. If you create an empty file (use truncate?) directly on MooseFS, the chunks will not be created. If you copy an empty file, physical zeros will be copied (even copy from MooseFS to MooseFS). That's what happened in your example. That's what would have happened on v3 if you did it that way there (copied, not created).
Yes, we could optimise that and yes, it's somewhere on the TODO list ;)

@onlyjob
Copy link
Contributor Author
onlyjob commented Feb 27, 2025

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 were made.

I do not know of other methods to sparsify existing files...

@chogata
Copy link
Member
chogata commented Feb 27, 2025

You can't sparsify (aka delete chunks) an existing file on MooseFS. If a file is created directly on MooseFS as empty, it will not have chunks. If it's copied over from another file (even on MooseFS) it will have chunks. That's what I was saying in my previous post.

Example:

root@test:/mnt/mfs4# touch foo
root@test:/mnt/mfs4# ls -al foo
-rw-r--r-- 1 root root 0 Feb 27 17:01 foo
root@test:/mnt/mfs4# mfsfileinfo foo
foo:
	no chunks - empty file
root@test:/mnt/mfs4# truncate --size 100000000 foo
root@test:/mnt/mfs4# ls -al foo
-rw-r--r-- 1 root root 100000000 Feb 27 17:02 foo
root@test:/mnt/mfs4# mfsfileinfo foo
foo:
	no chunks - empty file
root@test:/mnt/mfs4# cp foo bar
root@test:/mnt/mfs4# ls -al bar
-rw-r--r-- 1 root root 100000000 Feb 27 17:02 bar
root@test:/mnt/mfs4# mfsfileinfo bar
bar:
	chunk 0: 00000000011EDF45_00000001 / (id:18800453 ver:1) ; mtime:1740672133 (2025-02-27 17:02:13)
		copy 1: 172.17.2.148:19422 ; status:VALID
		copy 2: 172.17.2.148:29422 ; status:VALID
	chunk 1: 00000000011EDF46_00000001 / (id:18800454 ver:1) ; mtime:1740672133 (2025-02-27 17:02:13)
		copy 1: 172.17.2.143:49422 ; status:VALID
		copy 2: 172.17.2.144:39422 ; status:VALID

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@onlyjob @chogata
0