https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #19 from Alan Somers ---
I was able to reproduce the problem on 13.0-RELEASE, but not 14.0-CURRENT. I'm
trying stable/13 next.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #18 from Jörg Schilling ---
Please note that the apparent sparse files are not
created on the basic system that identifies as aarch64.
If I compile schilytools in an armv7 jail that runs on
the aarch64 raspi installation, only
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #17 from Robert Clausecker ---
So yeah, the same approach also works on amd64. To reproduce:
1. install archivers/star
2. make a zfs dataset and nullfs mount it somewhere.
3. in the nullfs mount, unpack the schilytools
4. buil
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #16 from Robert Clausecker ---
(In reply to Alan Somers from comment #15)
I can test on amd64; one second please.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #15 from Alan Somers ---
What about amd64? Can you test on 13.0-RELEASE with amd64? If you can provide
full steps to reproduce, including the nullfs mount options, I can test it on
14.0-CURRENT amd64.
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #14 from Robert Clausecker ---
(In reply to Alan Somers from comment #13)
Unfortunately I don't.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #13 from Alan Somers ---
This might be already fixed by
https://github.com/freebsd/freebsd-src/commit/42881526d401e7a9c09241e392b7ffa18cfe11d6
. Do you have the ability to test on 14.0-CURRENT ?
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #12 from Robert Clausecker ---
(In reply to Alan Somers from comment #11)
Yes, indeed. An fsync on the nullfs-mounted file makes it become non-sparse in
ZFS immediately. Hope this helps!
--
You are receiving this mail becau
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #11 from Alan Somers ---
Now we're getting somewhere.
* zdb shows a file that is completely sparse; it contains no data
* nullfs is involved.
Maybe your newly written file is getting cached by nullfs in the VM cache and
not fl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #10 from Robert Clausecker ---
Ok, it was a stale zpool cache file. Regenerated that. Now zdb spits out for
the defective file:
# zdb -d tau/usr/home 158868
Dataset tau/usr/home [ZPL], ID 166, cr_txg 156, 1.02G, 73710 ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #9 from Alan Somers ---
I doubt it. The cache file is probably fine. zdb must be failing for some
other reason. If you're familiar with dtrace, you can might be able to find
out why.
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #8 from Robert Clausecker ---
(In reply to Alan Somers from comment #7)
Hi Alan,
The cache file /etc/zfs/zpool.cache is there and seems fine. Here is what zdb
-C outputs:
# zdb -C
tau:
version: 5000
name: 'tau'
s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #7 from Alan Somers ---
I think I've seen zdb do that when there is no ZFS cache file. Did you disable
the ZFS cache file?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #6 from Robert Clausecker ---
(In reply to Alan Somers from comment #5)
If I try to use zdb, it gives ENOENT for whatever dataset I try to use. Looks
like this:
# zfs list tau/usr/home
NAME USED AVAIL REFER MO
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
Alan Somers changed:
What|Removed |Added
CC||asom...@freebsd.org
--- Comment #5 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #4 from Jörg Schilling ---
Does this only happen with a clone or also with a snapshot?
Since a clone is writable, it is expected to contain a copy of the
node instead of a reference to it that is used with a snapshot.
It would
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #3 from Robert Clausecker ---
I've tried to make a minimal example by cloning the file system on which I
performed the reproduction instructions, and then deleting all irrelevant
files. However, it turns out the files are actua
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
--- Comment #2 from Robert Clausecker ---
We found that on our arm64 box, the following steps somewhat consistently
produce a file afflicted with the issue:
1. on an arm64 FreeBSD 13.0 box, create an ARMv7 jail on a ZFS dataset
2. in that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
sch...@schily.net changed:
What|Removed |Added
CC||sch...@schily.net
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
Bug ID: 256205
Summary: lseek() with SEEK_HOLE some times wrongly reports
holes on ZFS
Product: Base System
Version: 13.0-STABLE
Hardware: Any
OS: Any
20 matches
Mail list logo
