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

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

From SSD to NVME

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

Contents

  From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 17:50 +0100
    Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-02 18:00 +0100
      Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 18:10 +0100
    Re: From SSD to NVME Bret Busby <bret@busby.net> - 2024-12-02 18:50 +0100
      Re: *****SPAM***** Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 20:30 +0100
      Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-02 21:30 +0100
    Re: From SSD to NVME basti <mailinglist@unix-solution.de> - 2024-12-02 19:40 +0100
      Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 20:20 +0100
        Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 00:20 +0100
          Re: From SSD to NVME eben@gmx.us - 2024-12-05 15:50 +0100
            Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 16:10 +0100
              Re: From SSD to NVME eben@gmx.us - 2024-12-05 17:00 +0100
                Re: From SSD to NVME Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-05 17:20 +0100
                  Re: From SSD to NVME Dan Ritter <dsr@randomstring.org> - 2024-12-05 18:00 +0100
                    Re: From SSD to NVME Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-05 18:20 +0100
                    Re: From SSD to NVME Chris Green <cl@isbd.net> - 2024-12-05 18:50 +0100
                      Re: From SSD to NVME Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-05 20:50 +0100
                      Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 21:00 +0100
                    Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-05 20:30 +0100
                      MBR to GPT + UEFI (was: From SSD to NVME) Jeffrey Walton <noloader@gmail.com> - 2024-12-05 20:40 +0100
                      Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-05 21:10 +0100
                        Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-05 21:30 +0100
                        Re: From SSD to NVME David Wright <deblis@lionunicorn.co.uk> - 2024-12-05 22:20 +0100
                          Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-05 23:10 +0100
                            Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 23:40 +0100
                            Re: From SSD to NVME Charles Curley <charlescurley@charlescurley.com> - 2024-12-05 23:40 +0100
                              Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-06 19:20 +0100
                                Re: From SSD to NVME Charles Curley <charlescurley@charlescurley.com> - 2024-12-06 20:00 +0100
                            Re: From SSD to NVME David Wright <deblis@lionunicorn.co.uk> - 2024-12-06 01:50 +0100
                      Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 21:20 +0100
                      Re: From SSD to NVME pocket@homemail.com - 2024-12-05 22:20 +0100
                        Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 22:30 +0100
                          Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-05 22:30 +0100
                            Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 22:40 +0100
                              Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-05 23:10 +0100
                      Re: From SSD to NVME David Wright <deblis@lionunicorn.co.uk> - 2024-12-05 22:20 +0100
                Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 19:10 +0100
                  Re: From SSD to NVME eben@gmx.us - 2024-12-05 22:10 +0100
                    Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 23:30 +0100
                      Re: From SSD to NVME eben@gmx.us - 2024-12-06 00:10 +0100
                  Re: From SSD to NVME Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-12-11 09:00 +0100
                    Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-11 14:20 +0100
                      Re: From SSD to NVME Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-12-12 22:20 +0100
                    Re: From SSD to NVME Dan Ritter <dsr@randomstring.org> - 2024-12-11 14:30 +0100
                      Re: From SSD to NVME Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-12-12 20:20 +0100
    Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-02 19:50 +0100
    Re: From SSD to NVME Bruno Schneider <boschneider@gmail.com> - 2024-12-02 19:50 +0100
      Re: From SSD to NVME Erwan David <erwan@rail.eu.org> - 2024-12-02 20:20 +0100
        Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 20:30 +0100
          Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-02 21:20 +0100
            Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 21:50 +0100
              Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-02 22:30 +0100
                Re: From SSD to NVME <tomas@tuxteam.de> - 2024-12-03 06:40 +0100
          Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-02 21:40 +0100
      Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 16:50 +0100
        Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 18:30 +0100
          Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 19:20 +0100
            Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 20:20 +0100
              Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 21:00 +0100
                Re: From SSD to NVME Felix Miata <mrmazda@earthlink.net> - 2024-12-05 22:20 +0100
                  Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 23:00 +0100
                    Re: From SSD to NVME - oops! Felix Miata <mrmazda@stanis.net> - 2024-12-06 00:00 +0100
                      Re: From SSD to NVME - oops! Max Nikulin <manikulin@gmail.com> - 2024-12-06 04:40 +0100
                    Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-06 00:00 +0100
                      Re: From SSD to NVME Jeffrey Walton <noloader@gmail.com> - 2024-12-06 04:20 +0100
    Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-02 20:50 +0100
      Re: From SSD to NVME pocket@homemail.com - 2024-12-03 03:00 +0100
        Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-03 10:00 +0100
          Re: From SSD to NVME pocket@homemail.com - 2024-12-03 12:10 +0100
            Re: From SSD to NVME <tomas@tuxteam.de> - 2024-12-03 12:40 +0100
            Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 13:20 +0100
              Re: From SSD to NVME pocket@homemail.com - 2024-12-03 13:40 +0100
                Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-03 14:00 +0100
                  Re: From SSD to NVME pocket@homemail.com - 2024-12-03 14:10 +0100
                    Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-03 14:30 +0100
                      Re: From SSD to NVME pocket@homemail.com - 2024-12-03 15:30 +0100
                        Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-03 16:00 +0100
              Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 15:50 +0100
                Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 20:40 +0100
                  Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-03 20:50 +0100
                    Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 21:40 +0100
                      Re: From SSD to NVME pocket@homemail.com - 2024-12-03 22:20 +0100
                        Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 22:30 +0100
                          Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:00 +0100
                            Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 23:10 +0100
                              Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:20 +0100
                        Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 22:40 +0100
                          Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:00 +0100
                            Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 23:20 +0100
                              Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:30 +0100
                                Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 23:50 +0100
                      Re: From SSD to NVME Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2024-12-04 02:40 +0100
                        Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-04 05:20 +0100
                          Re: From SSD to NVME pocket@homemail.com - 2024-12-04 13:10 +0100
                            Re: From SSD to NVME Joe <joe@jretrading.com> - 2024-12-04 16:00 +0100
                              Re: From SSD to NVME pocket@homemail.com - 2024-12-04 19:00 +0100
                        Re: From SSD to NVME Jeffrey Walton <noloader@gmail.com> - 2024-12-04 07:20 +0100
                  Re: From SSD to NVME gene heskett <gheskett@shentel.net> - 2024-12-05 01:10 +0100
                    Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-05 01:40 +0100
                      Re: From SSD to NVME gene heskett <gheskett@shentel.net> - 2024-12-05 03:00 +0100
            Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 15:30 +0100
              Re: From SSD to NVME pocket@homemail.com - 2024-12-03 15:50 +0100
                Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 16:10 +0100
                  Re: From SSD to NVME pocket@homemail.com - 2024-12-03 16:30 +0100
                    Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 00:00 +0100
            Re: From SSD to NVME Steve McIntyre <steve@einval.com> - 2024-12-03 22:20 +0100
    Re: From SSD to NVME Max Nikulin <manikulin@gmail.com> - 2024-12-03 04:10 +0100
    Re: From SSD to NVME David Christensen <dpchrist@holgerdanske.com> - 2024-12-03 05:50 +0100

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#275135 — From SSD to NVME

