Project

General

Profile

Feature #37

import disk from freens 7.2

Added by petrone - about 9 years ago. Updated over 1 year ago.

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

Revision b70a7b99 (diff)
Added by Oliver Pinter over 4 years ago

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)

Revision b70a7b99 (diff)
Added by Oliver Pinter over 4 years ago

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)

Revision 6b18646c (diff)
Added by Alexander Motin over 3 years ago

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

Revision 6b18646c (diff)
Added by Alexander Motin over 3 years ago

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

Revision 4d9e23ad (diff)
Added by Alexander Motin over 3 years ago

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

Revision 4d9e23ad (diff)
Added by Alexander Motin over 3 years ago

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

Revision 2925c1f3 (diff)
Added by Alexander Motin over 3 years ago

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

Revision 2925c1f3 (diff)
Added by Alexander Motin over 3 years ago

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 about 9 years ago

  • Status changed from Unscreened to Closed

Thank you.

For the moment imports are not possible, we are working on the solution, which is covered by ticket #6. I'm closing this one as a duplicate and will subscribe you to ticket #6.

#2 Updated by Jordan Hubbard over 4 years ago

  • Target version deleted (2)

#3 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

Commit: eb419ad5c7a01c6a42ad5b2226ed2ce7fafd53f4
https://github.com/pcbsd/freebsd-ports/commit/eb419ad5c7a01c6a42ad5b2226ed2ce7fafd53f4
Author: Bernard Spil <>
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 Avatar?id=14398&size=24x24 Updated by Kris Moore almost 4 years ago

Commit: 3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
https://github.com/pcbsd/freebsd-ports/commit/3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
Author: truckman <>
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).
  • Add documention for nmsgtool -j / --readjson and -J / --write-json
    command-line options (#26, #28).
  • Add PKG_CHECK_MODULES dependency on yajl >= 2.1.0 (#29, #31).
  • Make nmsgtool -k / --kicker work when combined with -c or -t, when
    producing output in JSON format (#25, #38).
  • Fix compiler warning [-Wtautological-compare] in
    _nmsg_msgmod_json_to_payload_load() (#36, #39).
  • Add nmsg_message_get_num_field_values(),
    nmsg_message_get_num_field_values_by_idx() functions (#5, #40).
[ Robert Edmonds ]
  • Remove the unused enum nmsg_modtype from the internal libnmsg API (#30).
  • Header file cleanups (#14, #34).
  • Rewrite nmsg_res_lookup() to use a switch, which eliminates a Clang
    warning (#14, #35).
  • Add a message filtering capability to the libnmsg I/O loop, including
    external filter module plugin and nmsgtool support (#41, #43, #44).
[ Mike Schiffman ]
  • Add yajl/ prefix to #include's of yajl headers (#37)

Pet portlint

Sponsored by: Farsight Security, Inc.

#5 Avatar?id=14398&size=24x24 Updated by Kris Moore almost 4 years ago

Commit: 3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
https://github.com/pcbsd/freebsd-ports/commit/3bd19b1310a12a6bae51db5d7ca2d6a6ed1aed17
Author: truckman <>
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).
  • Add documention for nmsgtool -j / --readjson and -J / --write-json
    command-line options (#26, #28).
  • Add PKG_CHECK_MODULES dependency on yajl >= 2.1.0 (#29, #31).
  • Make nmsgtool -k / --kicker work when combined with -c or -t, when
    producing output in JSON format (#25, #38).
  • Fix compiler warning [-Wtautological-compare] in
    _nmsg_msgmod_json_to_payload_load() (#36, #39).
  • Add nmsg_message_get_num_field_values(),
    nmsg_message_get_num_field_values_by_idx() functions (#5, #40).
[ Robert Edmonds ]
  • Remove the unused enum nmsg_modtype from the internal libnmsg API (#30).
  • Header file cleanups (#14, #34).
  • Rewrite nmsg_res_lookup() to use a switch, which eliminates a Clang
    warning (#14, #35).
  • Add a message filtering capability to the libnmsg I/O loop, including
    external filter module plugin and nmsgtool support (#41, #43, #44).
[ Mike Schiffman ]
  • Add yajl/ prefix to #include's of yajl headers (#37)

Pet portlint

Sponsored by: Farsight Security, Inc.

Also available in: Atom PDF