Feature #37
import disk from freens 7.2
Status:
Closed
Priority:
Important
Assignee:
-
Category:
Middleware
Target version:
-
Estimated time:
Severity:
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
Description
Hi,
firstable I would like to congratulate you for your job.
I wanted to know how to import my disk from freens 7.2 to freenas 8.
Have a good day.
Boris
P.S : sorry formy english, I'm french
Associated revisions
HBSD NOEXEC: remove old linux mmap hack
github-issue: #37 #4
Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
(cherry picked from commit 4d78843028ecaa97de9952202755238275d2f3be)
(cherry picked from commit 7968b7e9d28fae9a49a7893a1b0c1fcdee5e3692)
HBSD NOEXEC: remove old linux mmap hack
github-issue: #37 #4
Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
(cherry picked from commit 4d78843028ecaa97de9952202755238275d2f3be)
(cherry picked from commit 7968b7e9d28fae9a49a7893a1b0c1fcdee5e3692)
6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>
Reviewed by: Stefan Ring <stefanrin@gmail.com>
Reviewed by: Steven Burgess <sburgess@datto.com>
Reviewed by: Arne Jansen <sensille@gmx.net>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Paul Dagnelie <pcd@delphix.com>
In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.
The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).
Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).
Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).
We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).
The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).
Closes #37
6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>
Reviewed by: Stefan Ring <stefanrin@gmail.com>
Reviewed by: Steven Burgess <sburgess@datto.com>
Reviewed by: Arne Jansen <sensille@gmx.net>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Paul Dagnelie <pcd@delphix.com>
In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.
The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).
Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).
Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).
We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).
The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).
Closes #37
MFV r296609: 6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>
Reviewed by: Stefan Ring <stefanrin@gmail.com>
Reviewed by: Steven Burgess <sburgess@datto.com>
Reviewed by: Arne Jansen <sensille@gmx.net>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Paul Dagnelie <pcd@delphix.com>
In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.
The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).
Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).
Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).
We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).
The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).
Closes #37
openzfs/openzfs@adef853162e83f7cdf6b2d9af9756d434a9c743b
MFV r296609: 6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>
Reviewed by: Stefan Ring <stefanrin@gmail.com>
Reviewed by: Steven Burgess <sburgess@datto.com>
Reviewed by: Arne Jansen <sensille@gmx.net>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Paul Dagnelie <pcd@delphix.com>
In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.
The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).
Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).
Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).
We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).
The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).
Closes #37
openzfs/openzfs@adef853162e83f7cdf6b2d9af9756d434a9c743b
MFV r296609: 6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>
Reviewed by: Stefan Ring <stefanrin@gmail.com>
Reviewed by: Steven Burgess <sburgess@datto.com>
Reviewed by: Arne Jansen <sensille@gmx.net>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Paul Dagnelie <pcd@delphix.com>
In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.
The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).
Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).
Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).
We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).
The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).
Closes #37
openzfs/openzfs@adef853162e83f7cdf6b2d9af9756d434a9c743b
git-svn-id: svn+ssh://svn.freebsd.org/base/head@296610 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
MFV r296609: 6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>
Reviewed by: Stefan Ring <stefanrin@gmail.com>
Reviewed by: Steven Burgess <sburgess@datto.com>
Reviewed by: Arne Jansen <sensille@gmx.net>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Paul Dagnelie <pcd@delphix.com>
In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.
The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).
Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).
Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).
We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).
The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).
Closes #37
openzfs/openzfs@adef853162e83f7cdf6b2d9af9756d434a9c743b
git-svn-id: svn+ssh://svn.freebsd.org/base/head@296610 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
History
#1
Updated by Josh Paetzel over 9 years ago
Updated by Josh Paetzel - Status changed from Unscreened to Closed
#2
Updated by Jordan Hubbard about 5 years ago
Updated by Jordan Hubbard - Target version deleted (
2)
#3
Updated by Kris Moore almost 5 years ago
Commit: eb419ad5c7a01c6a42ad5b2226ed2ce7fafd53f4
https://github.com/pcbsd/freebsd-ports/commit/eb419ad5c7a01c6a42ad5b2226ed2ce7fafd53f4
Author: Bernard Spil <Sp1l@users.noreply.github.com>
Date: 2015-09-25 (Fri, 25 Sep 2015)
Log Message:
-----------
Merge pull request #37 from Sp1l/master
Fix net/x11vnc LibreSSL 2.3.0 build NO_SHA0
#4
Updated by Kris Moore over 4 years ago
Commit: 3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
https://github.com/pcbsd/freebsd-ports/commit/3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
Author: truckman <truckman@FreeBSD.org>
Date: 2016-02-03 (Wed, 03 Feb 2016)
Log Message:
-----------
Upgrade net/nmsg to 0.11.0:
nmsg (0.11.0)
[ Henry Stern ]- Add an interval randomization option that randomizes the initial offset
within the selected time interval. This functionality is exposed via the
libnmsg nmsg_io_set_interval_randomized() function and the nmsgtool -R /
--randomize command-line option (#27, #33).
- Make nmsgtool -k / --kicker work when combined with -c or -t, when
producing output in JSON format (#25, #38).
- Add nmsg_message_get_num_field_values(),
nmsg_message_get_num_field_values_by_idx() functions (#5, #40).
- Remove the unused enum nmsg_modtype from the internal libnmsg API (#30).
- Add a message filtering capability to the libnmsg I/O loop, including
external filter module plugin and nmsgtool support (#41, #43, #44).
- Add yajl/ prefix to #include's of yajl headers (#37)
Pet portlint
Sponsored by: Farsight Security, Inc.
#5
Updated by Kris Moore over 4 years ago
Commit: 3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
https://github.com/pcbsd/freebsd-ports/commit/3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
Author: truckman <truckman@FreeBSD.org>
Date: 2016-02-03 (Wed, 03 Feb 2016)
Log Message:
-----------
Upgrade net/nmsg to 0.11.0:
nmsg (0.11.0)
[ Henry Stern ]- Add an interval randomization option that randomizes the initial offset
within the selected time interval. This functionality is exposed via the
libnmsg nmsg_io_set_interval_randomized() function and the nmsgtool -R /
--randomize command-line option (#27, #33).
- Make nmsgtool -k / --kicker work when combined with -c or -t, when
producing output in JSON format (#25, #38).
- Add nmsg_message_get_num_field_values(),
nmsg_message_get_num_field_values_by_idx() functions (#5, #40).
- Remove the unused enum nmsg_modtype from the internal libnmsg API (#30).
- Add a message filtering capability to the libnmsg I/O loop, including
external filter module plugin and nmsgtool support (#41, #43, #44).
- Add yajl/ prefix to #include's of yajl headers (#37)
Pet portlint
Sponsored by: Farsight Security, Inc.