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 2 of 2 — ← Prev page 1 [2]

#219860

On Thu, Mar 05, 2020 at 10:11:55AM -0500, rhkramer@gmail.com wrote:
>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).

nice red herring, but those aren't going to be dependent on a commodity 
hard drive unless someone really screwed up.

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

#219869

On Thursday, March 05, 2020 01:56:27 PM Michael Stone wrote:
> On Thu, Mar 05, 2020 at 10:11:55AM -0500, rhkramer@gmail.com wrote:
> >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).
> 
> nice red herring, but those aren't going to be dependent on a commodity
> hard drive unless someone really screwed up.

What kind of hard drive would it use?  

Was this discussion limited to commodity hard drives?

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

#219814

On Wednesday 04 March 2020 12:48:57 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

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.

The other item that would look identical in the logs is a hot red sata 
drive cable that is failing, which a hot red cable will do, often before 
5 years has elapsed. That particular dye has been known to be a problem 
child since CB radios were imported from the J.A.Pan Company in the 
early 1970's.

The red wire in the microphone cables was always the first to fail.  You 
could pour the copper out of the cut off end of the red wire as a rust 
colored powder.  No matter how much of it you cut off looking for good 
copper to resolder a good connection.  That same plastic dye is still 
destroying hot red sata drive cables. Test by moving the middle of the 
cable while the machine is running with a tail on the log.  If the log 
blows up, replace that cable, preferably with a different color.

In any event I would be watching such a disk with an eye toward 
warrantying it before the warranty expires if a smartctl command to 
disable that "feature" is not available or effective at stopping such 
drive killing non-sense. I understand that W.D. Greens do that so have 
never considered them for purchase.

Do I miss-understand their advertising?

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]

#219817

On 2020-03-04 06:47, Tony van der Hoff wrote:
> I guess I'll go with s single SSD onto which I'll copy the data from the 
> RAID.

I would advise disconnecting the RAID, doing a fresh install onto the 
SSD, updating and configuring to suit, reconnecting the RAID, and then 
copying data.


Be sure to backup, archive, and image at key points before, during, and 
after the conversion.


> Thank you all for helping me make up my mind.

YW.  :-)


David

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

#219715

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?
> 

I would recommend:

- install SSD
- partition SSD, aligning partitions with new block sizes
- create filesystems in SSD partitions
- copy over filesystems with rsync
- make changes to new /etc/fstab
- make changes to bootloader to set new root filesystem
- shut down machine
- disconnect old disks
- start machine, make BIOS changes if necessary
- boot
- test for functionality

file-level copying is better than block-level copying when going
between drives of different technologies.

-dsr-

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

#219717

On 02.03.20 16:39, Dan Ritter wrote:
> 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?
>>
> 
> I would recommend:
> 
> - install SSD
> - partition SSD, aligning partitions with new block sizes
> - create filesystems in SSD partitions
> - copy over filesystems with rsync
> - make changes to new /etc/fstab
> - make changes to bootloader to set new root filesystem
> - shut down machine
> - disconnect old disks
> - start machine, make BIOS changes if necessary
> - boot
> - test for functionality
> 
> file-level copying is better than block-level copying when going
> between drives of different technologies.
> 
> -dsr-
> 

Why you do not simply prepare the SSD (partition/align) and after that
add the SSD as 3rd drive to the raid?

When all is synced you can kick off the HDD's or that them to "Write
mostly".

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

#219725

basti wrote:

> Why you do not simply prepare the SSD (partition/align) and after that
> add the SSD as 3rd drive to the raid?
> 
> When all is synced you can kick off the HDD's or that them to "Write
> mostly".

+1

However partitioning is still required, but the best way to copy the data is
to use the built in sync mechanism of linux raid.

I am just about to replace 2x1TB WD Green against 2x1TB WD Red using this
procedure, because the Green is very slow compared to the Red. 

Age is also a point, but as mentioned by Gene when running 24/7 its almost
forever. I think those Green disks are already 10y/o

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

#219738

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

