Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #219708 > unrolled thread

Advice on upgrading to SSD

Back to article view | Back to linux.debian.user

Contents

  Advice on upgrading to SSD Tony van der Hoff <lists@vanderhoff.org> - 2020-03-02 12:30 +0100
    Re: Advice on upgrading to SSD Gene Heskett <gheskett@shentel.net> - 2020-03-02 14:00 +0100
      Re: Advice on upgrading to SSD Tony van der Hoff <lists@vanderhoff.org> - 2020-03-04 15:50 +0100
        Re: Advice on upgrading to SSD grumpy@mailfence.com - 2020-03-04 16:10 +0100
        Re: Advice on upgrading to SSD Michael Stone <mstone@debian.org> - 2020-03-04 17:10 +0100
          Re: Advice on upgrading to SSD Nate Bargmann <n0nb@n0nb.us> - 2020-03-04 19:00 +0100
        Re: Advice on upgrading to SSD rhkramer@gmail.com - 2020-03-04 18:50 +0100
          Re: Advice on upgrading to SSD Dan Ritter <dsr@randomstring.org> - 2020-03-04 19:00 +0100
            Re: Advice on upgrading to SSD Cindy Sue Causey <butterflybytes@gmail.com> - 2020-03-04 20:30 +0100
            Re: Advice on upgrading to SSD "007@caiway.net" <007@caiway.net> - 2020-03-05 06:50 +0100
              Re: Advice on upgrading to SSD Klaus Singvogel <deb-user-ml@singvogel.net> - 2020-03-05 08:30 +0100
                Re: Advice on upgrading to SSD David Wright <deblis@lionunicorn.co.uk> - 2020-03-05 18:20 +0100
                  Re: Advice on upgrading to SSD Tixy <tixy@yxit.co.uk> - 2020-03-05 18:30 +0100
                  Re: Advice on upgrading to SSD Klaus Singvogel <klaus@singvogel.net> - 2020-03-05 19:00 +0100
          Re: Advice on upgrading to SSD Michael Stone <mstone@debian.org> - 2020-03-05 00:50 +0100
            Re: Advice on upgrading to SSD Gene Heskett <gheskett@shentel.net> - 2020-03-05 01:00 +0100
              Re: Advice on upgrading to SSD Michael Stone <mstone@debian.org> - 2020-03-05 04:30 +0100
                Re: Advice on upgrading to SSD Gene Heskett <gheskett@shentel.net> - 2020-03-05 04:40 +0100
              Re: Advice on upgrading to SSD <tomas@tuxteam.de> - 2020-03-05 09:30 +0100
                Re: Advice on upgrading to SSD rhkramer@gmail.com - 2020-03-05 16:20 +0100
                  Re: Advice on upgrading to SSD Michael Stone <mstone@debian.org> - 2020-03-05 20:00 +0100
                    Re: Advice on upgrading to SSD rhkramer@gmail.com - 2020-03-06 00:00 +0100
          Re: Advice on upgrading to SSD Gene Heskett <gheskett@shentel.net> - 2020-03-05 00:50 +0100
        Re: Advice on upgrading to SSD David Christensen <dpchrist@holgerdanske.com> - 2020-03-05 03:40 +0100
    Re: Advice on upgrading to SSD Dan Ritter <dsr@randomstring.org> - 2020-03-02 16:40 +0100
      Re: Advice on upgrading to SSD basti <basti@unix-solution.de> - 2020-03-02 17:30 +0100
        Re: Advice on upgrading to SSD deloptes <deloptes@gmail.com> - 2020-03-02 20:00 +0100
      Re: Advice on upgrading to SSD Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-03 09:30 +0100
    Re: Advice on upgrading to SSD Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-03-02 19:20 +0100
      Re: Advice on upgrading to SSD Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-03-02 20:40 +0100
    Re: Advice on upgrading to SSD David Christensen <dpchrist@holgerdanske.com> - 2020-03-02 20:20 +0100
      Re: Advice on upgrading to SSD Sarunas Burdulis <sarunas@math.dartmouth.edu> - 2020-03-02 20:30 +0100
        Re: Advice on upgrading to SSD Michael Stone <mstone@debian.org> - 2020-03-02 20:30 +0100
          Re: Advice on upgrading to SSD deloptes <deloptes@gmail.com> - 2020-03-02 22:10 +0100
    Re: Advice on upgrading to SSD Andy Smith <andy@strugglers.net> - 2020-03-03 01:50 +0100
      Re: Advice on upgrading to SSD Geoff <unit735@bigpond.com> - 2020-03-03 10:20 +0100

