Joe N. Wallace wrote:

huh, I always like it when someone here comes with some facts about what EMC
can do better on their documentation.

I just hope EMC is watching here and takes the point.

Support material would be so much better from EMC if they just would let
some tech people proof read before publishing.

2009/7/22 Yaron Zabary <yaron AT aristo.tau.ac DOT il>

Hello all,

  Recently I made a change to my setup which solved me a couple of problems
and I thought some of you might find this information useful.

  My Networker server is a Sun T1000 with an internal 160Gb SATA disk. The
server is connected to an EMC AX150 which is used for AFTD. Obviously, the
AX150 does heavy I/O during backups and staging (over 50Mb/s). In the
previous setup, /nsr was a ZFS filesystem on the AX150 (actually a link). In
the new setup /nsr was moved to the internal SATA disk. Due to disk space
limit on the internal disk, the indexes (/nsr/index) are still on the AX150.
This change solved several problems we had, such as RPC timeouts during
backups, non-responsive nsrd (nsrwatch not updating for minutes), slow
mminfo and very slow bootstrap backup.

 It seems that although one might be tempted to place /nsr on a large RAID
array, it is important that it will have good performance which your typical
AFTD array will probably be unable to deliver while busy.

 On a side note, while writing this, I went to the useless Performance
Tuning Guide to see if the best location for /nsr was mentioned (and just to
see if things have improved since I last went over it), but couldn't find
any discussion about it. I did find some improvements, such as the
statement: "For example, there is no system which can fully sustain 8 by
LTO3 (considered normal practice in many environments)."). It is still a bad
guide which still considers FDDI as a network upgrade (on page 32). This
looks even worse, because on page 31 they discuss contemporary hardware such
as "a mid-size system with 4 by 1-Gbit, NICs". As always, it seems that
nobody didn't bother to read it end to end. I am quite sure that if any EMC
engineer will spend just two hours to proof read it, many of its problems
can be eliminated. In its current state, this guide simply demonstrates
EMC's disrespect to their loyal paying customers.

--

-- Yaron.

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

--

-- Yaron.

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER