Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #275135 > unrolled thread
| Started by | Hans <hans.ullrich@loop.de> |
|---|---|
| First post | 2024-12-02 17:50 +0100 |
| Last post | 2024-12-03 05:50 +0100 |
| Articles | 20 on this page of 108 — 28 participants |
Back to article view | Back to linux.debian.user
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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> |
|---|---|
| Date | 2024-12-11 09:00 +0100 |
| Message-ID | <JSpNv-g4fc-7@gated-at.bofh.it> |
| In reply to | #275294 |
Michael Stone <mstone@debian.org> writes: > On Thu, Dec 05, 2024 at 10:55:48AM -0500, eben@gmx.us wrote: >>How do I tell how many lanes a given drive uses (preferably before purchase)? > > It would be buried in the technical docs. I've only seen 4x drives > (but I'm sure there may be some cheaper drives with fewer). While we're on the topic PCIe lanes and SSDs, I've been looking into some way of usiing old NVME SSDs when they get replaced by bigger ones. I don't really want to have a stack of little m.2 USB boxes. There are some PCIe adapter boards that take two or more SSDs but what isn't clear to me is if those cards can work in the typically free x1 PCIe slot, if the cards are x4 or x8 and drives are x4? > Yes. Also not many drives can sustain a multi-gigabyte write rate > anyway... I have to say I was quite disappointed when I cloned a 1TB SSD to a 2TB one, average speed wasn't much higher than writing to an HD. I don't remember what the target drive was though. Since I don't intend to make a habit of this, no big deal, but I wonder what kind of write speed one could expect in a sustained write of 1TB?
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-11 14:20 +0100 |
| Message-ID | <JSuNb-g7vz-5@gated-at.bofh.it> |
| In reply to | #275496 |
On Wed, Dec 11, 2024 at 09:51:01AM +0200, Anssi Saari wrote: >Michael Stone <mstone@debian.org> writes: > >> On Thu, Dec 05, 2024 at 10:55:48AM -0500, eben@gmx.us wrote: >>>How do I tell how many lanes a given drive uses (preferably before purchase)? >> >> It would be buried in the technical docs. I've only seen 4x drives >> (but I'm sure there may be some cheaper drives with fewer). > >While we're on the topic PCIe lanes and SSDs, I've been looking into >some way of usiing old NVME SSDs when they get replaced by bigger >ones. I don't really want to have a stack of little m.2 USB boxes. > >There are some PCIe adapter boards that take two or more SSDs but what >isn't clear to me is if those cards can work in the typically free x1 >PCIe slot, if the cards are x4 or x8 and drives are x4? As a general matter PCIe devices can/will downgrade, so e.g., if you plug a x16 video card into a x1 slot it will just work, but at x1 speed. But... The first gotcha is that many "dual m.2" boards have one sata and one nvme slot, and are effectively single slot adapters if you're dealing with nvme drives. To have more than one nvme means one of two things: 1) a pcie switch chip 2) port bifurcation. Switch chips are expensive, and would probably make this exercise cost more than an old nvme drive is worth. Port bifurcation requires a certain number of physical lanes, typical would be a x8 card with x4 going to each of two m.2 slots: in that case, the second slot *will not* work if the adapter is plugged into a x1 slot. Check the documentation carefully to understand what each adapter does, and plan accordingly. To set expectations, a single nvme/pcie adapter costs a few bucks, a nvme+sata adapter a couple of bucks more, a dual nvme with a switch will cost over a hundred, and a dual bifurcated card maybe fifty to a hundred. There are cards that are way overpriced, but rarely are they underpriced--if you see a really good deal on a dual m.2, it's probably nvme+sata. Be warned: I've seen a lot of incompatibilities between various adapters & motherboards in this space. (Beyond the obvious issues with whether a motherboard supports bifurcation, the cards which have pcie switches are using functionality that's in the spec but not used all that much and not necessarily tested on a particular motherboard's implementation-- especially consumer motherboards which aren't expected to use anything other than a video card.) >> Yes. Also not many drives can sustain a multi-gigabyte write rate >> anyway... > >I have to say I was quite disappointed when I cloned a 1TB SSD to a 2TB >one, average speed wasn't much higher than writing to an HD. I don't >remember what the target drive was though. Since I don't intend to make >a habit of this, no big deal, but I wonder what kind of write speed one >could expect in a sustained write of 1TB? Depends absolutely on the drive. Assuming something fairly recent, a gigabyte or two per second is easy to obtain with a simple cp. (If you're copying large files; small files will run much slower.) A transfer to a hard drive will max out around 100-200MByte/s, and a sata SSD around 500-600MByte/s--which shouldn't be hard to exceed with an NVMe unless it's older/cheaper or being throttled by running in the wrong slot.
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> |
|---|---|
| Date | 2024-12-12 22:20 +0100 |
| Message-ID | <JSYLf-gtUF-3@gated-at.bofh.it> |
| In reply to | #275503 |
Michael Stone <mstone@debian.org> writes: > As a general matter PCIe devices can/will downgrade... Thanks for the comprehensive reply. Indeed, those single drive adapters are dirt cheap so that's a "why not" buy. It turns out I actually have a free x4 slot and dual SSD adapters using ASM2812 bridges seem pretty cheap on eBay and Aliexpress, around 60 euros and free shipping. I have no idea if they'd work on my basic consumer motherboard (Asrock B550 Extreme4) but I guess I'll give one of those a try. Quad adapters seem to be rarer and more than twice the price. I have another computer with a free x16 slot but the chipset has no bifurcation support so the common quad SSD boards from Asus for example are out of the question.
[toc] | [prev] | [next] | [standalone]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2024-12-11 14:30 +0100 |
| Message-ID | <JSuWR-g7z9-1@gated-at.bofh.it> |
| In reply to | #275496 |
Anssi Saari wrote: > > Yes. Also not many drives can sustain a multi-gigabyte write rate > > anyway... > > I have to say I was quite disappointed when I cloned a 1TB SSD to a 2TB > one, average speed wasn't much higher than writing to an HD. I don't > remember what the target drive was though. Since I don't intend to make > a habit of this, no big deal, but I wonder what kind of write speed one > could expect in a sustained write of 1TB? One of the tests that servethehome.com does in reviewing SSDs is the write speed after cache saturation: that is, once you have sent enough gigabytes in a row, what is the ongoing write speed? It is not unusual for a PCIe NVMe device to manage writing the first few gigabytes at 4000 MB/s... and then drop to 500, 200 or even 150 MB/s for the long haul. And for many workloads, that's completely reasonable. It doesn't help all that much for copying large filesystems. Note that spinning disks have improved transfer speeds in the last few years. 100-120 MB/s was all you could expect for more than a decade, but you can now find disks that will do 180-250 MB/s for large contiguous transfers. -dsr-
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> |
|---|---|
| Date | 2024-12-12 20:20 +0100 |
| Message-ID | <JSWT7-gsMh-3@gated-at.bofh.it> |
| In reply to | #275504 |
Dan Ritter <dsr@randomstring.org> writes: > One of the tests that servethehome.com does in reviewing SSDs is the > write speed after cache saturation: that is, once you have sent enough > gigabytes in a row, what is the ongoing write speed? Thanks, excellent info, I had no idea servethehome does that kind of benchmarks. I dug up the drive in question, it's a Kingston NV2. Bottom of the barrel cheap, there's a review at https://www.tomshardware.com/reviews/kingston-nv2-ssd/ where they say sustained write speed is about 240 MB/s. That's about what I got, if memory serves.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-02 19:50 +0100 |
| Message-ID | <JPjEB-dgGI-1@gated-at.bofh.it> |
| In reply to | #275135 |
Hans composed on 2024-12-02 11:49 (UTC-0500):
> 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.
You may find it necessary to regenerate your UEFI BIOS boot entry in NVRAM using
efibootmgr.
You very likely would need to add drivers to your initrds first, else have to
rescue boot to rebuild after:
# inxi -Sd
System:
Host: ab250 Kernel: 6.1.0-25-amd64 arch: x86_64 bits: 64
Console: pty pts/0 Distro: Debian GNU/Linux 12 (bookworm)
Drives:
Local Storage: total: 476.94 GiB used: 60.56 GiB (12.7%)
ID-1: /dev/nvme0n1 vendor: Patriot model: M.2 P300 512GB size: 476.94 GiB
Optical-1: /dev/sr0 vendor: Optiarc model: DVD RW AD-7200S
dev-links: cdrom
Features: speed: 48 multisession: yes audio: yes dvd: yes
rw: cd-r,cd-rw,dvd-r,dvd-ram
# lsinitramfs /boot/initrd.img-6.1.0-25-amd64 | egrep 'nvme|ata|ahci|piix'
usr/lib/modules/6.1.0-25-amd64/kernel/drivers/nvme
usr/lib/modules/6.1.0-25-amd64/kernel/drivers/nvme/host
usr/lib/modules/6.1.0-25-amd64/kernel/drivers/nvme/host/nvme-core.ko
usr/lib/modules/6.1.0-25-amd64/kernel/drivers/nvme/host/nvme.ko
usr/lib/udev/ata_id
usr/bin/fatattr
#
I forgot to do it first the last time.
Oh, and I never use UUIDs, only LABELs.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Bruno Schneider <boschneider@gmail.com> |
|---|---|
| Date | 2024-12-02 19:50 +0100 |
| Message-ID | <JPjEB-dgGI-3@gated-at.bofh.it> |
| In reply to | #275135 |
> 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: I would recommend changing from UUID to labels. Doing so, all you need to worry is that the new partitions have the same labels as the old ones. https://wiki.debian.org/fstab#Labels 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. -- Bruno Schneider
[toc] | [prev] | [next] | [standalone]
| From | Erwan David <erwan@rail.eu.org> |
|---|---|
| Date | 2024-12-02 20:20 +0100 |
| Message-ID | <JPk7D-dh6u-1@gated-at.bofh.it> |
| In reply to | #275147 |
Le 02/12/2024 à 19:41, Bruno Schneider a écrit : >> 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: > I would recommend changing from UUID to labels. Doing so, all you need > to worry is that the new partitions have the same labels as the old > ones. > https://wiki.debian.org/fstab#Labels > > 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. > In 2019 I installed debian on nvme without any problem...
[toc] | [prev] | [next] | [standalone]
| From | Hans <hans.ullrich@loop.de> |
|---|---|
| Date | 2024-12-02 20:30 +0100 |
| Message-ID | <JPkhj-dh9B-9@gated-at.bofh.it> |
| In reply to | #275148 |
Yes, I read in other debian threads abnout Labels. What is the advantage of Labels to UUID? I alwaqys thought, labels can be easily changed and then at boot, linux would mount some other partition with the same label. But it will be rather difficult, to create a partition with the same UUID (but other size and content) of an existent (except of cloning, of course). Using labels seem to be rather unsecure in my opinion. Hans > In 2019 I installed debian on nvme without any problem...
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-12-02 21:20 +0100 |
| Message-ID | <JPl3H-dhG3-1@gated-at.bofh.it> |
| In reply to | #275151 |
Hi,
[ Beware not making clear that you mean FILESYSTEM labels and UUIDs
in this thread. It's been a week since we've had massive
misunderstanding of what filesystem UUIDs are and every mention of
UUID or LABEL without that context risks invoking a very confused
person who is prepared to write 100 emails on the subject. ]
On Mon, Dec 02, 2024 at 08:20:23PM +0100, Hans wrote:
> Yes, I read in other debian threads abnout Labels. What is the advantage of
> Labels to UUID?
Filesystem labels are easier for humans to read than filesystem UUIDs.
> I alwaqys thought, labels can be easily changed and then at
> boot, linux would mount some other partition with the same label.
I don't really understand your second part but it is as easy to change a
filesystem label as it is to change a filesystem UUID.
> But it will be rather difficult, to create a partition with the same UUID (but
> other size and content) of an existent (except of cloning, of course).
It's easy to set a specific filesystem UUID so if you really want to you
can easily set a new filesystem to have the same UUID as an existing
filesystem. Nothing will warn you or stop you. However since it is so
unnatural to type, perhaps it is less easy to do so *accidentally*.
I think the distinction would be that it isn't a usual procedure to
ever *set* a filesystem UUID since they are normally *generated*, whereas
it is quite common to set a filesystem LABEL.
> Using labels seem to be rather unsecure in my opinion.
I don't understand why they would be insecure, unless you meant
"dangerous" and even then, I can only understand it from the point of
view of it being easier to accidentally set more than one the same.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Hans <hans.ullrich@loop.de> |
|---|---|
| Date | 2024-12-02 21:50 +0100 |
| Message-ID | <JPlwJ-dhQC-9@gated-at.bofh.it> |
| In reply to | #275154 |
Am Montag, 2. Dezember 2024, 21:18:05 CET schrieb Andy Smith: > Hi, > > [ Beware not making clear that you mean FILESYSTEM labels and UUIDs > in this thread. It's been a week since we've had massive > misunderstanding of what filesystem UUIDs are and every mention of > UUID or LABEL without that context risks invoking a very confused > person who is prepared to write 100 emails on the subject. ] > Hi Andy, maybe I understood some thing not correct (because I am German), and my meaning of "Label" is not your meaning of "Label". That, what i understand as label is the name, I give a partition. For example, in gparted, I can give a partition a label like I want. For example, my Windows partition can get a label like "windows", "win11", "shitty_windows" or whatever, or my datapartition maybe labelled "space1". Is it that, what we are talking about? If yes, then I believe, it might be easy (or with some efforts), to hang in an usb-drive with a special label, which will then be booted, as the label of the usb-drive can be found in /etc/ fstab. But it will be much more difficiult, to create an usb-drive with the same UUID as can be found in /etc/fstab. That was my point, but maybe, as said before, we are talking of different kind of labels. Have fun! Hans
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-12-02 22:30 +0100 |
| Message-ID | <JPm9r-dijr-7@gated-at.bofh.it> |
| In reply to | #275157 |
Hi, On Mon, Dec 02, 2024 at 09:47:05PM +0100, Hans wrote: > That, what i understand as label is the name, I give a partition. For example, > in gparted, I can give a partition a label like I want. For example, my > Windows partition can get a label like "windows", "win11", "shitty_windows" or > whatever, or my datapartition maybe labelled "space1". Yeah, so, already we are off in the weeds. 🙁 But in that case I'm glad I said something! Lots of things can have UUIDs and lots of things can have LABELs. Sadly when we start to talk about storage a number of those things are involved so people get confused easily about which one is being talked about. I think you're talking about PARTLABELs, which parted refers to as "partition names". Those are held inside the GPT and refer to each partition independent of the contents of that partition. So you could nuke the contents of the partition and it would still show as having that PARTLABEL. Filesystems can also have labels. They are like Filesystem UUIDs. If you destroyed the filesystem you would destroy its label. In fstab you can refer to them with LABEL= instead of UUID=. You can set them with a tool like "e2label" or at creation time (mkfs.ext4 -L mylabel …"). Aside from LABEL confusion there is also UUID confusion, since partitions in a GPT will have UUIDs as well! See /dev/disk/by-partuuid/. In fstab you can use these GPT features with PARTLABEL= and PARTUUID=. We have threads here where tens of messages go by before the participants realise they are talking about two different kinds of LABEL or UUID. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-12-03 06:40 +0100 |
| Message-ID | <JPtND-dnI9-1@gated-at.bofh.it> |
| In reply to | #275158 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Dec 02, 2024 at 09:22:05PM +0000, Andy Smith wrote: > Hi, > > On Mon, Dec 02, 2024 at 09:47:05PM +0100, Hans wrote: > > That, what i understand as label is the name, I give a partition. For example, > > in gparted, I can give a partition a label like I want. For example, my > > Windows partition can get a label like "windows", "win11", "shitty_windows" or > > whatever, or my datapartition maybe labelled "space1". > > Yeah, so, already we are off in the weeds. 🙁 But in that case I'm > glad I said something! "There are several levels of labels" (TM) ;-) (and of course, of UUIDs and things) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-02 21:40 +0100 |
| Message-ID | <JPln4-dhN0-3@gated-at.bofh.it> |
| In reply to | #275151 |
Hans composed on 2024-12-02 20:20 (UTC+0100): > Yes, I read in other debian threads abnout Labels. What is the advantage of > Labels to UUID? I alwaqys thought, labels can be easily changed and then at > boot, linux would mount some other partition with the same label. > But it will be rather difficult, to create a partition with the same UUID (but > other size and content) of an existent (except of cloning, of course). > Using labels seem to be rather unsecure in my opinion. Labels not intended to be unique enough would indeed pose a threat to filesystems. Mine are unique enough to pose nominal risk. I typically make up a LABEL based upon some substring from the disk's serial and/or model number, a shorthand name of the OS/version or usage of the filesystem, and the partition number, 5-13 characters I can remember and type from a Grub prompt, unlike a UUID. Nothing forces use of special characters, upper case, lower case, numbers or the like as with online passwords. Use whatever works in your brain. When cloning, tools are readily available to re-unique labels, e.g. tune2fs -L. I clone often, part of backup strategy. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 16:50 +0100 |
| Message-ID | <JQmh3-dWz4-3@gated-at.bofh.it> |
| In reply to | #275147 |
On Mon, Dec 02, 2024 at 03:41:43PM -0300, Bruno Schneider wrote: >I would recommend changing from UUID to labels. Doing so, all you need >to worry is that the new partitions have the same labels as the old >ones. >https://wiki.debian.org/fstab#Labels I personally prefer UUIDs because the odds of an existing drive from a different system having a conflicting UUID when you put it in another system is near zero while the odds that another drive would have something like LABEL=root is very high. The installer adds UUIDs by default so most people will never need to decide or even think about this. In practical terms, in most cases, it doesn't matter which you use. If you use something like LVM it really doesn't matter as you'll just use the LV name (and in practice, this is what I do on any system that's not just one big partition). Arguing over one vs the other is pointless as there's no obvious right answer so much as there is personal preference; the only wrong answer is using the device name. :-)
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-05 18:30 +0100 |
| Message-ID | <JQnPQ-dXIW-7@gated-at.bofh.it> |
| In reply to | #275285 |
Michael Stone composed on 2024-12-05 10:42 (UTC-0500): >>https://wiki.debian.org/fstab#Labels > I personally prefer UUIDs because the odds of an existing drive from a > different system having a conflicting UUID when you put it in another > system is near zero while the odds that another drive would have > something like LABEL=root is very high. Clearly, because it's a seriously inept volume LABEL selection. Among the following are some better, yet easy enough to remember and type, examples: # egrep -i 'deb11|deb 11|seye|bull|debian11|debian 11' *L*txt | grep ├─ | wc -l 26 # egrep -i 'deb11|deb 11|seye|bull|debian11|debian 11' *L*txt | grep ├─ a-865L10.txt:├─sda28 ext4 SS25deb11 cb7dac29-… ab250L26.txt:├─nvme0n1p14 ext4 pt3p14deb11 889fea98-… ab560L10.txt:├─nvme0n1p14 ext4 tm8p14deb11 78980253-… ab85mL14.txt:├─sda17 ext4 tg1p17deb11 53725495-… asa88L08.txt:├─sda14 ext4 tvgp14deb11 2c533ad4-… big31L52.txt:├─sda28 ext4 p61bullseye 8718ac45-… big41L51.txt:├─sda25 ext4 i256bullseye 274996ea-… fi965L26.txt:├─sda17 ext4 w71bullseye c3b75320-… g5easL34.txt:├─sda11 ext4 m25p11deb11 8cb07113-… ga88xL01.txt:├─sda14 ext4 tvgp14deb11 2c533ad4-… gb970L12.txt:├─sda24 ext4 gs5p24deb11 f890a134-… gx270L14.txt:├─sda31 ext4 debian11 7b4a7828-… gx27bL23.txt:├─sda33 ext4 33deb11 d25ab64a-… gx27cL20.txt:├─sda32 ext3 deb11p32 307f2bcb-… gx280L27.txt:├─sda21 ext4 21deb11 908f51ef-… gx28bL21.txt:├─sda24 ext3 s16d-deb11 8711d07c-… gx320L15.txt:├─sda34 ext4 sbyd-deb11 bfc2b8a0-… gx62bL32.txt:├─sda35 ext4 t87p35deb11 7b6de942-… gx780L30.txt:├─sda25 ext4 25deb11 79dcb3f6-… gx78bL12.txt:├─sda16 ext4 p256p16deb11 6c2f8ee8-… hp750L05.txt:├─sda14 ext4 st20deb11 32f05d14-… hp945L15.txt:├─sda15 ext4 h8sbullseye 2f1ef2a2-… m7ncdL29.txt:├─sda44 ext3 H16Adeb11 7c5fd253-… mcp61L19.txt:├─sdb21 ext4 debian11 367e0348-… msi85L11.txt:├─sda10 ext4 sp25p10deb11 d8be9f22-… # The *L*txt files are automatically generated partitioner[1] logs with both both parted -l and lsblk -f output appended, which I use for keeping track of what's installed where here. Strings like pt3, tm8, m25 & sbyd above are extractions from disk model and/or serial numbers. [1] http://www.dfsee.com/ -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 19:20 +0100 |
| Message-ID | <JQoCd-dYeW-3@gated-at.bofh.it> |
| In reply to | #275291 |
On Thu, Dec 05, 2024 at 12:24:36PM -0500, Felix Miata wrote: >Clearly, because it's a seriously inept volume LABEL selection. Among the >following are some better, yet easy enough to remember and type, examples: ># egrep -i 'deb11|deb 11|seye|bull|debian11|debian 11' *L*txt | grep ├─ | wc -l >26 ># egrep -i 'deb11|deb 11|seye|bull|debian11|debian 11' *L*txt | grep ├─ >a-865L10.txt:├─sda28 ext4 SS25deb11 cb7dac29-… >ab250L26.txt:├─nvme0n1p14 ext4 pt3p14deb11 889fea98-… [snip] Never have I felt any need or desire to do anything like that. If I did, it would be on an LVM, not on dozens of partitions. >The *L*txt files are automatically generated partitioner[1] logs with >both both parted -l and lsblk -f output appended, which I use for keeping >track of what's installed where here. Strings like pt3, tm8, m25 & sbyd >above are extractions from disk model and/or serial numbers. Perhaps we can agree to disagree on what's easy. IMO, your labels are basically as opaque as a UUID, even if systemic, but with the disadvantage of needing more effort to genreate. :-)
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-05 20:20 +0100 |
| Message-ID | <JQpyh-dYOV-1@gated-at.bofh.it> |
| In reply to | #275295 |
Michael Stone composed on 2024-12-05 13:13 (UTC-0500): > On Thu, Dec 05, 2024 at 12:24:36PM -0500, Felix Miata wrote: >>Clearly, because it's a seriously inept volume LABEL selection. Among the >>following are some better, yet easy enough to remember and type, examples: >># egrep -i 'deb11|deb 11|seye|bull|debian11|debian 11' *L*txt | grep ├─ | wc -l >>26 >># egrep -i 'deb11|deb 11|seye|bull|debian11|debian 11' *L*txt | grep ├─ >>a-865L10.txt:├─sda28 ext4 SS25deb11 cb7dac29-… >>ab250L26.txt:├─nvme0n1p14 ext4 pt3p14deb11 889fea98-… > [snip] > Never have I felt any need or desire to do anything like that. If I did, > it would be on an LVM, not on dozens of partitions I have more than 40 PCs with well in excess of a dozen installed distros, each on a partition, readily cloned as element of backup system or seeding a new PC. I've never imagined any remotely simple way cloning (from outside an involved OS) could work with LVM employed. >>The *L*txt files are automatically generated partitioner[1] logs with >>both both parted -l and lsblk -f output appended, which I use for keeping >>track of what's installed where here. Strings like pt3, tm8, m25 & sbyd >>above are extractions from disk model and/or serial numbers. > Perhaps we can agree to disagree on what's easy. IMO, your labels are > basically as opaque as a UUID, even if systemic, but with the > disadvantage of needing more effort to genreate. :-) Generate too, big deal. I get cross-eyed looking at them. LOL 8 or 13 characters I can remember, recognize and type within a 40 entry custom.cfg or 40_custom, among other places, such as # wc -l /etc/fstab 155 /etc/fstab # I'm annoyed constantly in help forums, where scrolling is required, or wrapping occurs, because of 36 character UUID string pollution functioning as yet another "personally identifiable information"[1] data element for the data scrapers. [1] https://en.wikipedia.org/wiki/Personal_identifier -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 21:00 +0100 |
| Message-ID | <JQqaZ-dZ6e-5@gated-at.bofh.it> |
| In reply to | #275296 |
On Thu, Dec 05, 2024 at 02:15:13PM -0500, Felix Miata wrote: >I have more than 40 PCs with well in excess of a dozen installed distros, each on >a partition, You have a unique set of requirements. Probably that has little relevance to basically anyone else.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2024-12-05 22:20 +0100 |
| Message-ID | <JQrqp-e01a-7@gated-at.bofh.it> |
| In reply to | #275301 |
Michael Stone composed on 2024-12-05 14:50 (UTC-0500): > On Thu, Dec 05, 2024 at 02:15:13PM -0500, Felix Miata wrote: >>I have more than 40 PCs with well in excess of a dozen installed distros, each on >>a partition, > You have a unique set of requirements. Probably that has little > relevance to basically anyone else. I hear identifying hardware problems using VMs is rather problematic - no such obstacle here. :) Michael Stone composed on 2024-12-05 15:12 (UTC-0500): > You can't just dd the disks if you have an old style dos partition > table, you need to create a GPT partition table on the new drive, then > dd the individual partitions. I'm unaware of a tool that would automated > this, though one may exist. At least one does. I provided URL to the one I use, for some definition of "automated", upthread @2024-12-05 12:24 (UTC-0500) in reply to your post 102 minutes earlier. :) -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web