Well I do have a plan.
Thanks to the portability of ZFS boot disks, I'll make two new OS disks on
another machine with the next Nexcenta release, export the data pool and swap
in the new ones.
That way, I can at least manage a zfs scrub without killing the performance and
get the Intel SSD's
Hi,
this has already been the source of a lot of interesting discussions, so
far I haven't found the ultimate conclusion. From some discussion on
this list in February, I learned that an antry in ZFS' deduplication
table takes (in practice) half a KiB of memory. At the moment my data
looks like
Hello,
we are currently extensivly testing the DDRX1 drive for ZIL and we are going
through all the corner cases.
The headline above all our tests is do we still need to mirror ZIL with all
current fixes in ZFS (zfs can recover zil failure, as long as you don't export
the pool, with latest
This is a consequence of the design for performance of the ZIL code.
Intent log blocks are dynamically allocated and chained together.
When reading the intent log we read each block and checksum it
with the embedded checksum within the same block. If we can't read
a block due to an IO error then
On 08/23/10 13:12, Markus Keil wrote:
Does that mean that when the begin of the intent log chain gets corrupted, all
other intent log data after the corruption area is lost, because the checksum of
the first corrupted block doesn't match?Â
- Yes, but you wouldn't want to replay the