Hi folks,

as my old notebook died, I ntend to buy a new notebook.
The old one has got a SSD drive, the new one an NVME.

I want to clone the whole system 1 to 1 to the new NVME.
 
In my /etc/fstab I am using UUID entries instead of /dev/sdX.
The new one then would have /dev/nvme* as entries (that is clear), but if I am 
using only UUID, the question:

Will the UUID change at clone, even when the partitions are not changed in a 
bit of size? IMHO the UUID will not change, but I am not quite sure.

When cloning from SSD to SSD this is working, but I have no experience when 
cloning from SSD to NVME. 

Thanks for a short feedback.

Best 

Hans

      

[toc] | [next] | [standalone]

#275137

On Mon, Dec 02, 2024 at 17:49:18 +0100, Hans wrote:
> I want to clone the whole system 1 to 1 to the new NVME.
>  
> Will the UUID change at clone, even when the partitions are not changed in a 
> bit of size? IMHO the UUID will not change, but I am not quite sure.

Depends on what you mean by "clone".  If you mean a bit-for-bit copy
using dd or an equivalent, then you're correct.  The file system UUID
will be copied along with all the other bits of the old file system.

If you mean "create a new file system on the new drive, then rsync
the files over", then the file system UUID will not be the same.  Unless
of course you specifically go out of your way to copy the UUID as well.

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

#275140

Hi Greg,
> Depends on what you mean by "clone".  If you mean a bit-for-bit copy
> using dd or an equivalent, then you're correct.  The file system UUID
> will be copied along with all the other bits of the old file system.
I mean clone bit by bit. The software I am using is "Clonezilla" which depends 
on partclone and dd.