Page 1 of 2  [1] 2  Next page →

#219708 — Advice on upgrading to SSD

Hi,
I'm currently running Buster on a 5 year old GigaByte motherboard with a 
10-year old Raid-1 array on 2 500GB disks. Although it is running fine, 
I'm becoming a bit concerned about the longevity of this storage, so I'm 
planning to upgrade it to a 500GB or maybe 1TB SSD from Crucial.

My plan would be to install the SSD in the cage, and dd the contents of 
the array onto the SSD. I would then change the BIOS to boot from the 
SSD, making the RAID array redundant.

Can someone please tell me whether this plan is feasible, and what 
pitfalls I might encounter?

Thanks, Tony

-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [next] | [standalone]

#219709

On Monday 02 March 2020 06:28:58 Tony van der Hoff wrote:

> Hi,
> I'm currently running Buster on a 5 year old GigaByte motherboard with
> a 10-year old Raid-1 array on 2 500GB disks. Although it is running
> fine, I'm becoming a bit concerned about the longevity of this
> storage, so I'm planning to upgrade it to a 500GB or maybe 1TB SSD
> from Crucial.
>
> My plan would be to install the SSD in the cage, and dd the contents
> of the array onto the SSD. I would then change the BIOS to boot from
> the SSD, making the RAID array redundant.
>
> Can someone please tell me whether this plan is feasible, and what
> pitfalls I might encounter?
>
> Thanks, Tony

Its been my experience here, that drives that run 24/7, tend to run 
essentially forever. Shutting down and starting back up are the most 
dangerous times in the life of spinning rust.  I have an old spinning 
rust 1T here that has over 100k hours on it, and has not added to its 
original 25 reallocated sectors in all that time. I was going to show 
its report, but apparently it got cycled into a drawer with the last 
rebuild of this box after I had a fire at one of the usb ports and had 
to replace that 12 year old mobo.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#219770

> On Monday 02 March 2020 06:28:58 Tony van der Hoff wrote:
> 
>> Hi,
>> I'm currently running Buster on a 5 year old GigaByte motherboard with
>> a 10-year old Raid-1 array on 2 500GB disks. Although it is running
>> fine, I'm becoming a bit concerned about the longevity of this
>> storage, so I'm planning to upgrade it to a 500GB or maybe 1TB SSD
>> from Crucial.
>>
>> My plan would be to install the SSD in the cage, and dd the contents
>> of the array onto the SSD. I would then change the BIOS to boot from
>> the SSD, making the RAID array redundant.
>>
>> Can someone please tell me whether this plan is feasible, and what
>> pitfalls I might encounter?
>>

Thanks to all who replied.

Gene didn't address my problem, but made the very useful observation 
that disks spinning 24/7 don't really die. Perhaps I shouldn't worry 
about replacing them.

Dan gave a useful step-by-step procedure for copying at file level. This 
method is slightly problematical for me as it includes "make changes to 
new /etc/fstab" and "make changes to bootloader to set new root 
filesystem", neither of which I feel feel comfortable with, due to lack 
of knowledge. I'll certainly abandon my plan to dd the whole filesystem.

Basti and Deloptes propose to add the SSD as a third drive to the RAID. 
Very attractive, but would involve complications if the SSD is not 
identical in size to the old spinners.

Andrei supports file-level copying, so I'll stick to that.

Joe supports the idea of adding the drive to the RAID, but makes no 
reference to dealing wth the size difference.

Alex highlights the downside of size difference.

David and Sarunas suggests doing a system reinstall on the SSD, leaving 
my data on the RAID. Whilst a useful upgrade, I don't really understand 
how that addresses my problem. (if I have one!)

