Holes are not correctly generated(Silent corruption) #4996
Milestone
Comments
|
This looks like it would be fixed by either #4754 or #4950, both of which are in master but neither of which is in an 0.6.5.X release (yet). Could you try master and report back if you can reproduce using git master? Also, are you saying this still happens if you have the ignore_hole_birth tunable set to 1 and then do all of these steps? |
|
I have already merged those patch in 0.6.5.7. |
|
Just wanted to comment that this is definitely a new issue; occurs on Delphix's OS. The patch in #5004 appears to solve the issue; now it's just down to deciding what the best fix is. |
loyou
added a commit
to loyou/zfs
that referenced
this issue
Sep 4, 2016
Issue openzfs#4996 is ultimately caused because of a problem in the freeing logic. At the time when the dbufs are bzero'd, zfs doesn't yet have enough information to properly handle writes later in the same TXG. By changing the code to use the new dbuf_write_children_ready code path in more cases, we address this issue. The only time free_children will bzero a dbuf now is if we are freeing the entire dnode. Add Test Suite for hole_birth issues: illumos openzfs#7176, Zol openzfs#4996, Zol openzfs#5030. Change meaningless -1 into DMU_OBJECT_END
|
Closing, this was resolved in #5675. |
brad-lewis
pushed a commit
to brad-lewis/openzfs
that referenced
this issue
Apr 6, 2018
Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> As reported by openzfs/zfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. Upstream bug: DLPX-46861
brad-lewis
pushed a commit
to brad-lewis/openzfs
that referenced
this issue
Apr 13, 2018
Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> As reported by openzfs/zfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. Upstream bug: DLPX-46861
prakashsurya
pushed a commit
to brad-lewis/openzfs
that referenced
this issue
Jun 18, 2018
Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> As reported by openzfs/zfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. Closes openzfs#611
prakashsurya
pushed a commit
to openzfs/openzfs
that referenced
this issue
Jun 19, 2018
Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> Approved by: Robert Mustacchi <[email protected]> As reported by openzfs/zfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. Closes #611
lundman
pushed a commit
to openzfsonosx/zfs
that referenced
this issue
Jun 27, 2018
Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> Approved by: Robert Mustacchi <[email protected]> As reported by openzfs/zfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out.
lundman
pushed a commit
to openzfsonwindows/ZFSin
that referenced
this issue
Jul 19, 2018
Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> Approved by: Robert Mustacchi <[email protected]> As reported by openzfs/zfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out.
lundman
pushed a commit
to openzfsonwindows/ZFSin
that referenced
this issue
Jul 19, 2018
Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> Approved by: Robert Mustacchi <[email protected]> As reported by openzfs/zfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out.
behlendorf
pushed a commit
to behlendorf/zfs
that referenced
this issue
Jul 26, 2018
… birth times As reported by openzfs#4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. Porting Notes: * The DMU_OBJECT_END change in zfs_znode.c was already applied. * Added test cases from openzfs#5675 provided by @rincebrain for hole_birth issues. These test cases should be pushed upstream to OpenZFS. * Updated mk_files which is used by several rsend tests so the files created are a little more interesting and may contain holes. Authored by: Paul Dagnelie <[email protected]> Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> Approved by: Robert Mustacchi <[email protected]> Ported-by: Brian Behlendorf <[email protected]> OpenZFS-issue: https://www.illumos.org/issues/9438 OpenZFS-commit: openzfs/openzfs@738e2a3c External-issue: DLPX-46861
13 tasks
behlendorf
pushed a commit
that referenced
this issue
Jul 30, 2018
… birth times As reported by #4996, there is yet another hole birth issue. In this one, if a block is entirely holes, but the birth times are not all the same, we lose that information by creating one hole with the current txg as its birth time. The ZoL PR's fix approach is incorrect. Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. Porting Notes: * The DMU_OBJECT_END change in zfs_znode.c was already applied. * Added test cases from #5675 provided by @rincebrain for hole_birth issues. These test cases should be pushed upstream to OpenZFS. * Updated mk_files which is used by several rsend tests so the files created are a little more interesting and may contain holes. Authored by: Paul Dagnelie <[email protected]> Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> Approved by: Robert Mustacchi <[email protected]> Ported-by: Brian Behlendorf <[email protected]> OpenZFS-issue: https://www.illumos.org/issues/9438 OpenZFS-commit: openzfs/openzfs@738e2a3c External-issue: DLPX-46861 Closes #7746
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I open a new issue to check the hole birth related corruption issue separately.
This issue can be reproduced with 0.6.5.7 and latest master except ignore hole birth patch.
In this issue, holes are not generated correctly with the following steps which finally caused send/recv corruption:
we get md5sum mismatch:
let's check the indirect block of large_file in vpool/hb@s1 ,
and then the indirect block of large_file in vpool/hb@s2,
As my understanding, in the indirect block of large_file in vpool/hb@s2
it should get the indirect blocks like this:
L0 blocks at offset 20000 should be set to holes with birth time.
This hole is lost in step 2, we can get indirect blocks after step2.
During the test, I can find some point that in step3, if it expand the file size to next indirect level(L2). It will be fine.
compared with corruption file, the corrupted area are the offset 20000, which should be send as dump_free in sending stream.
The text was updated successfully, but these errors were encountered: