Dear All,
I have been advised to enquire here on zfs-discuss with the
ZFS problem described below, following discussion on Usenet NG
comp.unix.solaris. The full thread should be available here
https://groups.google.com/forum/#!topic/comp.unix.solaris/uEQzz1t-G1s
Many thanks
Tom Crane
Sao Kiselkov writes:
On 06/12/2012 05:37 PM, Roch Bourbonnais wrote:
So the xcall are necessary part of memory reclaiming, when one needs to
tear down the TLB entry mapping the physical memory (which can from here
on be repurposed).
So the xcall are just part of this. Should
Shot in the dark here:
What are you using for the sharenfs value on the ZFS filesystem? Something
like rw=.mydomain.lan ?
They are IP blocks or hosts specified as FQDNs, eg.,
pptank/home/tcrane sharenfs
rw=@192.168.101/24,rw=serverX.xx.rhul.ac.uk:serverY.xx.rhul.ac.uk
I've had
I noticed recently that the SSDs hosting the ZIL for my pool had a large
number in the SMART attribute for total LBAs written (with some
calculation, it seems to be the total amount of data written to the pool so
far), did some testing, and found that the ZIL is being used quite heavily
(matching
On Wed, Jun 13, 2012 at 05:56:56PM -0500, Timothy Coalson wrote:
client: ubuntu 11.10
/etc/fstab entry: server:/mainpool/storage /mnt/myelin nfs
bg,retry=5,soft,proto=tcp,intr,nfsvers=3,noatime,nodiratime,async 0
0
nfsvers=3
NAME PROPERTY VALUE SOURCE
On Tue, Jun 12, 2012 at 03:46:00PM +1000, Scott Aitken wrote:
Hi all,
Hi Scott. :-)
I have a 5 drive RAIDZ volume with data that I'd like to recover.
Yeah, still..
I tried using Jeff Bonwick's labelfix binary to create new labels but it
carps because the txg is not zero.
Can you provide
Interesting...from what I had read about NFSv3 asynchronous writes,
especially bits about does not require the server to commit to stable
storage, led me to expect different behavior. The performance impact
on large writes (which we do a lot of) wasn't severe, so sync=disabled
is probably not
