2012-01-11 1:26, Jim Klimov пишет:
To follow on the subject of VDEV caching, even if
only of metadata, in oi_148a, I have found the
disabling entry in /etc/system of the LiveUSB:
set zfs:zfs_vdev_cache_size=0
Now that I have the cache turned on and my scrub
continues, cache efficiency so far
On 1/10/2012 9:44 PM, Ray Van Dolson wrote:
On Tue, Jan 10, 2012 at 06:23:50PM -0800, Hung-Sheng Tsao (laoTsao) wrote:
how is the ram size what is the zpool setup and what is your hba and
hdd size and type
Hmm, actually this system has only 6GB of memory. For some reason I
though it had
I think about adding the following RFE to illumos bugtracker:
add an option/attribute to import ZFS pool without
automounting/sharing ZFS datasets
I wonder if something like this (like a tricky workaround)
is already in place?
--
My rationale is the currently ongoing repairs and inspections
On 01/11/12 11:48, Jim Klimov wrote:
I think about adding the following RFE to illumos bugtracker:
add an option/attribute to import ZFS pool without
automounting/sharing ZFS datasets
I wonder if something like this (like a tricky workaround)
is already in place?
-N
2012-01-11 16:00, Darren J Moffat пишет:
On 01/11/12 11:48, Jim Klimov wrote:
I think about adding the following RFE to illumos bugtracker:
add an option/attribute to import ZFS pool without
automounting/sharing ZFS datasets
I wonder if something like this (like a tricky workaround)
is
Hello all, I found this dialog on the zfs-de...@zfsonlinux.org list,
and I'd like someone to confirm-or-reject the discussed statement.
Paraphrasing in my words and understanding:
Labels, including Uberblock rings, are fixed 256KB in size each,
of which 128KB is the UB ring. Normally there
Hello all, I have a new crazy idea of the day ;)
Some years ago there was an idea proposed in one of ZFS
developers' blogs (maybe Jeff's? sorry, can't find and
link it now) that went somewhat along these lines:
Modern disks have some ECC/CRC codes for each sector,
and uses them to test
On Wed, Jan 11, 2012 at 9:16 AM, Jim Klimov jimkli...@cos.ru wrote:
I've recently had a sort of an opposite thought: yes,
ZFS redundancy is good - but also expensive in terms
of raw disk space. This is especially bad for hardware
space-constrained systems like laptops and home-NASes,
where
2012-01-11 20:40, Nico Williams пишет:
On Wed, Jan 11, 2012 at 9:16 AM, Jim Klimovjimkli...@cos.ru wrote:
I've recently had a sort of an opposite thought: yes,
ZFS redundancy is good - but also expensive in terms
of raw disk space. This is especially bad for hardware
space-constrained systems
I'm reading the ZFS On-disk Format PDF (dated 2006 -
are there newer releases?), and have some questions
regarding whether it is outdated:
1) On page 16 it has the following phrase (which I think
is in general invalid):
The value stored in offset is the offset in terms of
sectors (512 byte
On Jan 11, 2012, at 5:01 AM, Jim Klimov wrote:
Hello all, I found this dialog on the zfs-de...@zfsonlinux.org list,
and I'd like someone to confirm-or-reject the discussed statement.
Paraphrasing in my words and understanding:
Labels, including Uberblock rings, are fixed 256KB in size each,
On Sun, Jan 08, 2012 at 06:25:05PM -0800, Richard Elling wrote:
ZIL makes zero impact on resilver. I'll have to check to see if L2ARC is
still used, but
due to the nature of the ARC design, read-once workloads like backup or
resilver do
not tend to negatively impact frequently used data.
On Thu, Jan 12, 2012 at 03:05:32PM +1100, Daniel Carosone wrote:
On Sun, Jan 08, 2012 at 06:25:05PM -0800, Richard Elling wrote:
ZIL makes zero impact on resilver. I'll have to check to see if L2ARC is
still used, but
due to the nature of the ARC design, read-once workloads like backup or
13 matches
Mail list logo
