Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #14969
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Implementing virtual memory on cassette tape |
| Date | 2012-08-15 15:13 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2012Aug15.171336@mips.complang.tuwien.ac.at> (permalink) |
| References | (3 earlier) <c5f1248a-11dd-4cca-b710-b95ea69d6c5f@y1g2000vbx.googlegroups.com> <2012Aug9.154425@mips.complang.tuwien.ac.at> <46bbc85d-2dab-40cd-a4a0-6e4550e969b5@i7g2000vbc.googlegroups.com> <2012Aug10.175704@mips.complang.tuwien.ac.at> <d4f71351-45cd-4f16-aa48-8d92b8a3ee8f@n13g2000vby.googlegroups.com> |
Alex McDonald <blog@rivadpm.com> writes:
>On Aug 10, 4:57=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Alex McDonald <b...@rivadpm.com> writes:
>> >On Aug 9, 2:44=3DA0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>> >wrote:
>> >> Alex McDonald <b...@rivadpm.com> writes:
>> >> >On Aug 9, 7:00=3D3DA0am, an...@mips.complang.tuwien.ac.at (Anton Ertl=
>)
>> >> >wrote:
>> >To spin up a RAID group of say 14 drives on a shelf of disks will
>> >require that the drives are turned on serially in small groups.
>>
>> No. =A0If the hardware cannot spin them up at the same time, one will
>> not choose such a large RAID group. =A0Conversely, if RAID groups of 14
>> disks are desired, the hardware should be designed so that the group
>> can be spun up at the same time. =A0For a system that contains 480 disk
>> drives, dimensioning the power supply such that it can spin up 14
>> drives at once should be no problem.
>
>The power supplies are relatively small, and serve a disk shelf that
>is (commonly) organised in groups that can be fitted in a 19inch rack
>system. 14 drives or more is a common number, although very dense 48
>drive systems are also available. In total, the loading on a rack of
>such shelves (which may be in the mid hundreds to more of drives)
>cannot exceed certain limits in terms of amperage due to the heat
>generated; 15KW or more heat from a rack is difficult to dissipate.
If I have several power supplies, each powering a bunch of drives, I
would distribute the RAID group across these bunches, ideally one
drive per bunch. A nice side benefit is that the system can now
survive a power supply failure without needing any additional power
supply redundancy (not sure if the following rebuilding of lots of
RAID groups on power supply failure is practical, though, but if it
isn't, then we'll just have to bite the bullet and provide power
supply redundancy after all). So, to spin up a whole RAID group at
the same time, each power supply only needs to be able to support
spinning up one drive.
15KW would allow spinning up 480 drives at the same time (and would
also be necessary to let 480 LTO-5 tape drives work at the same time).
>Scaling power supplies on a shelf to support 14 drives power-up
>simultaneously means that most of the time supplies are operating at
>low loads, which is where power supplies are very inefficient; running
>them near their maximum rating is preferable, when conversion rates
>can be 90% or better.
Typical power supplies are relatively efficient across a pretty wide
range, and the highest efficiency is not at maximum load. E.g.,
looking at
http://www.anandtech.com/show/6013/350450w-roundup-11-cheap-psus/3,
i.e., even looking at a cheap power supply, there is relatively little
efficiency variation between 20% and 110% load, and the highest
efficiency is at 50% load. I also looked at the next one in the test
(FSP OEM 400W) and find the same pattern there.
>> For our servers, the bandwidth off the server disks is the limit most
>> of the time, because there is a lot of seeking during backups, and
>> also, the data is already compressed when it goes off the server.
>
>A smart backup program can reduce seeks by sorting, say, a snapshot of
>th disk, to reduce the seeks and read blocks serially. Enterprise
>class disks often support "skip read" semantics that can reduce the
>requirement to seek when reading data from a single track.
Any commodity drive I or my students have measured in the last 15
years or so has cached the data of several tracks for reading (I guess
but have not confirmed that in particular they cache data that they
read while waiting for the disk to rotate to the target sector, but if
there was no request right afterward, probably also the rest of the
track), and that's why some OS-side optimizations we (and others) did
were not as effective as I expected: the drives already did part of
them for us. Anyway, I had not heard that this is a marketing feature
for enterprise drives, and Google has not heard about "skip read
semantics", either.
Concerning our backup program, we are just using tar instead of a
smart one. It's good enough for our needs, but it does not optimize
disk reads the way you suggest (it would need to more about file
systems than I find comfortable to do that), so there's quite a bit of
waiting for disk seeks despite drive caches.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Implementing virtual memory on cassette tape chitselb <chitselb@gmail.com> - 2012-08-07 06:21 -0700
Re: Implementing virtual memory on cassette tape Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-07 08:44 -0500
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-07 14:01 +0000
Re: Implementing virtual memory on cassette tape Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-07 07:24 -0700
Re: Implementing virtual memory on cassette tape Stan Barr <plan.b@dsl.pipex.com> - 2012-08-07 15:30 +0000
Re: Implementing virtual memory on cassette tape Stan Barr <plan.b@dsl.pipex.com> - 2012-08-07 17:36 +0000
Re: Implementing virtual memory on cassette tape Jason Damisch <jasondamisch@yahoo.com> - 2012-08-07 11:52 -0700
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-07 12:39 -0700
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-07 12:55 -0700
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-07 22:00 +0200
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-08 00:27 -0700
Re: Implementing virtual memory on cassette tape Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-08 01:26 -0700
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-08 02:31 -0700
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-08 02:46 -0700
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-08 02:23 -0700
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-08 10:57 +0000
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-08 04:59 -0700
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-08 12:24 +0000
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-08 11:10 -0700
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-09 00:13 +0200
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-08 16:05 -0700
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-08 17:30 -0700
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-09 03:26 +0200
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-09 05:30 -0700
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-09 19:21 +0200
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-09 13:30 -0700
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-10 01:27 +0200
Re: Implementing virtual memory on cassette tape vandys@vsta.org - 2012-08-09 00:32 +0000
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-09 03:33 +0200
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-09 06:00 +0000
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-09 05:26 -0700
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-09 13:44 +0000
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-09 10:21 -0700
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-09 19:50 +0200
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-09 12:32 -0700
Re: Implementing virtual memory on cassette tape Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-09 22:07 +0200
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-09 13:58 -0700
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-09 17:36 -0700
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-10 04:13 -0700
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-11 20:27 -0700
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-10 15:57 +0000
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-13 05:23 -0700
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-15 15:13 +0000
Re: Implementing virtual memory on cassette tape Alex McDonald <blog@rivadpm.com> - 2012-08-15 11:57 -0700
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-08 07:08 +0000
Re: Implementing virtual memory on cassette tape chitselb <chitselb@gmail.com> - 2012-08-08 06:25 -0700
Re: Implementing virtual memory on cassette tape Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-08 01:23 -0700
Re: Implementing virtual memory on cassette tape kenney@cix.compulink.co.uk - 2012-08-08 05:06 -0500
Re: Implementing virtual memory on cassette tape Percy <percival.andrews@gmail.com> - 2012-08-08 21:11 -0700
Re: Implementing virtual memory on cassette tape chitselb <chitselb@gmail.com> - 2012-08-08 21:30 -0700
Re: Implementing virtual memory on cassette tape percival.andrews@gmail.com - 2012-08-08 23:50 -0700
Re: Implementing virtual memory on cassette tape chitselb <chitselb@gmail.com> - 2012-08-09 03:54 -0700
Re: Implementing virtual memory on cassette tape Paul Rubin <no.email@nospam.invalid> - 2012-08-09 09:07 -0700
Re: Implementing virtual memory on cassette tape chitselb <chitselb@gmail.com> - 2012-08-09 12:20 -0700
Re: Implementing virtual memory on cassette tape Mat <dambere@web.de> - 2012-08-10 13:41 -0700
Re: Implementing virtual memory on cassette tape Coos Haak <chforth@hccnet.nl> - 2012-08-10 23:54 +0200
Re: Implementing virtual memory on cassette tape dambere@web.de - 2012-08-10 15:41 -0700
Re: Implementing virtual memory on cassette tape Coos Haak <chforth@hccnet.nl> - 2012-08-11 01:47 +0200
Re: Implementing virtual memory on cassette tape Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-11 03:50 -0500
Re: Implementing virtual memory on cassette tape anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-11 09:03 +0000
Re: Implementing virtual memory on cassette tape Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-11 16:08 -0500
Re: Implementing virtual memory on cassette tape "Elizabeth D. Rather" <erather@forth.com> - 2012-08-11 21:51 -1000
csiph-web