> 
> If you mean "create a new file system on the new drive, then rsync
> the files over", then the file system UUID will not be the same.  Unless
> of course you specifically go out of your way to copy the UUID as well.
No, not rsync. This would be an option, but only if the above method is 
failing (i.e. target drive is smaller than source drive).

Hans

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

#275142

On 3/12/24 00:49, Hans wrote:
> Hi folks,
> 
> as my old notebook died, I ntend to buy a new notebook.
> The old one has got a SSD drive, the new one an NVME.
> 
> I want to clone the whole system 1 to 1 to the new NVME.
>   
> In my /etc/fstab I am using UUID entries instead of /dev/sdX.
> The new one then would have /dev/nvme* as entries (that is clear), but if I am
> using only UUID, the question:
> 
> Will the UUID change at clone, even when the partitions are not changed in a
> bit of size? IMHO the UUID will not change, but I am not quite sure.
> 
> When cloning from SSD to SSD this is working, but I have no experience when
> cloning from SSD to NVME.
> 
> Thanks for a short feedback.
> 
> Best
> 
> Hans
> 

If you simply clone the system from one hardware system to another, are 
you confident that it will work?

I expect that the two different hardware systems would require separate 
sets of drivers and configurations for those drivers.

Also, depending on the operating system and packages versions, you could 
end up with a frankenstein system.

Will the two primary drives be the same, in terms of total hard drive 
capacity, partition sizes and formatted/usable capacities?

Will the UEFI partitions on each system, be compatible?

It seems to me, to be making a mess.

I believe (and, I am no expert, and, this list will have much more 
knowledgeable people than me, available) that it would be simpler, to 
install the latest versions and packages of whatever you have/had on 
your older system, on your new system, and, then create your partitions, 
and copy data to corresponding partitions.

What you are intending to do, reminds me of a movie that I once watched, 
named Pet Semetary (sic).

..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............

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

#275150 — Re: *****SPAM***** Re: From SSD to NVME

> If you simply clone the system from one hardware system to another, are
> you confident that it will work?
Yes.
> 
> I expect that the two different hardware systems would require separate
> sets of drivers and configurations for those drivers.
Nope, kernel knows.
> Also, depending on the operating system and packages versions, you could
> end up with a frankenstein system.
> 
> Will the two primary drives be the same, in terms of total hard drive
> capacity, partition sizes and formatted/usable capacities?
> 
Yes, they will. But it is sensefull to resize the partitions for your needs 
(using gparted), as the newer harddrive is mostly bigger than the old one. 
This works without data loss.

> Will the UEFI partitions on each system, be compatible?
> 

Yes.
> It seems to me, to be making a mess.
> 
Nope, if you make it correctly: 
1. Clone 
2. Gparted resize partitions to your needs.
3. Use resize2fs with all partitions.

