Skip to content
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.

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

openZFS 2.0 rc3 reports fallocate supported, but not works #11073

Closed
wheelcomplex opened this issue Oct 16, 2020 · 2 comments
Closed

openZFS 2.0 rc3 reports fallocate supported, but not works #11073

wheelcomplex opened this issue Oct 16, 2020 · 2 comments
Labels
Type: Question Issue for discussion

Comments

@wheelcomplex
Copy link

Read this Go issuse for reference.

System information

Distribution Name | Ubuntu
Distribution Version | 20.04
Linux Kernel | 5.4.0-48-generic
Architecture | x86_64
ZFS Version | 2.0.0-rc3
SPL Version | 2.0.0-rc3

Describe the problem you're observing

openZFS 2.0 rc3 reports fallocate supported, but not works

Describe how to reproduce the problem

git clone https://go.googlesource.com/go && cd go/src && ./all.bash

Include any warning/errors/backtraces from the system logs

--- FAIL: TestFallocate (0.00s)
    fallocate_test.go:61: unexpected disk usage: got 1 blocks, want 2048
    fallocate_test.go:61: unexpected disk usage: got 1 blocks, want 4096
    fallocate_test.go:61: unexpected disk usage: got 1 blocks, want 6144
@wheelcomplex wheelcomplex added Status: Triage Needed New issue which needs to be triaged Type: Defect Incorrect behavior (e.g. crash, hang) labels Oct 16, 2020
@behlendorf
Copy link
Contributor

@wheelcomplex thanks for opening this issue. The ZFS behavior you're seeing is what was intended. Partial support for fallocate(2) was only recently added because its expected semantics really don't make sense for a copy-on-write filesystem. This is explained nicely in the commit message, f734301.

    Since ZFS does COW and snapshots, preallocating blocks for a file
    cannot guarantee that writes to the file will not run out of space.
    Even if the first overwrite was guaranteed, it would not handle any
    later overwrite of blocks due to COW, so strict compliance is futile.
    Instead, make a best-effort check that at least enough free space is
    currently available in the pool (with a bit of margin), then create
    a sparse file of the requested size and continue on with life.

This is functionally correct and achieves what callers are really after while avoiding the expense of preallocating blocks which won't be used. There's a good discussion in issue #326 covering the various tradeoffs and concerns.

If possible I'd suggest updating the test case to not worry about the internal filesystem details of exactly how many blocks were actually allocated.

@behlendorf behlendorf added Type: Question Issue for discussion and removed Status: Triage Needed New issue which needs to be triaged Type: Defect Incorrect behavior (e.g. crash, hang) labels Oct 16, 2020
@wheelcomplex
Copy link
Author

Thanks for the explaining and suggestion.

davepacheco pushed a commit to davepacheco/go that referenced this issue Nov 14, 2022
Basic fallocate(mode=0/2) compatibility has been added in openZFS 2.0.

Test case TestFallocate has been suggested to skip on ZFS (openzfs/zfs#11073).

fix: golang#42005

Change-Id: Ic7ea6cbcb076c8e422c4136950b5e1f2c034955c
davepacheco pushed a commit to davepacheco/go that referenced this issue Dec 21, 2022
Basic fallocate(mode=0/2) compatibility has been added in openZFS 2.0.

Test case TestFallocate has been suggested to skip on ZFS (openzfs/zfs#11073).

fix: golang#42005

Change-Id: Ic7ea6cbcb076c8e422c4136950b5e1f2c034955c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Question Issue for discussion
Projects
None yet
Development

No branches or pull requests

2 participants