Two conflicting situations: 

1) INFN-T1 has been running reliably before the upgrade to StoRM 1.7 and has been very unstable after (see section INFN-T1 below)
2) QMUL has been very unstable before the upgrade to 1.7 and is very reliable now (see section QMUL) below

Both statements are true and measurable (GGUS tickets, ATLAS activity monitoring, …) 

**** INFN-T1 ****

From CNAF: 
"""StoRM developers are tracking all issues reported in GGUS tickets (about last major release 1.7.0) and fixing it, temporary with patches and definitively in the next version planned for September"""

This is the list of GGUS tickets somehow related to the INFN-T1 StoRM upgrade. 

73866		atlas	INFN-T1	  top priority	NGI_IT	verified	  2011-08-27	   2011-08-29 07:09	  	 INFN-T1 SRM down
73452		atlas	INFN-T1	  top priority	NGI_IT	verified	  2011-08-13	   2011-08-14 20:27	  	 failed to contact on remote SRM at INFN-T1
73236		atlas	INFN-T1	  top priority	NGI_IT	verified	  2011-08-06	   2011-08-06 22:30	  	 put gridftp_copy_wait: Connection timed out at INF...
73054		atlas	INFN-T1	  top priority	NGI_IT	verified	  2011-07-29	   2011-07-31 17:22	  	 INFN-T1: srm is down

Notice that in the last year, INFN-T1 received 9 ALARM tickets, out of which 1 network related, 1 related to a tape intervention and 7 related to the storage. Out of 7 alarm tickets in one year, 4 of them have been issued in the last month, after  July 29 which is right after the StoRM upgrade. Besides, one has to add the following, which have been issued as TEAM tickets and are related to storage problems. 

73789		atlas	INFN-T1	  top priority	NGI_IT	solved	  2011-08-24	   2011-08-24 23:55	  	 Burst of errors in T0 to INFN-T1_DATADISK real dat...
73670		atlas	INFN-T1	  urgent	NGI_IT	verified	  2011-08-20	   2011-08-27 16:17	  	 INFN-T1 / INFN-T1-SIMUL: still see job failures wi...
73652		atlas	INFN-T1	  urgent	NGI_IT	verified	  2011-08-19	   2011-08-19 19:41	  	 INFN-T1 / INFN-T1-SIMUL: job failures with stage-o...
73619		atlas	INFN-T1	  less urgent	NGI_IT	solved	  2011-08-18	   2011-08-24 13:11	  	 INFN-T1_DATADISK: SOURCE errors, failed to contact...
73490		atlas	INFN-T1	  less urgent	NGI_IT	verified	  2011-08-15	   2011-08-19 01:46	  	 Failed jobs with forced timeout SRMV2STAGER error ...
73456		atlas	INFN-T1	  urgent	NGI_IT	verified	  2011-08-14	   2011-08-15 18:49	  	 INFN-T1: srm was down
73423		atlas	INFN-T1	  top priority	NGI_IT	solved	  2011-08-12	   2011-08-13 13:08	  	 thousands of failed transfers at INFN-T1_DATADISK...
73422		atlas	INFN-T1	  urgent	NGI_IT	verified	  2011-08-12	   2011-08-13 02:12	  	 INFN-T1_DATADISK many SRM errors
73348		atlas	INFN-T1	  urgent	NGI_IT	verified	  2011-08-09	   2011-08-12 08:35	  	 INFN-T1_SCRATCHDISK FTS State errors
73258		atlas	INFN-T1	  very urgent	NGI_IT	verified	  2011-08-08	   2011-08-14 16:48	  	 T0 export to INFN failing three attempts
73242		atlas	INFN-T1	  very urgent	NGI_IT	solved	  2011-08-07	   2011-08-08 13:46	  	 All the panda jobs failed on INFN-T1 with lcg_gt: ...

**** QMUL ****

From Christopher Walker (QMUL) 

Background
----------
Storm 1.6.2 regularly crashed for us (GGUS 71437 - filed June 6th) -
sometimes several times a day (I ended up running a cron job every
minute to restart the frontend if it had failed). With the ability of
pilots to run several jobs, if our SE fell over it was easy to fail
several thousand analysis jobs in the 5 minutes  it took to restart the
frontend[1].

This problem was less noticeable with production jobs - where a 5 minute
gap with no SE didn't cause as many problems.

The other problem we had was GGUS 70066  (filed in April) - for each
lcg-gt call that ATLAS made to our SE, there were about 200 protocols
requested. This resulted in log files of over 100GB/day - which filled
up our SE's log partition - also causing downtime ("fixed" by moving the
logs to our Lustre filesystem).

This unreliability affected analysis jobs disproportionately (including
those of local users who wanted to get work done on the grid). When
Manchester was set as a multicloud site for MC, QMUL was not - and
unreliability was given as the reason - which I took as a request to do
something about it.

The upgrade
-----------
This is where you noticed particular problems, and I'm sure I could have
handled it better by declaring a week or two of at risk (downtime
wouldn't have helped as the problem was load related).

I installed the new version of StoRM on a new machine - and turned the
old one off, leaving a fallback (which I had to use a couple of times).

After some initial teething troubles (and at least one backout), which
I'd not discovered when I installed our test SE, se04, I eventually got
a working StoRM 1.7.0. and went to bed happy - only to find it crashed
in the morning. I deployed the restart script and sent the developers
some core dumps. This crash was known about - and supposedly fixed in
1.7.1 - which I installed and promptly sent them some different  core
dumps, lather rinse, repeat, (I'm now on storm-frontend version 1.7.1-5
). I also fixed the space reporting issues (and we now no longer need to
run a du on our entire storage every time we need to know how much you
are using).  I now have an SE that has been up since I installed it
(except for a kernel upgrade causing a downgrade of the 10Gbit network
card driver and ensuing lockup).

Current State
-------------
I'm a lot happier, and whilst there are still some open tickets against
StoRM, we are a lot more reliable, and we were 7th in the list of
analysis sites yesterday [2] (beating CERN who were presumably in
downtime).