Workas also with a combination of Windows and Linux (I also have Windows on my 
harddrive, and Linux (multi partitions, some of then encrypted).

> I believe (and, I am no expert, and, this list will have much more
> knowledgeable people than me, available) that it would be simpler, to
> install the latest versions and packages of whatever you have/had on
> your older system, on your new system, and, then create your partitions,
> and copy data to corresponding partitions.
> 
> What you are intending to do, reminds me of a movie that I once watched,
> named Pet Semetary (sic).
> 
> ..
> Bret Busby
> Armadale
> West Australia
> (UTC+0800)
> ..............

Best 

Hans

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

#275155

Hi,

On Tue, Dec 03, 2024 at 01:49:12AM +0800, Bret Busby wrote:
> If you simply clone the system from one hardware system to another, are you
> confident that it will work?

You clearly aren't, but I think Hans should be, yes.

Worst cxase is that Hans ends up with something that doesn't boot, but
Hans would still have the thing that boots, so this is pretty low risk.

> I expect that the two different hardware systems would require separate sets
> of drivers and configurations for those drivers.

Sure. But There is only one NVMe driver in Linux and it will be baked in
to any recent kernel. Hans would have had top go out of their way to make
a custom kernel that won't work.

The other potential stumbling block is that sometimes a system's legacy
BIOS can't boot off of NVMe while its UEFI can. That's entirely outside
the world of Linux though.

> Also, depending on the operating system and packages versions, you could end
> up with a frankenstein system.

There is no mention in Hans's email of different versions of Debian
being involved here.

> Will the two primary drives be the same, in terms of total hard drive
> capacity, partition sizes and formatted/usable capacities?
> 
> Will the UEFI partitions on each system, be compatible?

None of that matters. If it boots now, it will boot afterwards as long
as the machine supports booting off of NVMe and the kernel has the drivers.

> I believe (and, I am no expert, and, this list will have much more
> knowledgeable people than me, available) that it would be simpler, to
> install the latest versions and packages of whatever you have/had on your
> older system, on your new system, and, then create your partitions, and copy
> data to corresponding partitions.

Huge waste of time I'm afraid.

> What you are intending to do, reminds me of a movie that I once watched,
> named Pet Semetary (sic).

Changing a storage drive reminds you of a horror movie? Okay, it may be
time to put the Internet away…

Thanks,
Andy

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

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

#275145

Am 02.12.24 um 17:49 schrieb Hans:
> Hi folks,
> 
> as my old notebook died, I ntend to buy a new notebook.
> The old one has got a SSD drive, the new one an NVME.
> 
> I want to clone the whole system 1 to 1 to the new NVME.
>   
> In my /etc/fstab I am using UUID entries instead of /dev/sdX.
> The new one then would have /dev/nvme* as entries (that is clear), but if I am
> using only UUID, the question:
> 
> Will the UUID change at clone, even when the partitions are not changed in a
> bit of size? IMHO the UUID will not change, but I am not quite sure.
> 
> When cloning from SSD to SSD this is working, but I have no experience when
> cloning from SSD to NVME.
> 
> Thanks for a short feedback.
> 
> Best
> 
> Hans
> 
>        
> 
> 

If you have LVM you can create a PV on the NVME and add then to the VG. 
After that move the LV to the new PV and remove the old SSD from the VG.
Don't forget to update the initram.

Best Regards

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

#275149

Thank you all for your response. 

Just to explain: I have only "standard" partitions. One for /boot, /, /usr, 
/var and /home. Most of them are luks encrypted.

This cloning I did often ovetr the years. My debian is rather old (means, first 
install years ago, but it was of course upgraded) and during the years, I 
cloned it from mechanical harddrive to SSD, then to a bigger SSD and so on.

This worked well and without any issues using clonezilla, resizing with 
gparted and resize2fs intelligently.

Although, first it was a change from /dev/hdaX to /dev/sdaX, this was well and 
easlily done until I changed to UUID. Even with this, the cloning worked 
perfectly without any flaws.

But /dev/hda and /dev /sda are very similar, except of the naming scheme.

But I never used NVME drives before and know (shame on me!) not much about it. 
If NVME are only super fast SSD's, then it will be easy, but if NVME are a 
complete alien hardware, then I might come in trouble (Nothing, that can not 
be fixed!).

So I asked here, maybe someone did the already the same, I intend to do and 
could give me some clues.

In the next days I get my new notebook and will report of my success. 

Maybe it will be helpfull for other people, too.

Have fun!

Hans  

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

#275258

On Mon, Dec 02, 2024 at 01:41:18PM -0500, Felix Miata wrote:
>You very likely would need to add drivers to your initrds first, else have to
>rescue boot to rebuild after:

This is probably the result of setting MODULES=dep in 
/etc/initramfs.conf. When changing hardware I'd recommend changing that 
to MODULES=most and then running "update-initramfs -k all -u" to 
regenerate the initramfs with the additional modules. It is possible to 
fix this with a rescue image if one forgets.

On Mon, Dec 02, 2024 at 03:41:43PM -0300, Bruno Schneider wrote:
>On a side note, last time I tried to install Debian on NVME, it
>wouldn't even find the storage device. I hope this has improved since
>then.

I've installed debian on a lot of machines with a lot of NVMe devices, 
and never had an issue. The hardware is pretty standardized, and the 
only thing I can think of which might cause an issue would be something 
like an HMB drive with an older linux that predates support for HMB, or 
a PCIe topology problem (unlikely in consumer hardware). In general I 
would expect normal NVMe to just work. I can think of additional failure 
modes causing inability to boot on older hardware, but the kernel should 
still see the drive.

On Mon, Dec 02, 2024 at 08:14:35PM +0100, Hans wrote:
>But I never used NVME drives before and know (shame on me!) not much about it.
>If NVME are only super fast SSD's, then it will be easy, but if NVME are a
>complete alien hardware, then I might come in trouble (Nothing, that can not
>be fixed!).

Apart from the need for the nvme driver to be in the initrd (just as 
you'd need an ata, scsi, etc module for those devices) it should be 
possible to migrate fairly easily. NVMe works just like SATA SSD from 
the partition level up (i.e., the stuff you'd dd). One somewhat 
different thing is the concept of NVMe namespaces: your drive will be 
/dev/nvme0, but you'll probably be using /dev/nvme0n1 except for device 
management. Partitions then look like /dev/nvme0n1p1. It's unlikely that 
you'd be creating/using additional namespaces apart from the first 
(default) one.

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

#275280

On 12/4/24 18:18, Michael Stone wrote:

> One somewhat different thing is the
> concept of NVMe namespaces: your drive will be /dev/nvme0, but you'll
> probably be using /dev/nvme0n1 except for device management. Partitions then
> look like /dev/nvme0n1p1.

Is it different when you boot from an nvme drive?  I have what I was told
was one and it appears as /dev/sdb or /dev/sda depending how the OS feels
that day.  I didn't buy it new, it was given to me, so I may have been
misinformed.  It's a thing that looks like a SIMM, and when it's plugged in
the motherboard disables one of the SATA ports, which is unfortunate.

eben@cerberus:~$ lsb_release --description
No LSB modules are available.
Description:	Debian GNU/Linux 12 (bookworm)

eben@cerberus:~$ uname -r
6.1.0-27-amd64

eben@cerberus:~$ sudo hdparm -i /dev/sdb

/dev/sdb:

 Model=TOSHIBA KSG60ZMV256G M.2 2280 256GB, FwRev=ABDA4102,
SerialNo=584B8018K5SP
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=500118192
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

eben@cerberus:~$ sudo hdparm -t /dev/sdb

/dev/sdb:
 Timing buffered disk reads: 886 MB in  3.01 seconds = 294.77 MB/sec

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

#275281

On Thu, Dec 05, 2024 at 09:42:08AM -0500, eben@gmx.us wrote:
>Is it different when you boot from an nvme drive?  I have what I was told
>was one and it appears as /dev/sdb or /dev/sda depending how the OS feels
>that day.  I didn't buy it new, it was given to me, so I may have been
>misinformed.  It's a thing that looks like a SIMM, and when it's plugged in
>the motherboard disables one of the SATA ports, which is unfortunate.

That is a SATA SSD, not an NVMe. The same physical form factor (M.2) 
supports either, but a particular drive will be one or the other. The 
SATA drive letters can change based on things like which drive starts up 
faster or what removeable devices are plugged in, which is why using 
UUIDs or somesuch is preferred over using the device name.

(SATA and NVMe are both SSDs, but one accesses the storage via a SATA 
controller and the other appears directly on a PCIe bus. They're 
functionally equivalent in a consumer context, but SATA reached the end 
of the road performance-wise in 2009 while PCIe continues to scale up; 
SATA maxes out at 600MB/s, while PCIe is currently at 4000MB/s per lane, 
with NVMe drives typically using as many as 4 lanes [16000MB/s]. Latency is also 
significantly lower for PCIe. For many [most?] consumer applications the 
differences will not be noticable.)

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

#275286

On 12/5/24 09:59, Michael Stone wrote:
> On Thu, Dec 05, 2024 at 09:42:08AM -0500, eben@gmx.us wrote:
>> Is it different when you boot from an nvme drive?  I have what I was
>> told was one and it appears as /dev/sdb or /dev/sda depending how the
>> OS feels that day.  I didn't buy it new, it was given to me, so I may
>> have been misinformed.  It's a thing that looks like a SIMM, and when
>> it's plugged in the motherboard disables one of the SATA ports, which
>> is unfortunate.
>
> That is a SATA SSD, not an NVMe.

Interesting, thanks.  Apparently either it was misrepresented to me, or I
misremembered.  That explains some stuff.

> The SATA drive letters can change based on things like which drive starts
> up faster or what removeable devices are plugged in, which is why using
> UUIDs or somesuch is preferred over using the device name.

And that probably explains why it's always sdb under a rescue thumb drive,
because that environment doesn't automount _anything_.

> SATA maxes out at 600MB/s, while PCIe is currently at 4000MB/s per lane,
> with NVMe drives typically using as many as 4 lanes [16000MB/s].

How do I tell how many lanes a given drive uses (preferably before purchase)?

> For many [most?] consumer applications the differences will not be
> noticable.)

Yeah, I probably wouldn't be able to tell.  It's just geek points.  I was
thinking it might matter when xferring gigabyte+ files to the media server,
but then the bottleneck would either be the CPU encrypting the SSH data, or
the network itself.

Is one kind more long-lived than the other?

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

#275288

>> That is a SATA SSD, not an NVMe.
> Interesting, thanks.  Apparently either it was misrepresented to me, or I
> misremembered.  That explains some stuff.

The switch from SATA to the NVMe interface/protocol happened basically
at the same time as the switch from the 2.5" (and mini-pcie) to the M.2
format, so it's a common mistake to consider that for an SSD, "M.2 =>
NVMe" (the implication is currently true in the other direction, tho,
AFAIK).

>> For many [most?] consumer applications the differences will not be
>> noticable.)