On Lu, 02 mar 20, 10:39:11, Dan Ritter wrote:
> 
> file-level copying is better than block-level copying when going
> between drives of different technologies.

+1 on this.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#219721

Tony van der Hoff <lists@vanderhoff.org> writes:

> 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?

I've found the best way to migrate to new disks, especially if I've
already got a RAID array, is to put the new disk in, add it to the
array, wait for the array to synchronize, remove the old disks from
array.  Now install grub on the new disk.  If the new disk is larger
than the old ones were, now resize the filesystem to match.

This has worked well enough for me that I've got several one-disk RAID 1
arrays in anticipation of eventual upgrades.

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

#219729

On 3/2/20 6:52 PM, Joe Pfeiffer wrote:
> Tony van der Hoff <lists@vanderhoff.org> writes:
> 
>> 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?
> 
> I've found the best way to migrate to new disks, especially if I've
> already got a RAID array, is to put the new disk in, add it to the
> array, wait for the array to synchronize, remove the old disks from
> array.  Now install grub on the new disk.  If the new disk is larger
> than the old ones were, now resize the filesystem to match.
> 
> This has worked well enough for me that I've got several one-disk RAID 1
> arrays in anticipation of eventual upgrades.
> 

Good idea, but most likely the 500GB SSD is not really 500GB as most
vendors leave some space for over provisioning area.

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

#219726

On 2020-03-02 03:28, 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

I would suggest doing a fresh install onto a single, fast SSD, keeping 
the system image and your home directory small, and leaving the bulk of 
your data the 500 GB mirror.  Backup, archive, and image religiously 
(especially before you start on this adventure).


David

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

#219727

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

On 3/2/20 2:19 PM, David Christensen wrote:
> On 2020-03-02 03:28, 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
> 
> I would suggest doing a fresh install onto a single, fast SSD, keeping
> the system image and your home directory small, and leaving the bulk of
> your data the 500 GB mirror.  Backup, archive, and image religiously
> (especially before you start on this adventure).

+1. Nothing like a fresh install.

-- 
Sarunas Burdulis
Systems Administrator, Dartmouth Mathematics
math.dartmouth.edu/~sarunas

· https://useplaintext.email ·

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

#219728

On Mon, Mar 02, 2020 at 02:22:45PM -0500, Sarunas Burdulis wrote:
>On 3/2/20 2:19 PM, David Christensen wrote:
>> On 2020-03-02 03:28, 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
>>
>> I would suggest doing a fresh install onto a single, fast SSD, keeping
>> the system image and your home directory small, and leaving the bulk of
>> your data the 500 GB mirror.  Backup, archive, and image religiously
>> (especially before you start on this adventure).
>
>+1. Nothing like a fresh install.

-1, unecessary busy work

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

#219731

Michael Stone wrote:

> -1, unecessary busy work

+(-1) configurations grown during the years broken - hard to restore

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

#219733

Hi Tony,

On Mon, Mar 02, 2020 at 11:28:58AM +0000, Tony van der Hoff wrote:
> 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.

Just as you have two HDDs in a RAID array for redundancy, you should
not rely on a single SSD.

If you cannot afford two SSDs then I second the suggestion to
replace one of the HDDs with the SSD and set the HDD write-mostly.

Do also check the exact sector counts as it is entirely possible
that a "500GB" SSD is actually slightly smaller than your "500GB" HDDs.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#219742

Andy Smith wrote:

> 
> Just as you have two HDDs in a RAID array for redundancy, you should
> not rely on a single SSD.
> 
> If you cannot afford two SSDs then I second the suggestion to
> replace one of the HDDs with the SSD and set the HDD write-mostly.
> 
> Do also check the exact sector counts as it is entirely possible
> that a "500GB" SSD is actually slightly smaller than your "500GB" HDDs.
> 
> Cheers,
> Andy
> 

I did exactly this, though I replaced a 1TB disk with a 2TB sata SSD to avoid that problem, and at some point I'll replace the remaining disk with an nvme drive now that I've replaced the MB, then I'll grow the filesystems to fit.

Regards,
Geoff

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web