Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #452905 > unrolled thread
| Started by | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| First post | 2017-03-21 10:21 -0700 |
| Last post | 2017-03-24 08:54 -0400 |
| Articles | 20 on this page of 113 — 24 participants |
Back to article view | Back to sci.electronics.design
big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-21 10:21 -0700
Re: big drives bitrex <bitrex@de.lete.earthlink.net> - 2017-03-21 13:47 -0400
Re: big drives George Herold <gherold@teachspin.com> - 2017-03-21 12:42 -0700
Re: big drives dagmargoodboat@yahoo.com - 2017-03-21 12:55 -0700
Re: big drives George Herold <gherold@teachspin.com> - 2017-03-21 13:37 -0700
Re: big drives bill.sloman@ieee.org - 2017-03-21 21:51 -0700
Re: big drives George Herold <gherold@teachspin.com> - 2017-03-22 07:26 -0700
Re: big drives Winfield Hill <hill@rowland.harvard.edu> - 2017-03-22 03:38 -0700
Re: big drives Don Kuenz <g@crcomp.net> - 2017-03-22 14:23 +0000
Re: big drives David Brown <david.brown@hesbynett.no> - 2017-03-22 16:43 +0100
Re: big drives Don Kuenz <g@crcomp.net> - 2017-03-22 18:35 +0000
Re: big drives David Brown <david.brown@hesbynett.no> - 2017-03-23 10:24 +0100
Re: big drives Don Kuenz <g@crcomp.net> - 2017-03-23 16:11 +0000
Re: big drives krw@notreal.com - 2017-03-23 13:05 -0400
Re: big drives Don Kuenz <g@crcomp.net> - 2017-03-23 17:39 +0000
Re: big drives krw@notreal.com - 2017-03-23 21:05 -0400
Re: big drives Don Kuenz <g@crcomp.net> - 2017-03-24 03:01 +0000
Re: big drives krw@notreal.com - 2017-03-23 23:09 -0400
Re: big drives Don Kuenz <g@crcomp.net> - 2017-03-24 04:15 +0000
Re: big drives krw@notreal.com - 2017-03-24 22:34 -0400
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-22 12:25 -0700
Re: big drives dplatt@coop.radagast.org (Dave Platt) - 2017-03-22 13:57 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-22 16:03 -0700
Re: big drives krw@notreal.com - 2017-03-22 20:29 -0400
Re: big drives tabbypurr@gmail.com - 2017-03-22 04:36 -0700
Re: big drives Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> - 2017-03-22 08:57 -0400
Re: big drives Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-03-22 11:59 -0400
Re: big drives krw@notreal.com - 2017-03-22 13:23 -0400
Re: big drives Jon Elson <jmelson@wustl.edu> - 2017-03-22 16:38 -0500
Re: big drives krw@notreal.com - 2017-03-22 20:31 -0400
Re: big drives gray_wolf <g_wolf@nospam.com> - 2017-03-23 20:59 -0500
Re: big drives gray_wolf <g_wolf@nospam.com> - 2017-03-23 21:00 -0500
Re: big drives Robert Baer <robertbaer@localnet.com> - 2017-03-23 22:21 -0800
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-22 07:51 -0700
Re: big drives krw@notreal.com - 2017-03-22 13:23 -0400
Re: big drives Robert Baer <robertbaer@localnet.com> - 2017-03-23 22:19 -0800
Re: big drives tabbypurr@gmail.com - 2017-03-24 04:26 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-24 08:38 -0700
Re: big drives Jon Elson <jmelson@wustl.edu> - 2017-03-22 16:37 -0500
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-22 16:07 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-22 16:21 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-22 16:45 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-22 23:21 -0700
Re: big drives John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-24 13:06 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 16:56 -0700
Re: big drives John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-24 17:35 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 21:47 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-22 16:19 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-22 16:50 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-22 17:58 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-22 21:00 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-22 22:50 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-23 08:27 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-23 12:25 -0700
Re: big drives tabbypurr@gmail.com - 2017-03-24 04:31 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 06:38 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-24 08:41 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 11:38 -0700
Re: big drives John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-24 13:55 -0700
Re: big drives tabbypurr@gmail.com - 2017-03-24 17:14 -0700
Re: big drives John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-24 17:41 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 18:00 -0700
Re: big drives Joerg <news@analogconsultants.com> - 2017-03-23 09:35 -0700
Re: big drives "Michael A. Terrell" <mike.terrell@earthlink.net> - 2017-03-23 18:38 -0400
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-23 16:18 -0700
Re: big drives Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-03-23 18:29 -0400
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-23 18:38 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-23 18:54 -0700
Re: big drives pcdhobbs@gmail.com - 2017-03-23 19:16 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-23 19:28 -0700
Re: big drives pcdhobbs@gmail.com - 2017-03-23 19:55 -0700
Re: big drives krw@notreal.com - 2017-03-23 23:04 -0400
Re: big drives pcdhobbs@gmail.com - 2017-03-23 22:00 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-24 08:46 -0700
Re: big drives krw@notreal.com - 2017-03-24 22:38 -0400
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-23 22:22 -0700
Re: big drives pcdhobbs@gmail.com - 2017-03-23 23:08 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 00:21 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-24 09:00 -0700
Re: big drives David Brown <david.brown@hesbynett.no> - 2017-03-24 17:14 +0100
Re: big drives tabbypurr@gmail.com - 2017-03-24 09:19 -0700
Re: big drives David Brown <david.brown@hesbynett.no> - 2017-03-24 17:47 +0100
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 12:01 -0700
Re: big drives Jasen Betts <jasen@xnet.co.nz> - 2017-03-24 20:30 +0000
Re: big drives John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-24 14:06 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 11:55 -0700
Re: big drives "Michael A. Terrell" <mike.terrell@earthlink.net> - 2017-03-25 04:00 -0400
Re: big drives upsidedown@downunder.com - 2017-03-24 22:18 +0200
Re: big drives John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-24 14:15 -0700
Re: big drives Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-25 13:21 +0200
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-25 07:54 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-25 10:53 -0700
Re: big drives upsidedown@downunder.com - 2017-03-25 23:11 +0200
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-25 15:14 -0700
Re: big drives upsidedown@downunder.com - 2017-03-26 12:18 +0300
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-26 03:33 -0700
Re: big drives Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-03-26 16:36 -0400
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-26 14:13 -0700
Re: big drives Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-25 21:04 +0200
Re: big drives pcdhobbs@gmail.com - 2017-03-24 19:03 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-24 08:53 -0700
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 12:12 -0700
Re: big drives John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-24 14:20 -0700
Re: big drives krw@notreal.com - 2017-03-24 22:43 -0400
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-24 20:10 -0700
Re: big drives krw@notreal.com - 2017-03-24 23:23 -0400
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-24 22:25 -0700
Re: big drives Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-25 13:23 +0200
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-23 19:36 -0700
Re: big drives upsidedown@downunder.com - 2017-03-24 10:14 +0200
Re: big drives Don Y <blockedofcourse@foo.invalid> - 2017-03-24 01:31 -0700
Re: big drives John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-23 16:21 -0700
Re: big drives "Michael A. Terrell" <mike.terrell@earthlink.net> - 2017-03-24 08:54 -0400
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-03-21 10:21 -0700 |
| Subject | big drives |
| Message-ID | <rpn2dc9nqndp7glvfi5pdedb8ujgmf7pln@4ax.com> |
I just happened to open my recycle bin and there was 42 Gbytes of junk. I remember 256 Kbyte hard drives. A PC with a 10M drive was top-end. There's no point in reducing jpeg sizes, or even deleting stuff, any more. I could never take enough pics, or create enough docs, to keep up with the progress in hard drives. I suppose some people could collect a large number of HD movies and use a terabyte somehow. It's impossible to crack one-time-pad encryption. Giant hard drives and memory sticks make OTP files easy to physically hand off to correspondents. -- John Larkin Highland Technology, Inc jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
[toc] | [next] | [standalone]
| From | bitrex <bitrex@de.lete.earthlink.net> |
|---|---|
| Date | 2017-03-21 13:47 -0400 |
| Message-ID | <bHdAA.18717$_83.7632@fx07.iad> |
| In reply to | #452905 |
On 03/21/2017 01:21 PM, John Larkin wrote: > > I just happened to open my recycle bin and there was 42 Gbytes of > junk. > > I remember 256 Kbyte hard drives. A PC with a 10M drive was top-end. > > There's no point in reducing jpeg sizes, or even deleting stuff, any > more. I could never take enough pics, or create enough docs, to keep > up with the progress in hard drives. I suppose some people could > collect a large number of HD movies and use a terabyte somehow. You're actually increasing the entropy of the universe by doing so, so probably better not to. Eventually file sizes will become so large that you'll be able to warm your home in wintertime from the waste heat generated every time you delete a lousy photo.
[toc] | [prev] | [next] | [standalone]
| From | George Herold <gherold@teachspin.com> |
|---|---|
| Date | 2017-03-21 12:42 -0700 |
| Message-ID | <ce547f70-9055-4132-b1d0-23ec98cbb81b@googlegroups.com> |
| In reply to | #452912 |
On Tuesday, March 21, 2017 at 1:47:55 PM UTC-4, bitrex wrote: > On 03/21/2017 01:21 PM, John Larkin wrote: > > > > I just happened to open my recycle bin and there was 42 Gbytes of > > junk. > > > > I remember 256 Kbyte hard drives. A PC with a 10M drive was top-end. > > > > There's no point in reducing jpeg sizes, or even deleting stuff, any > > more. I could never take enough pics, or create enough docs, to keep > > up with the progress in hard drives. I suppose some people could > > collect a large number of HD movies and use a terabyte somehow. > > You're actually increasing the entropy of the universe by doing so, so > probably better not to. > > Eventually file sizes will become so large that you'll be able to warm > your home in wintertime from the waste heat generated every time you > delete a lousy photo. Hmm each bit will add kT of energy. To get a Joule we'll need ~10^21 bits. Looks like maybe 16 Joules... http://www.idc.com/downloads/where_is_storage_infographic_243338.pdf (Yeah bits/ bytes.. .but only bits storing information count. I'm guessing most bits in your typical byte are redundant.) George H.
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-03-21 12:55 -0700 |
| Message-ID | <afce6632-f01d-4a82-b5f0-7cb33afe8b8a@googlegroups.com> |
| In reply to | #452933 |
On Tuesday, March 21, 2017 at 3:42:27 PM UTC-4, George Herold wrote: > (Yeah bits/ bytes.. .but only bits storing information count. > I'm guessing most bits in your typical byte are redundant.) Absolutely. I only use bits 0 and 2, personally. But I'm thinking of cutting back. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | George Herold <gherold@teachspin.com> |
|---|---|
| Date | 2017-03-21 13:37 -0700 |
| Message-ID | <1ad44e59-cebc-4f97-8e89-0cc745b4584b@googlegroups.com> |
| In reply to | #452936 |
On Tuesday, March 21, 2017 at 3:55:10 PM UTC-4, dagmarg...@yahoo.com wrote: > On Tuesday, March 21, 2017 at 3:42:27 PM UTC-4, George Herold wrote: > > > (Yeah bits/ bytes.. .but only bits storing information count. > > I'm guessing most bits in your typical byte are redundant.) > > Absolutely. I only use bits 0 and 2, personally. But I'm thinking > of cutting back. > > Cheers, > James Arthur Grin... James, no one can every say you aren't doing your bit to save energy. George h.
[toc] | [prev] | [next] | [standalone]
| From | bill.sloman@ieee.org |
|---|---|
| Date | 2017-03-21 21:51 -0700 |
| Message-ID | <4221e12c-c203-4ee2-b921-a4d8e4b0ad19@googlegroups.com> |
| In reply to | #452939 |
On Wednesday, March 22, 2017 at 7:37:21 AM UTC+11, George Herold wrote: > On Tuesday, March 21, 2017 at 3:55:10 PM UTC-4, dagmarg...@yahoo.com wrote: > > On Tuesday, March 21, 2017 at 3:42:27 PM UTC-4, George Herold wrote: > > > > > (Yeah bits/ bytes.. .but only bits storing information count. > > > I'm guessing most bits in your typical byte are redundant.) > > > > Absolutely. I only use bits 0 and 2, personally. But I'm thinking > > of cutting back. > > > > Cheers, > > James Arthur > > Grin... James, no one can every say you aren't doing your bit to save energy. > > George h. James Arthur doesn't process new information. If Bastiat hadn't said it by 1850, it wasn't worth saying. -- Bill Sloman, Sydney
[toc] | [prev] | [next] | [standalone]
| From | George Herold <gherold@teachspin.com> |
|---|---|
| Date | 2017-03-22 07:26 -0700 |
| Message-ID | <cf451fcb-f780-45b0-af75-fd7755988e9c@googlegroups.com> |
| In reply to | #453007 |
On Wednesday, March 22, 2017 at 12:51:17 AM UTC-4, bill....@ieee.org wrote: > On Wednesday, March 22, 2017 at 7:37:21 AM UTC+11, George Herold wrote: > > On Tuesday, March 21, 2017 at 3:55:10 PM UTC-4, dagmarg...@yahoo.com wrote: > > > On Tuesday, March 21, 2017 at 3:42:27 PM UTC-4, George Herold wrote: > > > > > > > (Yeah bits/ bytes.. .but only bits storing information count. > > > > I'm guessing most bits in your typical byte are redundant.) > > > > > > Absolutely. I only use bits 0 and 2, personally. But I'm thinking > > > of cutting back. > > > > > > Cheers, > > > James Arthur > > > > Grin... James, no one can every say you aren't doing your bit to save energy. > > > > George h. > > James Arthur doesn't process new information. If Bastiat hadn't said it by 1850, it wasn't worth saying. > > -- > Bill Sloman, Sydney Bill, I don't read anything you write. If you want to respond with something funny, or informative, that's fine. I like James, we disagree about some political things, but that doesn't bother me. I detest all the name calling. It is perhaps one of my flaws, that I expect better behavior from my allies vs opponents. (Though opponents is too strong a word.) Of course I'm often disappointed in that regard. George H.
[toc] | [prev] | [next] | [standalone]
| From | Winfield Hill <hill@rowland.harvard.edu> |
|---|---|
| Date | 2017-03-22 03:38 -0700 |
| Message-ID | <oatk6f031g4@drn.newsguy.com> |
| In reply to | #452905 |
John Larkin wrote...
>
>
>I just happened to open my recycle bin and there was 42 Gbytes of
>junk.
>
>I remember 256 Kbyte hard drives. A PC with a 10M drive was top-end.
>
>There's no point in reducing jpeg sizes, or even deleting stuff, any
>more. I could never take enough pics, or create enough docs, to keep
>up with the progress in hard drives. I suppose some people could
>collect a large number of HD movies and use a terabyte somehow.
>
>It's impossible to crack one-time-pad encryption. Giant hard drives
>and memory sticks make OTP files easy to physically hand off to
>correspondents.
An old saying, true from the 70s, until nearly 2000:
There are just two types of hard drives,
new ones, and full ones.
--
Thanks,
- Win
[toc] | [prev] | [next] | [standalone]
| From | Don Kuenz <g@crcomp.net> |
|---|---|
| Date | 2017-03-22 14:23 +0000 |
| Message-ID | <20170322a@crcomp.net> |
| In reply to | #453021 |
Winfield Hill <hill@rowland.harvard.edu> wrote: > John Larkin wrote... >> >> >>I just happened to open my recycle bin and there was 42 Gbytes of >>junk. >> >>I remember 256 Kbyte hard drives. A PC with a 10M drive was top-end. >> >>There's no point in reducing jpeg sizes, or even deleting stuff, any >>more. I could never take enough pics, or create enough docs, to keep >>up with the progress in hard drives. I suppose some people could >>collect a large number of HD movies and use a terabyte somehow. >> >>It's impossible to crack one-time-pad encryption. Giant hard drives >>and memory sticks make OTP files easy to physically hand off to >>correspondents. > > An old saying, true from the 70s, until nearly 2000: > There are just two types of hard drives, > new ones, and full ones. > The 15K RPM 600 GB SAS RAID5 array in one of my server farms is so full that it recently grew into a second chassis. That sucks in many ways. The root problem is a 600 GB limitation on 15K RPM SAS hard drives that has been in force for about a decade now. There's been absolutely no improvement nor innovation in 15K RPM SAS drives over that period of time. Thank you, -- Don Kuenz KB7RPU
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-22 16:43 +0100 |
| Message-ID | <oau5tt$dpd$1@dont-email.me> |
| In reply to | #453032 |
On 22/03/17 15:23, Don Kuenz wrote: > Winfield Hill <hill@rowland.harvard.edu> wrote: >> John Larkin wrote... >>> >>> >>> I just happened to open my recycle bin and there was 42 Gbytes of >>> junk. >>> >>> I remember 256 Kbyte hard drives. A PC with a 10M drive was top-end. >>> >>> There's no point in reducing jpeg sizes, or even deleting stuff, any >>> more. I could never take enough pics, or create enough docs, to keep >>> up with the progress in hard drives. I suppose some people could >>> collect a large number of HD movies and use a terabyte somehow. >>> >>> It's impossible to crack one-time-pad encryption. Giant hard drives >>> and memory sticks make OTP files easy to physically hand off to >>> correspondents. >> >> An old saying, true from the 70s, until nearly 2000: >> There are just two types of hard drives, >> new ones, and full ones. >> > > The 15K RPM 600 GB SAS RAID5 array in one of my server farms is so full > that it recently grew into a second chassis. That sucks in many ways. > > The root problem is a 600 GB limitation on 15K RPM SAS hard drives that > has been in force for about a decade now. There's been absolutely no > improvement nor innovation in 15K RPM SAS drives over that period of > time. > My usual supplier has 15K rpm SAS at 0.9 TB, 2.5". It also has 1 GB SSDs that are /much/ faster, and more reliable, at half the price. So the root problem is that you are stuck in outdated technology. (I fully appreciate at that it can make sense to continue with what you have, rather than change to something new even if it is cheaper, faster, and more readily available. There can be many reasons for that.)
[toc] | [prev] | [next] | [standalone]
| From | Don Kuenz <g@crcomp.net> |
|---|---|
| Date | 2017-03-22 18:35 +0000 |
| Message-ID | <20170322b@crcomp.net> |
| In reply to | #453042 |
David Brown <david.brown@hesbynett.no> wrote: > On 22/03/17 15:23, Don Kuenz wrote: <snip> >> >> The 15K RPM 600 GB SAS RAID5 array in one of my server farms is so full >> that it recently grew into a second chassis. That sucks in many ways. >> >> The root problem is a 600 GB limitation on 15K RPM SAS hard drives that >> has been in force for about a decade now. There's been absolutely no >> improvement nor innovation in 15K RPM SAS drives over that period of >> time. >> > > My usual supplier has 15K rpm SAS at 0.9 TB, 2.5". It also has 1 GB > SSDs that are /much/ faster, and more reliable, at half the price. So > the root problem is that you are stuck in outdated technology. > > (I fully appreciate at that it can make sense to continue with what you > have, rather than change to something new even if it is cheaper, faster, > and more readily available. There can be many reasons for that.) The capacity of 3.5" 15K SAS hard drives has been stalled at an upper limit of 600 GB for about a decade now. It becomes more of a problem in the enterprise space with each passing day. "Outdated technology" seems like a cop out when brand new PCs with 3.5" hard drives larger than 10 TB are about to ship. The rationalization that users have only themselves to blame for using "outdated technology" reminds me of Dilbert's boss. "It isn't a problem if you can give it to someone else." That's what Dilbert's boss always says. Thank you, -- Don Kuenz KB7RPU
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-23 10:24 +0100 |
| Message-ID | <ob043n$6sa$1@dont-email.me> |
| In reply to | #453087 |
On 22/03/17 19:35, Don Kuenz wrote: > David Brown <david.brown@hesbynett.no> wrote: >> On 22/03/17 15:23, Don Kuenz wrote: > > <snip> > >>> >>> The 15K RPM 600 GB SAS RAID5 array in one of my server farms is so full >>> that it recently grew into a second chassis. That sucks in many ways. >>> >>> The root problem is a 600 GB limitation on 15K RPM SAS hard drives that >>> has been in force for about a decade now. There's been absolutely no >>> improvement nor innovation in 15K RPM SAS drives over that period of >>> time. >>> >> >> My usual supplier has 15K rpm SAS at 0.9 TB, 2.5". It also has 1 GB >> SSDs that are /much/ faster, and more reliable, at half the price. So >> the root problem is that you are stuck in outdated technology. >> >> (I fully appreciate at that it can make sense to continue with what you >> have, rather than change to something new even if it is cheaper, faster, >> and more readily available. There can be many reasons for that.) > > The capacity of 3.5" 15K SAS hard drives has been stalled at an upper > limit of 600 GB for about a decade now. It becomes more of a problem in > the enterprise space with each passing day. For 3.5" drives, that might well be true. A 15K rpm 3.5" drive is mechanically much more demanding than a 2.5" drive. And since you can get much faster and much more reliable drives for less money, and you can also get brackets to fit 2.5" disks into 3.5" frames, it is extremely unlikely that anyone is going to make new 15K 3.5" drives. > > "Outdated technology" seems like a cop out when brand new PCs with 3.5" > hard drives larger than 10 TB are about to ship. The rationalization > that users have only themselves to blame for using "outdated technology" > reminds me of Dilbert's boss. "It isn't a problem if you can give it to > someone else." That's what Dilbert's boss always says. > Hard disks are not outdated technology, nor are 3.5" disks. But super-fast hard disks /are/ outdated - there is no point in them. SSDs are smaller, faster, cheaper, lower power, and more reliable - they win on every count. Your entire multi-disk raid could be replaced by a couple of big SSDs in RAID1 (or perhaps Linux RAID10) setup for a faster system taking less space and using a fraction of the power and noise. (Again, I fully understand that replacement is not necessarily a cheap or easy process - I am giving you the manufacturers' viewpoint here.) Hard disks make sense when you want cheap GB's. SSDs make sense when you want speed. So new hard disks these days are typically 5400 or maybe 7200 rpm - 10K and 15K spinning rust is a thing of the past.
[toc] | [prev] | [next] | [standalone]
| From | Don Kuenz <g@crcomp.net> |
|---|---|
| Date | 2017-03-23 16:11 +0000 |
| Message-ID | <20170323a@crcomp.net> |
| In reply to | #453209 |
David Brown <david.brown@hesbynett.no> wrote: <snip> > Hard disks are not outdated technology, nor are 3.5" disks. But > super-fast hard disks /are/ outdated - there is no point in them. SSDs > are smaller, faster, cheaper, lower power, and more reliable - they win > on every count. Your entire multi-disk raid could be replaced by a > couple of big SSDs in RAID1 (or perhaps Linux RAID10) setup for a faster > system taking less space and using a fraction of the power and noise. > (Again, I fully understand that replacement is not necessarily a cheap > or easy process - I am giving you the manufacturers' viewpoint here.) > > Hard disks make sense when you want cheap GB's. SSDs make sense when > you want speed. So new hard disks these days are typically 5400 or > maybe 7200 rpm - 10K and 15K spinning rust is a thing of the past. Technical glitches such as the Seagate plague make me hesitant to bet my farms on SSD. Other people can bet *their* farms first and we'll see what happens. At this present point in time it's best for me to "lead from behind" just like a science fictional hindmost puppeteer. :0) Thank you, -- Don Kuenz KB7RPU
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-03-23 13:05 -0400 |
| Message-ID | <3uv7dclii8s6nkmqrpi3kvdboshgv1biv3@4ax.com> |
| In reply to | #453235 |
On Thu, 23 Mar 2017 16:11:01 -0000 (UTC), Don Kuenz <g@crcomp.net> wrote: > >David Brown <david.brown@hesbynett.no> wrote: > ><snip> > >> Hard disks are not outdated technology, nor are 3.5" disks. But >> super-fast hard disks /are/ outdated - there is no point in them. SSDs >> are smaller, faster, cheaper, lower power, and more reliable - they win >> on every count. Your entire multi-disk raid could be replaced by a >> couple of big SSDs in RAID1 (or perhaps Linux RAID10) setup for a faster >> system taking less space and using a fraction of the power and noise. >> (Again, I fully understand that replacement is not necessarily a cheap >> or easy process - I am giving you the manufacturers' viewpoint here.) >> >> Hard disks make sense when you want cheap GB's. SSDs make sense when >> you want speed. So new hard disks these days are typically 5400 or >> maybe 7200 rpm - 10K and 15K spinning rust is a thing of the past. > >Technical glitches such as the Seagate plague make me hesitant to bet >my farms on SSD. Other people can bet *their* farms first and we'll see >what happens. At this present point in time it's best for me to "lead >from behind" just like a science fictional hindmost puppeteer. :0) There is always a learning curve and SSD isn't the right technology for long-term storage (yet) but for a fast drive for computations, what's the problem? If it fails, so what? They're also great for laptops, for obvious reasons.
[toc] | [prev] | [next] | [standalone]
| From | Don Kuenz <g@crcomp.net> |
|---|---|
| Date | 2017-03-23 17:39 +0000 |
| Message-ID | <20170323b@crcomp.net> |
| In reply to | #453240 |
krw@notreal.com wrote: > On Thu, 23 Mar 2017 16:11:01 -0000 (UTC), Don Kuenz <g@crcomp.net> > wrote: > >> >>David Brown <david.brown@hesbynett.no> wrote: >> >><snip> >> >>> Hard disks are not outdated technology, nor are 3.5" disks. But >>> super-fast hard disks /are/ outdated - there is no point in them. SSDs >>> are smaller, faster, cheaper, lower power, and more reliable - they win >>> on every count. Your entire multi-disk raid could be replaced by a >>> couple of big SSDs in RAID1 (or perhaps Linux RAID10) setup for a faster >>> system taking less space and using a fraction of the power and noise. >>> (Again, I fully understand that replacement is not necessarily a cheap >>> or easy process - I am giving you the manufacturers' viewpoint here.) >>> >>> Hard disks make sense when you want cheap GB's. SSDs make sense when >>> you want speed. So new hard disks these days are typically 5400 or >>> maybe 7200 rpm - 10K and 15K spinning rust is a thing of the past. >> >> >>Technical glitches such as the Seagate plague make me hesitant to bet >>my farms on SSD. Other people can bet *their* farms first and we'll see >>what happens. At this present point in time it's best for me to "lead >>from behind" just like a science fictional hindmost puppeteer. :0) > > There is always a learning curve and SSD isn't the right technology > for long-term storage (yet) but for a fast drive for computations, > what's the problem? If it fails, so what? > > They're also great for laptops, for obvious reasons. SSD deployments into non-mission critical applications are actually quite old school to me at this juncture. Regardless it's still best for me to "lead from behind" and let other people bet their own mission critical farms first. :0) Thank you, -- Don Kuenz KB7RPU
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-03-23 21:05 -0400 |
| Message-ID | <35s8dc1huf6dvav4hn5jbu1hppkmro5pfq@4ax.com> |
| In reply to | #453245 |
On Thu, 23 Mar 2017 17:39:36 -0000 (UTC), Don Kuenz <g@crcomp.net> wrote: > >krw@notreal.com wrote: >> On Thu, 23 Mar 2017 16:11:01 -0000 (UTC), Don Kuenz <g@crcomp.net> >> wrote: >> >>> >>>David Brown <david.brown@hesbynett.no> wrote: >>> >>><snip> >>> >>>> Hard disks are not outdated technology, nor are 3.5" disks. But >>>> super-fast hard disks /are/ outdated - there is no point in them. SSDs >>>> are smaller, faster, cheaper, lower power, and more reliable - they win >>>> on every count. Your entire multi-disk raid could be replaced by a >>>> couple of big SSDs in RAID1 (or perhaps Linux RAID10) setup for a faster >>>> system taking less space and using a fraction of the power and noise. >>>> (Again, I fully understand that replacement is not necessarily a cheap >>>> or easy process - I am giving you the manufacturers' viewpoint here.) >>>> >>>> Hard disks make sense when you want cheap GB's. SSDs make sense when >>>> you want speed. So new hard disks these days are typically 5400 or >>>> maybe 7200 rpm - 10K and 15K spinning rust is a thing of the past. >>> >>> >>>Technical glitches such as the Seagate plague make me hesitant to bet >>>my farms on SSD. Other people can bet *their* farms first and we'll see >>>what happens. At this present point in time it's best for me to "lead >>>from behind" just like a science fictional hindmost puppeteer. :0) >> >> There is always a learning curve and SSD isn't the right technology >> for long-term storage (yet) but for a fast drive for computations, >> what's the problem? If it fails, so what? >> >> They're also great for laptops, for obvious reasons. > >SSD deployments into non-mission critical applications are actually >quite old school to me at this juncture. Regardless it's still best >for me to "lead from behind" and let other people bet their own >mission critical farms first. :0) What's "mission critical" about a cycle server? Add another.
[toc] | [prev] | [next] | [standalone]
| From | Don Kuenz <g@crcomp.net> |
|---|---|
| Date | 2017-03-24 03:01 +0000 |
| Message-ID | <20170323c@crcomp.net> |
| In reply to | #453310 |
<snip> >>SSD deployments into non-mission critical applications are actually >>quite old school to me at this juncture. Regardless it's still best >>for me to "lead from behind" and let other people bet their own >>mission critical farms first. :0) > > What's "mission critical" about a cycle server? Add another. My server farms, plural, each contain multiple servers. There's at most one cycle server in the mix. That particular cycle server is not mission critical. The remaining servers of interest host mission critical applications for unaffiliated enterprises. It's just like the name says, when a mission critical server fails the enterprise fails. That's why it's best for me to "lead from behind" and let other people bet their own mission critical farms first. :0) Thank you, -- Don Kuenz KB7RPU
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-03-23 23:09 -0400 |
| Message-ID | <s739dc9j4e0l6d8bifhflrmto6psi1p96l@4ax.com> |
| In reply to | #453327 |
On Fri, 24 Mar 2017 03:01:32 -0000 (UTC), Don Kuenz <g@crcomp.net> wrote: > ><snip> > >>>SSD deployments into non-mission critical applications are actually >>>quite old school to me at this juncture. Regardless it's still best >>>for me to "lead from behind" and let other people bet their own >>>mission critical farms first. :0) >> >> What's "mission critical" about a cycle server? Add another. > >My server farms, plural, each contain multiple servers. There's at most >one cycle server in the mix. That particular cycle server is not mission >critical. > >The remaining servers of interest host mission critical applications for >unaffiliated enterprises. It's just like the name says, when a mission >critical server fails the enterprise fails. That's why it's best for me >to "lead from behind" and let other people bet their own mission >critical farms first. :0) OK, but you haven't addressed the point. What's the purpose of a 15K drive - at all. For a cycle-server, reliability isn't critical so SSD is a natural solution. The disk in a byte server needs more reliability (RAID helps a lot) but not so much speed. A slower, high-density drive will have the same, or even higher data rate as a 15K and an SSD has *far* faster access. What's the point in the 15K? My bet is that's why they haven't improved much.
[toc] | [prev] | [next] | [standalone]
| From | Don Kuenz <g@crcomp.net> |
|---|---|
| Date | 2017-03-24 04:15 +0000 |
| Message-ID | <20170323d@crcomp.net> |
| In reply to | #453329 |
krw@notreal.com wrote: > On Fri, 24 Mar 2017 03:01:32 -0000 (UTC), Don Kuenz <g@crcomp.net> > wrote: > >> >><snip> >> >>>>SSD deployments into non-mission critical applications are actually >>>>quite old school to me at this juncture. Regardless it's still best >>>>for me to "lead from behind" and let other people bet their own >>>>mission critical farms first. :0) >>> >>> What's "mission critical" about a cycle server? Add another. >> >>My server farms, plural, each contain multiple servers. There's at most >>one cycle server in the mix. That particular cycle server is not mission >>critical. >> >>The remaining servers of interest host mission critical applications for >>unaffiliated enterprises. It's just like the name says, when a mission >>critical server fails the enterprise fails. That's why it's best for me >>to "lead from behind" and let other people bet their own mission >>critical farms first. :0) > > OK, but you haven't addressed the point. What's the purpose of a 15K > drive - at all. For a cycle-server, reliability isn't critical so SSD > is a natural solution. The disk in a byte server needs more > reliability (RAID helps a lot) but not so much speed. A slower, > high-density drive will have the same, or even higher data rate as a > 15K and an SSD has *far* faster access. What's the point in the 15K? > My bet is that's why they haven't improved much. One of my vendors supports thousands of dermatology and gastroenterology practices across the nation. They insist on 15K. They won't even give me the time of day without it. "You can't argue with success." And that's why 15K works for me too. Remember my "lead from behind" policy. :0) Thank you, -- Don Kuenz KB7RPU
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-03-24 22:34 -0400 |
| Message-ID | <5nlbdc5doqtjhoispao7rr5d440fvn2sr2@4ax.com> |
| In reply to | #453332 |
On Fri, 24 Mar 2017 04:15:15 -0000 (UTC), Don Kuenz <g@crcomp.net> wrote: > >krw@notreal.com wrote: >> On Fri, 24 Mar 2017 03:01:32 -0000 (UTC), Don Kuenz <g@crcomp.net> >> wrote: >> >>> >>><snip> >>> >>>>>SSD deployments into non-mission critical applications are actually >>>>>quite old school to me at this juncture. Regardless it's still best >>>>>for me to "lead from behind" and let other people bet their own >>>>>mission critical farms first. :0) >>>> >>>> What's "mission critical" about a cycle server? Add another. >>> >>>My server farms, plural, each contain multiple servers. There's at most >>>one cycle server in the mix. That particular cycle server is not mission >>>critical. >>> >>>The remaining servers of interest host mission critical applications for >>>unaffiliated enterprises. It's just like the name says, when a mission >>>critical server fails the enterprise fails. That's why it's best for me >>>to "lead from behind" and let other people bet their own mission >>>critical farms first. :0) >> >> OK, but you haven't addressed the point. What's the purpose of a 15K >> drive - at all. For a cycle-server, reliability isn't critical so SSD >> is a natural solution. The disk in a byte server needs more >> reliability (RAID helps a lot) but not so much speed. A slower, >> high-density drive will have the same, or even higher data rate as a >> 15K and an SSD has *far* faster access. What's the point in the 15K? >> My bet is that's why they haven't improved much. > >One of my vendors supports thousands of dermatology and gastroenterology >practices across the nation. They insist on 15K. They won't even give me >the time of day without it. > >"You can't argue with success." And that's why 15K works for me too. >Remember my "lead from behind" policy. :0) Because there is a demand doesn't mean it's a good idea. Times change.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | sci.electronics.design
csiph-web