That's my experience as well.

> Is one kind more long-lived than the other?

As a general rule, no, tho you could argue that by virtue of imposing
slower writes, the SATA interface can lead to a longer lifetime just
because it takes longer to reach the "TBW" limit.  🙂


        Stefan

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

#275289

Stefan Monnier wrote: 
> >> That is a SATA SSD, not an NVMe.
> > Interesting, thanks.  Apparently either it was misrepresented to me, or I
> > misremembered.  That explains some stuff.
> 
> The switch from SATA to the NVMe interface/protocol happened basically
> at the same time as the switch from the 2.5" (and mini-pcie) to the M.2
> format, so it's a common mistake to consider that for an SSD, "M.2 =>
> NVMe" (the implication is currently true in the other direction, tho,
> AFAIK).

Not at all. We have many servers with U.2 and U.3 format disks,
which look like classic 2.5" SSDs but use NVMe PCIe connections.

I suspect there are few desktops (mostly 'workstation' class
machines) and no laptops using U.2.

-dsr-

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

#275290

>> "M.2 => NVMe" (the implication is currently true in the other
>> direction, tho, AFAIK).
> Not at all. We have many servers with U.2 and U.3 format disks,
> which look like classic 2.5" SSDs but use NVMe PCIe connections.

Aha!  Thanks for setting me straight!


        Stefan

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