Michael and Deloptes poo-poo that suggestion, with which I concur.

Andy suggests that I should continue using RAID, instead of reverting to 
a single disk. Thank you very much for this helpful suggestion, I 
considered it originally, but abandoned it on cost grounds. When I 
originally built this system with RAID, 10 years ago, I was very reliant 
on data integrity. I now no longer have such a pressing need, and am 
quite happy to rely on a single disk, with nightly rsync backups to an 
off-site server. I certainly have no need for the always-on data that 
RAID provides.

Finally, Geoff supports Andy's suggestion, and in addition, 
interestingly,  mentions NVME to replace SATA SSD. Attractive, but costly.

So, you have all given me plenty to think about, for which I'm grateful.
I guess I'll go with s single SSD onto which I'll copy the data from the 
RAID.
Thank you all for helping me make up my mind.

-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [prev] | [next] | [standalone]

#219773

On Wed, 4 Mar 2020, Tony van der Hoff wrote:

>> On Monday 02 March 2020 06:28:58 Tony van der Hoff wrote:
>> 
>>> Hi,
>>> I'm currently running Buster on a 5 year old GigaByte motherboard with
>>> a 10-year old Raid-1 array on 2 500GB disks. Although it is running
>>> fine, I'm becoming a bit concerned about the longevity of this
>>> storage, so I'm planning to upgrade it to a 500GB or maybe 1TB SSD
>>> from Crucial.
>>> 
>>> My plan would be to install the SSD in the cage, and dd the contents
>>> of the array onto the SSD. I would then change the BIOS to boot from
>>> the SSD, making the RAID array redundant.
>>> 
>>> Can someone please tell me whether this plan is feasible, and what
>>> pitfalls I might encounter?
>>> 
>
> Thanks to all who replied.
>
> Gene didn't address my problem, but made the very useful observation that 
> disks spinning 24/7 don't really die. Perhaps I shouldn't worry about 
> replacing them.
>
> Dan gave a useful step-by-step procedure for copying at file level. This 
> method is slightly problematical for me as it includes "make changes to new 
> /etc/fstab" and "make changes to bootloader to set new root filesystem", 
> neither of which I feel feel comfortable with, due to lack of knowledge. I'll 
> certainly abandon my plan to dd the whole filesystem.
>
> Basti and Deloptes propose to add the SSD as a third drive to the RAID. Very 
> attractive, but would involve complications if the SSD is not identical in 
> size to the old spinners.
>
> Andrei supports file-level copying, so I'll stick to that.
>
> Joe supports the idea of adding the drive to the RAID, but makes no reference 
> to dealing wth the size difference.
>
> Alex highlights the downside of size difference.
>
> David and Sarunas suggests doing a system reinstall on the SSD, leaving my 
> data on the RAID. Whilst a useful upgrade, I don't really understand how that 
> addresses my problem. (if I have one!)
>
> Michael and Deloptes poo-poo that suggestion, with which I concur.
>
> Andy suggests that I should continue using RAID, instead of reverting to a 
> single disk. Thank you very much for this helpful suggestion, I considered it 
> originally, but abandoned it on cost grounds. When I originally built this 
> system with RAID, 10 years ago, I was very reliant on data integrity. I now 
> no longer have such a pressing need, and am quite happy to rely on a single 
> disk, with nightly rsync backups to an off-site server. I certainly have no 
> need for the always-on data that RAID provides.
>
> Finally, Geoff supports Andy's suggestion, and in addition, interestingly, 
> mentions NVME to replace SATA SSD. Attractive, but costly.
>
> So, you have all given me plenty to think about, for which I'm grateful.
> I guess I'll go with s single SSD onto which I'll copy the data from the 
> RAID.
> Thank you all for helping me make up my mind.
>

if new drive is the same size or larger
install new drive
boot using usb drive, i use systemrescuecd
dd if=old_drive of=new_drive

[toc] | [prev] | [next] | [standalone]

#219779

On Wed, Mar 04, 2020 at 02:47:47PM +0000, Tony van der Hoff wrote:
>Gene didn't address my problem, but made the very useful observation 
>that disks spinning 24/7 don't really die. Perhaps I shouldn't worry 
>about replacing them.

