bugs to track
these problems as well, with little activity from other posters:
* https://www.illumos.org/issues/841
* https://www.illumos.org/issues/956
The current version of my software watchdog which saves some
trouble for my assistant by catching near-freeze conditions,
is here:
* http://thum
> 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 ma
> 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 [filesystem]@
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 fil
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
ol will come back online sometime...
The current version of my software watchdog which saves some
trouble for my assistant by catching near-freeze conditions,
is here:
* http://thump
Just want to share with you. We have found and been suffering from some weird
issues because of
it. It is better to connect them directly to the sata ports on the mainboard.
Thanks.
Fred
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://
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 talki
2011-06-10 18:00, Steve Gonczi пишет:
Hi Jim,
I wonder what OS version you are running?
There was a problem similar to what you are describing in earlier versions
in the 13x kernel series.
Should not be present in the 14x kernels.
It is OpenIndiana oi_148a, and unlike many other details -
t
> 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
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 wel
On Fri, Jun 10, 2011 at 8:59 AM, Jim Klimov 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 been using T
On Jun 10, 2011 11:52 AM, "Jim Klimov" wrote:
>
> 2011-06-10 18:00, Steve Gonczi пишет:
>>
>> Hi Jim,
>>
>> I wonder what OS version you are running?
>>
>> There was a problem similar to what you are describing in earlier
versions
>> in the 13x kernel series.
>>
>> Should not be present in the 14
> 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 case
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 (F
15 matches
Mail list logo