#275293

Dan Ritter <dsr@randomstring.org> wrote:
> Stefan Monnier wrote: 
> > >> That is a SATA SSD, not an NVMe.
> > > Interesting, thanks.  Apparently either it was misrepresented to me, or I
> > > misremembered.  That explains some stuff.
> > 
> > The switch from SATA to the NVMe interface/protocol happened basically
> > at the same time as the switch from the 2.5" (and mini-pcie) to the M.2
> > format, so it's a common mistake to consider that for an SSD, "M.2 =>
> > NVMe" (the implication is currently true in the other direction, tho,
> > AFAIK).
> 
> Not at all. We have many servers with U.2 and U.3 format disks,
> which look like classic 2.5" SSDs but use NVMe PCIe connections.
> 
> I suspect there are few desktops (mostly 'workstation' class
> machines) and no laptops using U.2.
> 
As I understand it the slots in the M2 SSD connector can tell whether
it's SATA or NVMe or both.  I have an M2 SSD which I believe will work
either with a SATA connection or with NVMe, and it has two slots in
its connector.

-- 
Chris Green
·

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

#275299

> As I understand it the slots in the M2 SSD connector can tell whether
> it's SATA or NVMe or both.  I have an M2 SSD which I believe will work
> either with a SATA connection or with NVMe, and it has two slots in
> its connector.

IIUC the M.2 slot into which you insert the SSD can support either SATA,
or NVMe, or both (depending on the slot), but I have not yet seen any
M.2 SSD drive which works with both SATA and NVMe.


        Stefan

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

#275300

On Thu, Dec 05, 2024 at 05:22:50PM +0000, Chris Green wrote:
>As I understand it the slots in the M2 SSD connector can tell whether
>it's SATA or NVMe or both.  I have an M2 SSD which I believe will work
>either with a SATA connection or with NVMe, and it has two slots in
>its connector.

