On Jun 11, 2011, at 5:46 AM, Edward Ned Harvey wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jim Klimov
See FEC suggestion from another poster ;)
Well, of course, all storage mediums have built-in hardware FEC. At least
disk
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jim Klimov
See FEC suggestion from another poster ;)
Well, of course, all storage mediums have built-in hardware FEC. At least disk
tape for sure. But naturally you can't always trust it
On Jun 11, 2011, at 08:46, Edward Ned Harvey wrote:
If you simply want to layer on some more FEC, there must be some standard
generic FEC utilities out there, right?
zfs send | fec /dev/...
Of course this will inflate the size of the data stream somewhat, but
improves the
From: David Magda [mailto:dma...@ee.ryerson.ca]
Sent: Saturday, June 11, 2011 9:04 AM
If one is saving streams to a disk, it pay be worth creating parity files
for them
(especially if the destination file system is not ZFS):
Parity is just a really simple form of error detection. It's not
On Jun 11, 2011, at 09:20, Edward Ned Harvey wrote:
Parity is just a really simple form of error detection. It's not very
useful for error correction. If you look into error correction codes,
you'll see there are many other codes which would be more useful for the
purposes of zfs send
2011-06-11 17:20, Edward Ned Harvey пишет:
From: David Magda [mailto:dma...@ee.ryerson.ca]
Sent: Saturday, June 11, 2011 9:04 AM
If one is saving streams to a disk, it pay be worth creating parity files
for them
(especially if the destination file system is not ZFS):
Parity is just a really
From: David Magda [mailto:dma...@ee.ryerson.ca]
Sent: Saturday, June 11, 2011 9:38 AM
These parity files use a forward error correction-style system that can be
used to perform data verification, and allow recovery when data is lost or
corrupted.
http://en.wikipedia.org/wiki/Parchive
On Jun 11, 2011, at 10:37, Edward Ned Harvey wrote:
From: David Magda [mailto:dma...@ee.ryerson.ca]
Sent: Saturday, June 11, 2011 9:38 AM
These parity files use a forward error correction-style system that can be
used to perform data verification, and allow recovery when data is lost or
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jim Klimov
Besides, the format
is not public and subject to change, I think. So future compatibility
is not guaranteed.
That is not correct.
Years ago, there was a comment in the man
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jonathan Walker
New to ZFS, I made a critical error when migrating data and
configuring zpools according to needs - I stored a snapshot stream to
a file using zfs send -R
On 06/10/11 12:47, Edward Ned Harvey wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jonathan Walker
New to ZFS, I made a critical error when migrating data and
configuring zpools according to needs - I stored a snapshot stream to
a
2011-06-10 15:58, Darren J Moffat пишет:
As I pointed out last time this came up the NDMP service on Solaris 11
Express and on the Oracle ZFS Storage Appliance uses the 'zfs send'
stream as what is to be stored on the tape.
This discussion turns interesting ;)
Just curious: how do these
On Fri, June 10, 2011 07:47, Edward Ned Harvey wrote:
#1 A single bit error causes checksum mismatch and then the whole data
stream is not receivable.
I wonder if it would be worth adding a (toggleable?) forward error
correction (FEC) [1] scheme to the 'zfs send' stream.
Even if we're
If it is true that unlike ZFS itself, the replication
stream format has
no redundancy (even of ECC/CRC sort), how can it be
used for
long-term retention on tape?
It can't. I don't think it has been documented anywhere, but I believe that it
has been well understood that if you don't trust
2011-06-10 20:58, Marty Scholes пишет:
If it is true that unlike ZFS itself, the replication
stream format has
no redundancy (even of ECC/CRC sort), how can it be
used for
long-term retention on tape?
It can't. I don't think it has been documented anywhere, but I believe that it
has been well
On Fri, Jun 10, 2011 at 8:59 AM, Jim Klimov jimkli...@cos.ru wrote:
Is such tape storage only intended for reliable media such as
another ZFS or triple-redundancy tape archive with fancy robotics?
How would it cope with BER in transfers to/from such media?
Large and small businesses have
I stored a snapshot stream to a file
The tragic irony here is that the file was stored on a non-zfs filesystem. You
had had undetected bitrot which unknowingly corrupted the stream. Other files
also might have been silently corrupted as well.
You may have just made one of the strongest
On Jun 10, 2011, at 8:59 AM, David Magda wrote:
On Fri, June 10, 2011 07:47, Edward Ned Harvey wrote:
#1 A single bit error causes checksum mismatch and then the whole data
stream is not receivable.
I wonder if it would be worth adding a (toggleable?) forward error
correction (FEC) [1]
Hey all,
New to ZFS, I made a critical error when migrating data and
configuring zpools according to needs - I stored a snapshot stream to
a file using zfs send -R [filesystem]@[snapshot] [stream_file].
When I attempted to receive the stream onto to the newly configured
pool, I ended up with a
On Thu, Jun 9, 2011 at 8:59 AM, Jonathan Walker kall...@gmail.com wrote:
New to ZFS, I made a critical error when migrating data and
configuring zpools according to needs - I stored a snapshot stream to
a file using zfs send -R [filesystem]@[snapshot] [stream_file].
Why is this a critical
2011-06-09 18:52, Paul Kraus пишет:
On Thu, Jun 9, 2011 at 8:59 AM, Jonathan Walkerkall...@gmail.com wrote:
New to ZFS, I made a critical error when migrating data and
configuring zpools according to needs - I stored a snapshot stream to
a file using zfs send -R
On Thu, Jun 9, 2011 at 1:17 PM, Jim Klimov jimkli...@cos.ru wrote:
2011-06-09 18:52, Paul Kraus пишет:
On Thu, Jun 9, 2011 at 8:59 AM, Jonathan Walkerkall...@gmail.com wrote:
New to ZFS, I made a critical error when migrating data and
configuring zpools according to needs - I stored a
2011-06-09 21:33, Paul Kraus пишет:
If some bits in the saved file flipped,
Then you have a bigger problem, namely that the file was corrupted.
That is not a limitation of the zfs send format. If the stream gets
corrupted via network transmission you have the same problem.
No it is not quite
New to ZFS, I made a critical error when migrating data and
configuring zpools according to needs - I stored a snapshot stream to
a file using zfs send -R [filesystem]@[snapshot] [stream_file].
Why is this a critical error, I thought you were supposed to be
able to save the output from zfs
On 09/06/11 1:33 PM, Paul Kraus wrote:
On Thu, Jun 9, 2011 at 1:17 PM, Jim Klimov jimkli...@cos.ru wrote:
2011-06-09 18:52, Paul Kraus пишет:
On Thu, Jun 9, 2011 at 8:59 AM, Jonathan Walkerkall...@gmail.com wrote:
New to ZFS, I made a critical error when migrating data and
configuring
25 matches
Mail list logo
