|
Home > Archive > Data Storage > September 2004 > emc v/s. netapp
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| vidyesh 2004-08-27, 5:46 pm |
| the emc figures on spec.org for their ns700 system at specsfs97_R1.v3
give a fig of 36 k iops per sec at abt 7.1 ms. this is however only
with striping and no raid or snapshots with only 350 gb of data on 136
disks of 144 gb.
this does not seem like a real life situation in any way.
in real life one would have raid 5 , a lot of snapshots and at least
abt 15 tb of data on 136 disks.
in such a scenario wht would be the degradation in the performance
figures.
i mean in percentage terms could someone give me an estimate as to how
much toll say raid 5 , snapshots and a large amt of data would take on
the iops of the system
also the ip4700 the erstwhile version of the system was known to go
into fsck when there was an abrupt power off or a ungraceful shutdown
of the system. the fsck time was proportional to ur data size and cud
take upto days . your data was unavailabel for tht time
does this bug still continue in the emc ns 700s
i guess it does becaue the file system still remains the same which is
the uxfs.
can anyone with experience with the ns 700 throw some light.
thanks and regards
videysh
| |
|
| On 27 Aug 2004 07:16:13 -0700, in comp.arch.storage you wrote:
>the emc figures on spec.org for their ns700 system at specsfs97_R1.v3
>give a fig of 36 k iops per sec at abt 7.1 ms. this is however only
>with striping and no raid or snapshots with only 350 gb of data on 136
>disks of 144 gb.
>
>this does not seem like a real life situation in any way.
>in real life one would have raid 5 , a lot of snapshots and at least
>abt 15 tb of data on 136 disks.
Sure, you have a point, but you'd expect any vendor to try to
configure to maximise performance.
It's not that unusual for EMC to spread the metas over as many
spindles as possible - hence the 126 spindles. They'd do this on a
real NS700 if you had that many disks. There's a lot of design work
that goes into the implementation.
>in such a scenario wht would be the degradation in the performance
>figures.
>i mean in percentage terms could someone give me an estimate as to how
>much toll say raid 5 , snapshots and a large amt of data would take on
>the iops of the system
Impossible to guess at. If you're interested in buying one, tell your
EMC rep that you have a particular performance requirement (you'll
have to specify what this is). They'll go away and get the
engineering folks to check if it's possible. If it's not they'll tell
you - engineering won't allow them to ship you the box unless they
agree on the performance requirements.
>also the ip4700 the erstwhile version of the system was known to go
>into fsck when there was an abrupt power off or a ungraceful shutdown
>of the system. the fsck time was proportional to ur data size and cud
>take upto days . your data was unavailabel for tht time
>
>does this bug still continue in the emc ns 700s
>
>i guess it does becaue the file system still remains the same which is
>the uxfs.
The IP4700 wasn't a great product and had quite a few shortcomings,
which is ultimately why EMC have dropped it and produced the
NS600/NS700 produts which use (Celerra) DART instead.
I'm not convinced that the IP4700 used the same uxfs file system as
the NS700/Celerra. The reason being that Celerra was developed solely
by EMC, while the IP4700 was done by Data General (but brought to
market by EMC). At the time the Celerra guys and the IP4700 guys
didn't really work together, so I'd be surprised if they used the same
file system.
I don't have any documentation to hand to check this.
In my experience the Celerra was pretty good at coming back up quickly
after an abnormal shutdown - YMMV.
HVB.
| |
| spiegela@gmail.com 2004-09-26, 5:47 pm |
| First off, I couldn't say how many what kind of throughput and response
time you'd get with RAID 5 as compared with striping, but there are
even more factors that will come into play. These include raid group
size, IO size, randomness of reads, etc. If you bring your specific
requirements to an EMC rep, they should be able to enlist the help of a
performance expert who can show you a range of performance available
with the different configuration options.
Adding checkpoints doesn't seem like very much of a performance factor.
What you're really looking at is adding a pointer, and writing a new
block rather than replacing one. The real affect that it has is
consuming memory on the datamover, as those pointers are kept in memory
for quick access to them. Memory, though, isn't typically in
contention on the datamover. Again, more details can probably be
gleaned from an EMC performance expert. They have graphs on all this
stuff...
As to a fsck'ing: uxfs is a journaling filesystem now, and almost all
filesystem corruption-- should it occur-- shoule be fixable without a
fsck. Moreover, the Clariion within the NS700 has enough battery power
to destage writes to disk from cache before the system powers off,
thereby preventing any corruption. Also, though I've never needed to
fsck, I really couldn't imagine it taking several *days* for any size
of filesystem.
HTH
Aaron
| |
| Jesper Monsted 2004-09-26, 5:47 pm |
| "spiegela@gmail.com" <spiegela@gmail.com> wrote in
news:1096169249.025496.264830@h37g2000oda.googlegroups.com:
> As to a fsck'ing: uxfs is a journaling filesystem now, and almost all
> filesystem corruption-- should it occur-- shoule be fixable without a
> fsck. Moreover, the Clariion within the NS700 has enough battery power
> to destage writes to disk from cache before the system powers off,
> thereby preventing any corruption. Also, though I've never needed to
> fsck, I really couldn't imagine it taking several *days* for any size
> of filesystem.
EMC asked me for 16 hours of downtime to run a full fsck of our (at that
time) 1.3 TB CNS-14. It's at 2.5 now and growing...
--
/Jesper Monsted
| |
|
| "Jesper Monsted" <newsspam@rootweiler.dk.invalid> wrote in message
news:Xns95708269B4E06newsspamrootweilerd
k@62.243.74.163...
> "spiegela@gmail.com" <spiegela@gmail.com> wrote in
> news:1096169249.025496.264830@h37g2000oda.googlegroups.com:
>
>
> EMC asked me for 16 hours of downtime to run a full fsck of our (at that
> time) 1.3 TB CNS-14. It's at 2.5 now and growing...
fsck is a file system problem and not the EMC. We are testing a CX500
(in the hopes of getting a CX700) using a 2GB Dual Opteron and with one
FC tray were are getting decent numbers against a lot of clients. We are
getting 4 ATA trays soon and will retest with even more clients. So far
performance improves with more clients. Kinda counter-intuitive, eh?
--
Wolf
----------------------------------------------------------------
Please post all reponses to UseNet. All email cheerfully and automagically
routed to Dave Null
| |
| Jesper Monsted 2004-09-26, 8:47 pm |
| "Wolf" <wolfdotcom@hotmail.com> wrote in
news:wcE5d.1279$zc1.205@newssvr12.news.prodigy.com:
> fsck is a file system problem and not the EMC. We are testing a CX500
> (in the hopes of getting a CX700) using a 2GB Dual Opteron and with
> one FC tray were are getting decent numbers against a lot of clients.
> We are getting 4 ATA trays soon and will retest with even more
> clients. So far performance improves with more clients. Kinda
> counter-intuitive, eh?
You seem to have missed the point... We're talking about Celerras, not
Clariions.
The CNS-14 and friends all need to maintain their file systems.
Other than that, the Clariions CX's are nice pieces of hardware - as long
as some previously unencountered bug doesn't make them blow up in your
face. *spits at two CX600s with seriously malfunctioning accesslogix*
--
/Jesper Monsted
| |
|
| > fsck is a file system problem and not the EMC. We are testing a CX500
I disagree. We had problems with our Celerra and were forced to do fscks
which took many hours to complete. DART, the underlying OS of the celerra,
has a UNIX like filesystem that can require lengthy fsck's when it gets
corrupted.
| |
| spiegela@gmail.com 2004-09-27, 5:46 pm |
| What was the context behind this? Was there an outage, or a persistent
problem? I'm not disputing your claim-- I'm just curious, I guess.
The way you have it phrased, its as though the system was running, and
EMC asked you to schedule an outage for this. That seems strange since
normally a filesystem with corruption would be unmountable.
Aaron
| |
| Jesper Monsted 2004-09-27, 5:46 pm |
| "spiegela@gmail.com" <spiegela@gmail.com> wrote in
news:1096318274.219967.237570@h37g2000oda.googlegroups.com:
> What was the context behind this? Was there an outage, or a persistent
> problem? I'm not disputing your claim-- I'm just curious, I guess.
Internal inconsistancies in some system table. I didn't really bother to
figure out what really happened since i don't really care about the box
(it's running and EMC takes care of it - i didn't want it anyway and won't
waste my time on it until it's actually decided what we're going to do with
it. It's a 2xDM, 2xCS CNS14 with a few nfs clients).
> The way you have it phrased, its as though the system was running, and
> EMC asked you to schedule an outage for this. That seems strange since
> normally a filesystem with corruption would be unmountable.
I think it happened when our clariion cx600's went nuts. EMC ended up
fixing the problem online, but the cx's still have a fscked up accesslogix
database.
--
/Jesper Monsted
|
|
|
|
|