The M.2 drive will be either NVMe or SATA, I've never heard of one that 
does both (would add cost for no benefit over two simpler cards). The 
M.2 slot can support one or the other or both. SATA drives will have two 
notches (B+M key), NVMe is usually one (M key), but there are two-notch 
drives (B+M key) intended to be usable in M.2 slots actually intended 
for low bandwidth network cards (B key slot without SATA support). The 
M.2 keying situation is generally a bit of a mess and there's no 
guarantee that a drive that physically fits into a slot will actually 
work, while there are configurations which logically work but need a 
physical converter. I assume this is because people did things not 
originally expected by the spec to allow more flexible use of slots, but 
the result is that the keying makes things more confusing rather than 
simplifying anything.

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

#275297

Hi folks,

as promised I send you my experiences with cloning to NVME.

So, today I got my new notebook. As I never used UEFI, I disabled UEFI in BIOS 
(my first mistake!), then cloned everything to the new drive.

Firts reboot worked well, no problems. But then I realized, that if you want 
NVME mode, you MUST use native UEFI in BIOS settings. 

However, doing so, neither Debian nor Windows will boot. Of course: There is 
no EFI partition on my harddrive, as I never needed one (still).

Now I am hasseling with the drive, as I want NVME-mode of course, because it 
is faster. And of course, I do not want to reinstall everything!

I saw some documentations, how to get EFI on the drive, but it looks, you need 
a seperate partition with FAT to get EFI on, right?

However, I saw also the possibility to get EFI on my seperate /boot partition.

What can I do? I would like to keep the existing partitions.  However, I could 
shrink them. At the moment, my drive looks at this:

primary partition Windows-boot  ntfs
primary partition Windows ntfs
primary partition /boot /dev/sda3 ext4
extended partition /dev/sda4 
logical partition /dev/sda5 swap
logical partition /dev/sda6 / ext4
logical partition /dev/sda7 encrypted home
logical partition /dev/sda8 encrypted usr
logical partition /dev/sda9 encrypted var
logical partition /dev/sda10 encrypted data

So I could shrinken some partitions and create a new logical one.

Other option would be, delete "swap" partition and make a new "EFI" partition.

What do you think, might be the best way? 

Some better ideas?

Thanks for reading this.

Best regards

Hans
    

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

#275298 — MBR to GPT + UEFI (was: From SSD to NVME)

On Thu, Dec 5, 2024 at 2:24 PM Hans <hans.ullrich@loop.de> wrote:
>
> as promised I send you my experiences with cloning to NVME.
>
> So, today I got my new notebook. As I never used UEFI, I disabled UEFI in BIOS
> (my first mistake!), then cloned everything to the new drive.
>
> Firts reboot worked well, no problems. But then I realized, that if you want
> NVME mode, you MUST use native UEFI in BIOS settings.
>
> However, doing so, neither Debian nor Windows will boot. Of course: There is
> no EFI partition on my harddrive, as I never needed one (still).
>
> Now I am hasseling with the drive, as I want NVME-mode of course, because it
> is faster. And of course, I do not want to reinstall everything!
>
> I saw some documentations, how to get EFI on the drive, but it looks, you need
> a seperate partition with FAT to get EFI on, right?
>
> However, I saw also the possibility to get EFI on my seperate /boot partition.
>
> What can I do? I would like to keep the existing partitions.  However, I could
> shrink them. At the moment, my drive looks at this:
>
> primary partition Windows-boot  ntfs
> primary partition Windows ntfs
> primary partition /boot /dev/sda3 ext4
> extended partition /dev/sda4
> logical partition /dev/sda5 swap
> logical partition /dev/sda6 / ext4
> logical partition /dev/sda7 encrypted home
> logical partition /dev/sda8 encrypted usr
> logical partition /dev/sda9 encrypted var
> logical partition /dev/sda10 encrypted data
>
> So I could shrinken some partitions and create a new logical one.
>
> Other option would be, delete "swap" partition and make a new "EFI" partition.
>
> What do you think, might be the best way?
>
> Some better ideas?

I believe you are looking for "convert mbr to gpt uefi." See
discussions like
<https://gist.github.com/cjyar/cd5ea76a8692516767672ffc2883df92>.

Jeff

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web