Hi,
I haven't followed all the details in this discussion, but it seems to me
that it all breaks down to:
- NFS on ZFS is slow due to NFS being very conservative when sending
ACK to clients only after writes have definitely committed to disk.
- Therefore, the problem is not that much ZFS
Nope, wrong conclusion again.
This large performance degradation has nothing whatsoever to
do with ZFS. I have not seen data that would show a possible
slowness on the part of ZFS vfs AnyFS on the
backend; there may well be and that would be an entirely
diffenrent discussion to the large
On Thu, Nov 23, 2006 at 12:09:09PM +0100, Pawel Jakub Dawidek wrote:
On Wed, Nov 22, 2006 at 03:38:05AM -0800, Peter Eriksson wrote:
There is nothing in the ZFS FAQ about this. I also fail to see how FMA
could make any difference since it seems that ZFS is deadlocking somewhere
in the
Hi Roch,
thanks, now I better understand the issue :).
Nope. NFS is slow for single threaded tar extract. The
conservative approach of NFS is needed with the NFS protocol
in order to ensure client's side data integrity. Nothing ZFS
related.
...
NFS is plenty fast in a throughput
Roch - PAE wrote:
Not possible. Nothing related to ZFS here and if NFS had
ways to make this better i think it would have been done in v4.
If we extended the protocol to allow for exclusive mounts
(single client access) then, I would think that the extra
knowledge could be used to gain
One of the things that I have taken for granted was that I can *always* boot
a Sun server with a CDROM or DVD or jumpstart boot net -srv and get to a
prompt. That allows me to fsck filesystems and ufsdump to tape if needed.
In fact, I have generally done obscure things like fully install a
We have had file delegation on by default in NFSv4 since Solaris 10 FCS,
putback in July 2004.
We're currently working on also providing directory delegations - client
caching of directory contents - as part of the upcoming NFSv4.1.
cheers,
calum.
Darren J Moffat wrote:
Roch - PAE wrote:
On 11/23/06, James Dickens [EMAIL PROTECTED] wrote:
On 11/23/06, Dennis Clarke [EMAIL PROTECTED] wrote:
this is off list on purpose ?
run zpool import, it will search all attached storage and give you a
list
of availible pools. then run zpool import poolname or add a -f if
you
On 11/23/06, James Dickens [EMAIL PROTECTED] wrote:
On 11/23/06, Dennis Clarke [EMAIL PROTECTED] wrote:
assume worst case
someone walks up to you and drops an array on you.
They say its ZFS an' I need that der stuff 'k? all while chewing on a
cig.
what do you do ? besides run ?
Bill,
I did the same test on the Thumper I'm working on with the NFS vols
converted from ZFS stripes to SVM stripes. In both cases same
number/type of disks in the stripe. In my very simple test ,time for
file in frame*; do cp /inq/$file /outq/$file; done, UFS did
approximately 64 MB/s,
Calum Mackay wrote:
We have had file delegation on by default in NFSv4 since Solaris 10 FCS,
putback in July 2004.
The delegation of a file gives the client certain guarantees about how
that file may be accessed by other clients (regardless of NFS version)
or processes local to the NFS
Dennis,
i'm not sure if this will help you, but i had something similar happen and was
able to get my zpool back.
i decided to install (not upgrade) Nevada snv-51 which was the current build at
the time. I had (and thankfully still have) a zpool which i'd created under
snv-37 on a separite
Excuse me if I'm mistaken, but I think the question is on the lines of how to
access and more importantly - Backup zfs pools/filesystems present on a system
by just booting from a CD/DVD.
I think the answer would be on the lines of (forced?) importing of zfs pools
present on the system and
13 matches
Mail list logo