the speed advantages are such that I try to avoid spinning disks for OSs
wherever possible these days since the costs for SSDs have gotten so 
low. 

>Andrei supports file-level copying, so I'll stick to that.

Yes, this is generally how I'd proceed. rsync existing filesystem onto 
the new one, bind mount /dev /proc and /sys to the new filesystem, then 
chroot into it, edit fstab on the new filesystem to point to the new 
root (I'd personally use the UUID) run grub-install to put the 
bootloader on the new disk, and then run update-grub. There are other 
approaches to setting up the bootloader as well. It's best to do all 
this in single user mode to avoid files changing while you're copying. 
Then you'll want to change the bios settings to boot off the ssd first 
rather than the hard drives.

[toc] | [prev] | [next] | [standalone]

#219795

[Multipart message — attachments visible in raw view] — view raw

* On 2020 04 Mar 10:02 -0600, Michael Stone wrote:
> On Wed, Mar 04, 2020 at 02:47:47PM +0000, Tony van der Hoff wrote:
> > Gene didn't address my problem, but made the very useful observation
> > that disks spinning 24/7 don't really die. Perhaps I shouldn't worry
> > about replacing them.
> 
> the speed advantages are such that I try to avoid spinning disks for OSs
> wherever possible these days since the costs for SSDs have gotten so low.

This.

I updated two desktops last week from spinning rust to SSDs, including
this machine, and the speed increase, lack of noise, much lower heat
inside the case, and now much lower price point makes the upgrade a no
brainer.

> > Andrei supports file-level copying, so I'll stick to that.
> 
> Yes, this is generally how I'd proceed. rsync existing filesystem onto the
> new one, bind mount /dev /proc and /sys to the new filesystem, then chroot
> into it, edit fstab on the new filesystem to point to the new root (I'd
> personally use the UUID) run grub-install to put the bootloader on the new
> disk, and then run update-grub. There are other approaches to setting up the
> bootloader as well. It's best to do all this in single user mode to avoid
> files changing while you're copying. Then you'll want to change the bios
> settings to boot off the ssd first rather than the hard drives.

I like rsync for this.  In the olde days I often updated over the LAN to
copy data from a laptop to a desktop and back to the laptop's new drive.
Years ago I bought a 500 GB USB drive that saved that step.  As rsync
gives compression with the '-z' option, doing so over the network was
tolerable.

I had to do a bit more dancing on this machine where I use secure boot
with UEFI.  I followed the steps from:

	https://wiki.debian.org/GrubEFIReinstall 
	
including putting the suggested Refind image on a thumb drive and
booting to it after disabling secure boot but via EFI.  That was easy,
the next day I updated the BIOS which erased all of the user keys so I
had to do those steps over and ensure the Grub key was in NVRAM along
with the key I use to sign the Virtualbox kernel modules.

It was a learning experience!

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#219793

On Wednesday, March 04, 2020 09:47:47 AM Tony van der Hoff wrote:
> Gene didn't address my problem, but made the very useful observation
> that disks spinning 24/7 don't really die. Perhaps I shouldn't worry
> about replacing them.

I wouldn't count on that, for two reasons:

   * everything mechanical wears, and eventually wears out (well, maybe not if 
the bearings are a magnetic suspension type) (no moving parts in contact)

   * I suspect most of us don't know whether our disks are spinning 24/7 -- 
some of my computers are up 24/7, but I suspect the disks "spin down" when 
unused for some period of time

[toc] | [prev] | [next] | [standalone]

#219794

rhkramer@gmail.com wrote: 
> On Wednesday, March 04, 2020 09:47:47 AM Tony van der Hoff wrote:
> > Gene didn't address my problem, but made the very useful observation
> > that disks spinning 24/7 don't really die. Perhaps I shouldn't worry
> > about replacing them.
> 
> I wouldn't count on that, for two reasons:
> 
>    * everything mechanical wears, and eventually wears out (well, maybe not if 
> the bearings are a magnetic suspension type) (no moving parts in contact)
> 
>    * I suspect most of us don't know whether our disks are spinning 24/7 -- 
> some of my computers are up 24/7, but I suspect the disks "spin down" when 
> unused for some period of time

Some do, some don't. Drives sold as "laptop" or "green" drives
are more likely to do so by themselves.

There used to be (still?) a set of Western Digital drives that
would go into a hard sleep and park their heads repeatedly. This 
tended to cause a shortened lifespan as well as terrible
performance.

-dsr-

[toc] | [prev] | [next] | [standalone]

#219804

On 3/4/20, Dan Ritter <dsr@randomstring.org> wrote:
> rhkramer@gmail.com wrote:
>> some of my computers are up 24/7, but I suspect the disks "spin down" when
>>
>> unused for some period of time
>
> Some do, some don't. Drives sold as "laptop" or "green" drives
> are more likely to do so by themselves.
>
> There used to be (still?) a set of Western Digital drives that
> would go into a hard sleep and park their heads repeatedly. This
> tended to cause a shortened lifespan as well as terrible
> performance.


I remember seeing AND possibly sharing here on Debian-User about a
BIOS setting that let the User decide whether to let disks like that
make that decision on their own..

SOMETHING like that, anyway.. My Dell PC power supply started working
again.. and then finally fritzed for good so I can't go in to check
exactly what it said. I THINK that's the computer that had that
CHOICE.. Dell XPS.... 420.... grin.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#219821

> There used to be (still?) a set of Western Digital drives that
> would go into a hard sleep and park their heads repeatedly. This 
> tended to cause a shortened lifespan as well as terrible
> performance.
> 
> -dsr-
> 
with cron:
# prevent disks from sleeping, every minute:
* *     *  *    *  /bin/touch /dev/sda &>/    

[toc] | [prev] | [next] | [standalone]

#219823

007@caiway.net wrote:
> with cron:
> # prevent disks from sleeping, every minute:
> * *     *  *    *  /bin/touch /dev/sda &>/    

Wha not using "hdparm"?

Regards,
	Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

[toc] | [prev] | [next] | [standalone]

#219846

On Thu 05 Mar 2020 at 08:26:58 (+0100), Klaus Singvogel wrote:
> 007@caiway.net wrote:
> > with cron:
> > # prevent disks from sleeping, every minute:
> > * *     *  *    *  /bin/touch /dev/sda &>/    
> 
> Wha not using "hdparm"?

Would you be more specific and include the options you are suggesting.
There are over 60 available, some dangerous.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#219848

On Thu, 2020-03-05 at 11:18 -0600, David Wright wrote:
> On Thu 05 Mar 2020 at 08:26:58 (+0100), Klaus Singvogel wrote:
> > 007@caiway.net wrote:
> > > with cron:
> > > # prevent disks from sleeping, every minute:
> > > * *     *  *    *  /bin/touch /dev/sda &>/    
> > 
> > Wha not using "hdparm"?
> 
> Would you be more specific and include the options you are
> suggesting.
> There are over 60 available, some dangerous.
> 

I'm assuming he means -S which sets the standby (spindown) time‐out for
the drive. I use it to force my NAS drives to spin down so the noise
doesn't annoy me. But a timeout of zero will disable spindown.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#219854

David Wright wrote:
> > Wha not using "hdparm"?
> 
> Would you be more specific and include the options you are suggesting.
> There are over 60 available, some dangerous.

I don't use hdparm anymore and can't memorize.
But I'd gone to Google, and they tell me: "hdparm -I /dev/sdX -S 0"

Regards,
	Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

[toc] | [prev] | [next] | [standalone]

#219813

On Wed, Mar 04, 2020 at 06:39:51PM -0500, Gene Heskett wrote:
>On Wednesday 04 March 2020 12:48:57 rhkramer@gmail.com wrote:
>>    * I suspect most of us don't know whether our disks are spinning
>> 24/7 -- some of my computers are up 24/7, but I suspect the disks
>> "spin down" when unused for some period of time
>
>Would that not be logged as an access error, followed by a reset/restart
>in the logs?  At the very minimum it should be logged so that the user
>can know the drive is doing that.

no, not unless something is horribly broken

[toc] | [prev] | [next] | [standalone]

#219815

On Wednesday 04 March 2020 18:49:06 Michael Stone wrote:

> On Wed, Mar 04, 2020 at 06:39:51PM -0500, Gene Heskett wrote:
> >On Wednesday 04 March 2020 12:48:57 rhkramer@gmail.com wrote:
> >>    * I suspect most of us don't know whether our disks are spinning
> >> 24/7 -- some of my computers are up 24/7, but I suspect the disks
> >> "spin down" when unused for some period of time
> >
> >Would that not be logged as an access error, followed by a
> > reset/restart in the logs?  At the very minimum it should be logged
> > so that the user can know the drive is doing that.
>
> no, not unless something is horribly broken

That is lieing to the user, and not nice at all.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#219818

On Wed, Mar 04, 2020 at 06:53:12PM -0500, Gene Heskett wrote:
>On Wednesday 04 March 2020 18:49:06 Michael Stone wrote:
>
>> On Wed, Mar 04, 2020 at 06:39:51PM -0500, Gene Heskett wrote:
>> >On Wednesday 04 March 2020 12:48:57 rhkramer@gmail.com wrote:
>> >>    * I suspect most of us don't know whether our disks are spinning
>> >> 24/7 -- some of my computers are up 24/7, but I suspect the disks
>> >> "spin down" when unused for some period of time
>> >
>> >Would that not be logged as an access error, followed by a
>> > reset/restart in the logs?  At the very minimum it should be logged
>> > so that the user can know the drive is doing that.
>>
>> no, not unless something is horribly broken
>
>That is lieing to the user, and not nice at all.

Why on earth would you expect an error? That's just nuts.

[toc] | [prev] | [next] | [standalone]

#219819

On Wednesday 04 March 2020 22:26:34 Michael Stone wrote:

> On Wed, Mar 04, 2020 at 06:53:12PM -0500, Gene Heskett wrote:
> >On Wednesday 04 March 2020 18:49:06 Michael Stone wrote:
> >> On Wed, Mar 04, 2020 at 06:39:51PM -0500, Gene Heskett wrote:
> >> >On Wednesday 04 March 2020 12:48:57 rhkramer@gmail.com wrote:
> >> >>    * I suspect most of us don't know whether our disks are
> >> >> spinning 24/7 -- some of my computers are up 24/7, but I suspect
> >> >> the disks "spin down" when unused for some period of time
> >> >
> >> >Would that not be logged as an access error, followed by a
> >> > reset/restart in the logs?  At the very minimum it should be
> >> > logged so that the user can know the drive is doing that.
> >>
> >> no, not unless something is horribly broken
> >
> >That is lieing to the user, and not nice at all.
>
> Why on earth would you expect an error? That's just nuts.

No its not. If the disk is asked for data from such and such a sector in 
order to issue a stop command to a machine, IMO it has its seek time + 1 
revolution to get that data under a head and read. If its spun down then 
it will have to also spin the drive up which may take 2 or 3 seconds.  
That IMNSHO is a huge error that in some scenarios, could get somebody 
maimed or killed.

So we'll have to agree to disagree.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#219828

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 04, 2020 at 06:53:12PM -0500, Gene Heskett wrote:

[...]

> That is lieing to the user, and not nice at all.

Disable your caches! now!

What? Your computer is just 1/3 as fast as it used to be?

Computing is about lying -- and trying to not get caught.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#219838

On Thursday, March 05, 2020 03:27:09 AM tomas@tuxteam.de wrote:
> On Wed, Mar 04, 2020 at 06:53:12PM -0500, Gene Heskett wrote:
> 
> [...]
> 
> > That is lieing to the user, and not nice at all.
> 
> Disable your caches! now!
> 
> What? Your computer is just 1/3 as fast as it used to be?
> 
> Computing is about lying -- and trying to not get caught.

Not always, or not in this respect.  There are applications where, in essence, 
a real time kernel is (leading to quick responses to real world events or 
similar are) necessary, sometimes for the protection of life or limb (as Gene 
has alluded to).

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web