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

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

f3tools vs Silicon Power 4T drive

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

Contents

  f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-14 23:10 +0100
    Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-15 01:50 +0100
      Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-15 03:10 +0100
        Re: f3tools vs Silicon Power 4T drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-15 03:30 +0100
        Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-15 17:00 +0100
      Re: f3tools vs Silicon Power 4T drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-15 03:20 +0100
      Re: f3tools vs Silicon Power 4T drive Max Nikulin <manikulin@gmail.com> - 2024-02-15 03:20 +0100
        Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-15 04:10 +0100
      Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-15 04:00 +0100
        Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-15 17:20 +0100
          Re: f3tools vs Silicon Power 4T drive David Wright <deblis@lionunicorn.co.uk> - 2024-02-15 17:30 +0100
          Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-15 21:30 +0100
            Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-15 21:50 +0100
              Re: f3tools vs Silicon Power 4T drive David Wright <deblis@lionunicorn.co.uk> - 2024-02-15 22:30 +0100
                Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-16 07:40 +0100
                  Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-16 15:50 +0100
                    Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-17 03:20 +0100
                      Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-17 06:50 +0100
                        Re: f3tools vs Silicon Power 4T drive Jeffrey Walton <noloader@gmail.com> - 2024-02-17 07:40 +0100
                          Of irrelevant chatter and meta-chatter [was: f3tools vs Silicon  Power 4T drive] <tomas@tuxteam.de> - 2024-02-17 09:50 +0100
                        Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-17 18:50 +0100
                        Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-18 02:30 +0100
                  Re: f3tools vs Silicon Power 4T drive David Wright <deblis@lionunicorn.co.uk> - 2024-02-16 21:10 +0100
              Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-15 22:50 +0100
              Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-16 02:50 +0100
                Re: f3tools vs Silicon Power 4T drive debian-user@howorth.org.uk - 2024-02-16 13:50 +0100
                  Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-16 16:40 +0100
                Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-16 16:00 +0100
                Re: f3tools vs Silicon Power 4T drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-16 21:20 +0100
                  Re: f3tools vs Silicon Power 4T drive Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-16 21:50 +0100
                    Re: f3tools vs Silicon Power 4T drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-16 22:10 +0100
                    Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-16 22:20 +0100
                      Re: f3tools vs Silicon Power 4T drive debian-user@howorth.org.uk - 2024-02-17 21:20 +0100
                    Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-17 03:30 +0100
                    Re: f3tools vs Silicon Power 4T drive <tomas@tuxteam.de> - 2024-02-17 06:40 +0100
                  Re: f3tools vs Silicon Power 4T drive <tomas@tuxteam.de> - 2024-02-17 06:40 +0100
                    Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-18 02:10 +0100
                      Re: f3tools vs Silicon Power 4T drive <tomas@tuxteam.de> - 2024-02-18 07:50 +0100
            Re: f3tools vs Silicon Power 4T drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-16 21:00 +0100
      Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-15 17:10 +0100
        Re: f3tools vs Silicon Power 4T drive debian-user@howorth.org.uk - 2024-02-15 18:40 +0100
          Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-15 20:50 +0100
            Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-15 22:10 +0100
              Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-15 22:30 +0100
                Re: f3tools vs Silicon Power 4T drive gene heskett <gheskett@shentel.net> - 2024-02-16 07:20 +0100
                  Re: f3tools vs Silicon Power 4T drive Andy Smith <andy@strugglers.net> - 2024-02-16 15:40 +0100
                  Re: f3tools vs Silicon Power 4T drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-16 21:30 +0100
              Re: f3tools vs Silicon Power 4T drive Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-15 23:40 +0100
                Re: f3tools vs Silicon Power 4T drive Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-02-16 08:50 +0100
              Re: f3tools vs Silicon Power 4T drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-16 21:10 +0100
                Re: f3tools vs Silicon Power 4T drive David Wright <deblis@lionunicorn.co.uk> - 2024-02-16 21:10 +0100

Page 1 of 3  [1] 2 3  Next page →

#267408 — f3tools vs Silicon Power 4T drive

Drive is plugged into amobo usb-3 port via a startech USB3S2SAT3CB 
ADAPTER CABLE.

f3probe took over 16 seconds, but says it the real thing:
root@coyote:~# f3probe /dev/sdc
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
          it can take longer. Please be patient.

Probe finished, recovering blocks... Done

Good news: The device `/dev/sdc' is the real thing

Device geometry:
                  *Usable* size: 3.64 TB (7814037168 blocks)
                 Announced size: 3.64 TB (7814037168 blocks)
                         Module: 4.00 TB (2^42 Bytes)
         Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
            Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 16.04s

2nd drive is a CC of first. So in hex, those two should yield 7.28T of 
storage..

I have made 1 full partiton om each one, a labeled those partitions  as 
SiPwr_0 and SiPwr_1
I have not attempted to do anything else until the hdwe is fully 
assembled.  My only question it will those partition names survive 
lvcreating an 11T lvm out of these and 2 more 2T gigastones.

Thanks for any advice since I have not dealt with an lvm in about 15+ 
years trying it once when it first came out with a high disaster rating 
then. This time the experiment will be on something expendable in its 
early days.

Thank you all.

Take care, stay warm and well.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [next] | [standalone]

#267410

Hi,

On Wed, Feb 14, 2024 at 05:09:02PM -0500, gene heskett wrote:
> I have made 1 full partiton om each one, a labeled those partitions  as
> SiPwr_0 and SiPwr_1

Please show us the command you used¹ to do that, so we know what
exactly you are talking about, because as previously discussed
there's a lot of different things that you like to call "partition
labels".

If we take that literally that would be a GPT partition name, but
you've used this same terminology before and meant a filesystem
label.

> My only question it will those partition names survive lvcreating an 11T lvm
> out of these and 2 more 2T gigastones.

Assuming you meant partition name the first time as well, nothing
you do other than a disk wipe or re-name should alter those
partition names.

But your chosen partition names don't make a lot of sense to me.
You've picked names based on the type/manufacturer of device so you
may as well have just used the names from /dev/disk/by-id/… which
already have that information and are already never going to change.
I don't know why you want to complicate matters.

If instead you put filesystems on these partitions and labelled
*those*, well, no, LVM goes under filesystems so those filesystems
and their labels (and contents) are not long for this world.

> I have not dealt with an lvm in about 15+ years trying it once
> when it first came out with a high disaster rating then.

I hope you are putting a level of redundancy under that LVM or are
using the redundancy features of LVM (which you need to go out of
your way to do). Otherwise by default what you'll have is not
redundant and a device failure will lose at least the contents of
that device, possibly more.

Regards,
Andy

¹ and while you are there, maybe a post-it note with "I will show
  the exact command I used any time I write to debian-user" stuck to
  the top of the display of the screen you use to compose emails
  would help, because basically every thread you post here lacks
  that information.

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

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

#267411

On 2/14/24 19:48, Andy Smith wrote:
> Hi,
> 
> On Wed, Feb 14, 2024 at 05:09:02PM -0500, gene heskett wrote:
>> I have made 1 full partiton om each one, a labeled those partitions  as
>> SiPwr_0 and SiPwr_1
> 
> Please show us the command you used¹ to do that, so we know what
> exactly you are talking about, because as previously discussed
> there's a lot of different things that you like to call "partition
> labels".
> 
> If we take that literally that would be a GPT partition name, but
> you've used this same terminology before and meant a filesystem
> label.
> 
>> My only question it will those partition names survive lvcreating an 11T lvm
>> out of these and 2 more 2T gigastones.
> 
> Assuming you meant partition name the first time as well, nothing
> you do other than a disk wipe or re-name should alter those
> partition names.
> 
> But your chosen partition names don't make a lot of sense to me.
> You've picked names based on the type/manufacturer of device so you
> may as well have just used the names from /dev/disk/by-id/… which
> already have that information and are already never going to change.
> I don't know why you want to complicate matters.

Will the by-id string fit in the space reserved for a label?That IF 
there was a connection between the /dev/sdc that udev assigns and 
anything in this list:

root@coyote:~# ls /dev/disk/by-id
ata-ATAPI_iHAS424_B_3524253_327133504865 
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1    wwn-0x5002538f413394a5
ata-Gigastone_SSD_GST02TBG221146 
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 
wwn-0x5002538f413394a5-part1
ata-Gigastone_SSD_GST02TBG221146-part1 
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 
wwn-0x5002538f413394a5-part2
ata-Gigastone_SSD_GSTD02TB230102 
ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V 
wwn-0x5002538f413394a5-part3
ata-Gigastone_SSD_GSTD02TB230102-part1 
ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1    wwn-0x5002538f413394a9
ata-Gigastone_SSD_GSTG02TB230206 
ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 
wwn-0x5002538f413394a9-part1
ata-Gigastone_SSD_GSTG02TB230206-part1 
ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 
wwn-0x5002538f413394a9-part2
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T 
ata-SPCC_Solid_State_Disk_AA231107S304KG00080 
wwn-0x5002538f413394a9-part3
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 
ata-SPCC_Solid_State_Disk_AA231107S304KG00080-part1  wwn-0x5002538f413394ae
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2  md-name-coyote:0 
                                wwn-0x5002538f413394ae-part1
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 
md-name-coyote:0-part1 
wwn-0x5002538f413394ae-part2
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E        md-name-coyote:2 
                                wwn-0x5002538f413394ae-part3
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1  md-name-_none_:1 
                                wwn-0x5002538f413394b0
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 
md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb 
wwn-0x5002538f413394b0-part1
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 
md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 
wwn-0x5002538f413394b0-part2
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V 
md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 
wwn-0x5002538f413394b0-part3
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 
md-uuid-bb6e03ce:19d290c8:5171004f:0127a392          wwn-0x5002538f42205e8e
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 
usb-SPCC_Sol_id_State_Disk_1234567897E6-0:0 
wwn-0x5002538f42205e8e-part1
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 
usb-SPCC_Sol_id_State_Disk_1234567897E6-0:0-part1 
wwn-0x5002538f42205e8e-part2
ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W 
usb-USB_Mass_Storage_Device_816820130806-0:0 
wwn-0x5002538f42205e8e-part3
root@coyote:~#

I dare you to find the disk that udev calls sdc in the above wall of text.

Why can't you understand that I want a unique label for all of this 
stuff that is NOT a wall of HEX numbers no one can remember.  Its not 
mounted, so blkid does NOT see it.

> If instead you put filesystems on these partitions and labelled
> *those*, well, no, LVM goes under filesystems so those filesystems
> and their labels (and contents) are not long for this world.
> 
>> I have not dealt with an lvm in about 15+ years trying it once
>> when it first came out with a high disaster rating then.
> 
> I hope you are putting a level of redundancy under that LVM or are
> using the redundancy features of LVM (which you need to go out of
> your way to do). Otherwise by default what you'll have is not
> redundant and a device failure will lose at least the contents of
> that device, possibly more.
> 
> Regards,
> Andy
> 
> ¹ and while you are there, maybe a post-it note with "I will show
>    the exact command I used any time I write to debian-user" stuck to
>    the top of the display of the screen you use to compose emails
>    would help, because basically every thread you post here lacks
>    that information.
> 

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#267415

On 2/14/24 18:06, gene heskett wrote:
> Will the by-id string fit in the space reserved for a label?That IF 
> there was a connection between the /dev/sdc that udev assigns and 
> anything in this list:
> 
> root@coyote:~# ls /dev/disk/by-id
> ata-ATAPI_iHAS424_B_3524253_327133504865 
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1    wwn-0x5002538f413394a5
> ata-Gigastone_SSD_GST02TBG221146 
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 
> wwn-0x5002538f413394a5-part1
> ata-Gigastone_SSD_GST02TBG221146-part1 
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 
> wwn-0x5002538f413394a5-part2
> ata-Gigastone_SSD_GSTD02TB230102 
> ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V wwn-0x5002538f413394a5-part3
> ata-Gigastone_SSD_GSTD02TB230102-part1 
> ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1    wwn-0x5002538f413394a9
> ata-Gigastone_SSD_GSTG02TB230206 
> ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 
> wwn-0x5002538f413394a9-part1
> ata-Gigastone_SSD_GSTG02TB230206-part1 
> ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 
> wwn-0x5002538f413394a9-part2
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T 
> ata-SPCC_Solid_State_Disk_AA231107S304KG00080 wwn-0x5002538f413394a9-part3
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 
> ata-SPCC_Solid_State_Disk_AA231107S304KG00080-part1  wwn-0x5002538f413394ae
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2  md-name-coyote:0 
>                                 wwn-0x5002538f413394ae-part1
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 md-name-coyote:0-part1 
> wwn-0x5002538f413394ae-part2
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E        md-name-coyote:2 
>                                 wwn-0x5002538f413394ae-part3
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1  md-name-_none_:1 
>                                 wwn-0x5002538f413394b0
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 
> md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb wwn-0x5002538f413394b0-part1
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 
> md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 
> wwn-0x5002538f413394b0-part2
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V 
> md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 wwn-0x5002538f413394b0-part3
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 
> md-uuid-bb6e03ce:19d290c8:5171004f:0127a392          wwn-0x5002538f42205e8e
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 
> usb-SPCC_Sol_id_State_Disk_1234567897E6-0:0 wwn-0x5002538f42205e8e-part1
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 
> usb-SPCC_Sol_id_State_Disk_1234567897E6-0:0-part1 
> wwn-0x5002538f42205e8e-part2
> ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W 
> usb-USB_Mass_Storage_Device_816820130806-0:0 wwn-0x5002538f42205e8e-part3
> root@coyote:~#
> 
> I dare you to find the disk that udev calls sdc in the above wall of text.
> 
> Why can't you understand that I want a unique label for all of this 
> stuff that is NOT a wall of HEX numbers no one can remember.  Its not 
> mounted, so blkid does NOT see it.


For labeled disk partitions, use /dev/disk/by-label/* paths:

2024-02-14 18:22:34 root@taz ~
# ls -1 /dev/disk/by-label/
sda3_crypt
taz_boot
taz_root


David

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

#267431

Hi,

On Wed, Feb 14, 2024 at 09:06:43PM -0500, gene heskett wrote:
> On 2/14/24 19:48, Andy Smith wrote:
> > But your chosen partition names don't make a lot of sense to me.
> > You've picked names based on the type/manufacturer of device so you
> > may as well have just used the names from /dev/disk/by-id/… which
> > already have that information and are already never going to change.
> > I don't know why you want to complicate matters.
> 
> Will the by-id string fit in the space reserved for a label?

I doubt it, but what would be the point of doing that? The device ID
conveys all the same information that you're putting in the
partition name.

> I dare you to find the disk that udev calls sdc in the above wall of text.

$ ls -l /dev/disk/by-id | grep sdb1
lrwxrwxrwx 1 root root 10 Jan 17 02:49 ata-SAMSUNG_MZ7KM1T9HAJM-00005_S2HNNAAGA00863-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan 17 02:49 wwn-0x5002538c00066800-part1 -> ../../sdb1

Thus, partition 1 of sdb1 is on partition 1 of
/dev/disk/by-id/ata-SAMSUNG_MZ7KM1T9HAJM-00005_S2HNNAAGA00863.
Information already held by the kernel; no need to duplicate it in a
GPT partition name or anywhere else.

There are many other ways to retrieve the same information; that was
the first that sprang to mind but I would not use that in a script
because it's basically parsing ls (a big no-no).

If you'd simply state what you're trying to achieve then 99.9% of
all your posts wouldn't be massive X/Y problems.

> Why can't you understand that I want a unique label for all of this stuff
> that is NOT a wall of HEX numbers no one can remember.  Its not mounted, so
> blkid does NOT see it.

See above. You're welcome.

I note that you still haven't responded with the exact command you
used to set these "labels", so at this point we still do not know
exactly what you mean and I have to proceed assuming you meant GPT
partition name. A simple request that would enable us to help you
better, ignored.

Regards,
Andy

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

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

#267412

On 2/14/24 17:48, gene heskett wrote:
> On 2/14/24 19:48, Andy Smith wrote:
>> On Wed, Feb 14, 2024 at 05:09:02PM -0500, gene heskett wrote:
>>> I have made 1 full partiton om each one, a labeled those partitions  as
>>> SiPwr_0 and SiPwr_1
>>
>> Please show us the command you used¹ to do that, so we know what
>> exactly you are talking about, because as previously discussed
>> there's a lot of different things that you like to call "partition
>> labels".
> 
> This is what gparted calls a "partition label" and certainly does not 
> need a 4.5 megabyte camera image to see. or even a 50k screen snap.
> Taking this screenshot was a pita, because the gparted window disappears 
> behind the terminal screen when you click on take another shot, so you 
> have to quit, then find the gparted on the tool bar to bring it back to 
> the front, then move it and the terminal so its not totally hidden. Then 
> rerun spectacle again waste a click bringing it fwd, then 30 seconds 
> later the spectacal instructions finally show up and after 5 minutes of 
> screwing around, finally get the screen shot attached to prove I'm not 
> lieing.


The easy and accurate answer is to use a root console, fdisk(8) with 
--list-details, select the console session, and paste into a mail reply:

2024-02-14 18:09:26 root@taz ~
# fdisk --list-details /dev/sda
Disk /dev/sda: 55.9 GiB, 60022480896 bytes, 117231408 sectors
Disk model: INTEL SSDSC2CW06
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 816CF78F-AFAD-4F70-AAA0-B08C6CE95AE7
First LBA: 34
Last LBA: 117231374
Alternative LBA: 117231407
Partition entries LBA: 2
Allocated partition entries: 128

Device        Start       End  Sectors Type-UUID 
    UUID                                 Name              Attrs
/dev/sda1      2048   1953791  1951744 
C12A7328-F81F-11D2-BA4B-00A0C93EC93B 
5A1358F4-23A2-4CF6-A4E2-0A30A0FFC904 ESP
/dev/sda2   1953792   3907583  1953792 
0FC63DAF-8483-4772-8E79-3D69D8477DE4 
B429D984-E32D-4BAE-A7AE-137168B0F0F3 taz_boot
/dev/sda3   3907584   5861375  1953792 
0FC63DAF-8483-4772-8E79-3D69D8477DE4 
83862E6A-7B89-4AB9-A21D-BAEF3AD0F7A3 taz_swap_crypt
/dev/sda4   5861376  29298687 23437312 
0FC63DAF-8483-4772-8E79-3D69D8477DE4 
2A708FD7-F6EE-49D7-8E23-65905BCD6512 taz_root_crypt
/dev/sda5  29298688 117229567 87930880 
0FC63DAF-8483-4772-8E79-3D69D8477DE4 
B8468EA2-B66D-4D13-9FD1-E46AEDA58067 taz_scratch_crypt


David

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

#267413

On 15/02/2024 08:48, gene heskett wrote:
> This is what gparted calls a "partition label" and certainly does not 
> need a 4.5 megabyte camera image to see. or even a 50k screen snap.

lsblk --fs -o +PARTLABEL  /dev/sdc

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

#267418

On 2/14/24 21:14, Max Nikulin wrote:
> On 15/02/2024 08:48, gene heskett wrote:
>> This is what gparted calls a "partition label" and certainly does not 
>> need a 4.5 megabyte camera image to see. or even a 50k screen snap.
> 
> lsblk --fs -o +PARTLABEL  /dev/sdc
> 
> NAME   FSTYPE FSVER LABEL   UUID                                 FSAVAIL FSUSE% MOUNTPOINTS PARTLABEL
sdc 

└─sdc1 ext4   1.0   SiPwr_1 70bfe832-38b1-46ed-85f4-33cf473185bb
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#267417

On 2/14/24 20:49, gene heskett wrote:
> On 2/14/24 19:48, Andy Smith wrote:
>> Hi,
>>
>> On Wed, Feb 14, 2024 at 05:09:02PM -0500, gene heskett wrote:
>>> I have made 1 full partiton om each one, a labeled those partitions  as
>>> SiPwr_0 and SiPwr_1
>>
>> Please show us the command you used¹ to do that, so we know what
>> exactly you are talking about, because as previously discussed
>> there's a lot of different things that you like to call "partition
>> labels".
> 
> This is what gparted calls a "partition label" and certainly does not 
> need a 4.5 megabyte camera image to see. or even a 50k screen snap.
> Taking this screenshot was a pita, because the gparted window disappears 
> behind the terminal screen when you click on take another shot, so you 
> have to quit, then find the gparted on the tool bar to bring it back to 
> the front, then move it and the terminal so its not totally hidden. Then 
> rerun spectacle again waste a click bringing it fwd, then 30 seconds 
> later the spectacal instructions finally show up and after 5 minutes of 
> screwing around, finally get the screen shot attached to prove I'm not 
> lieing.
> 
>> If we take that literally that would be a GPT partition name, but
>> you've used this same terminology before and meant a filesystem
>> label.
>>
>>> My only question it will those partition names survive lvcreating an 
>>> 11T lvm
>>> out of these and 2 more 2T gigastones.
>>
>> Assuming you meant partition name the first time as well, nothing
>> you do other than a disk wipe or re-name should alter those
>> partition names.
>>
>> But your chosen partition names don't make a lot of sense to me.
>> You've picked names based on the type/manufacturer of device so you
>> may as well have just used the names from /dev/disk/by-id/… which
>> already have that information and are already never going to change.
>> I don't know why you want to complicate matters.
>>
>> If instead you put filesystems on these partitions and labelled
>> *those*, well, no, LVM goes under filesystems so those filesystems
>> and their labels (and contents) are not long for this world.
>>
>>> I have not dealt with an lvm in about 15+ years trying it once
>>> when it first came out with a high disaster rating then.
>>
>> I hope you are putting a level of redundancy under that LVM or are
>> using the redundancy features of LVM (which you need to go out of
>> your way to do). Otherwise by default what you'll have is not
>> redundant and a device failure will lose at least the contents of
>> that device, possibly more.
>>
You pique my curiosity because this is going to be my backup system, but 
not a syllable about how to do it. You tell me its fine 3 paragraphs up. 
then tell me lvcreate will wipe it out.  I'm asking for answers, not 
more connumdrums..
>> Regards,
>> Andy
>>
>> ¹ and while you are there, maybe a post-it note with "I will show
>>    the exact command I used any time I write to debian-user" stuck to
>>    the top of the display of the screen you use to compose emails
>>    would help, because basically every thread you post here lacks
>>    that information.
>>
> 
> Cheers, Gene Heskett, CET.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#267433

Hi,

On Wed, Feb 14, 2024 at 09:56:07PM -0500, gene heskett wrote:
> > On 2/14/24 19:48, Andy Smith wrote:
> > > I hope you are putting a level of redundancy under that LVM or are
> > > using the redundancy features of LVM (which you need to go out of
> > > your way to do). Otherwise by default what you'll have is not
> > > redundant and a device failure will lose at least the contents of
> > > that device, possibly more.
> > > 
> You pique my curiosity because this is going to be my backup system, but not
> a syllable about how to do it. You tell me its fine 3 paragraphs up. then
> tell me lvcreate will wipe it out.  I'm asking for answers, not more
> connumdrums..

You've split your reply to my mail across three different emails and
now you're replying to a part about redundancy, but asking questions
about something completely different, all while referring to bits
that are not proximal to where your text is, so it's unclear to me
exactly what you are asking about.

You asked if "labels" would survive their associated partition being
put into LVM.

I said, "yes if you mean partition names, no if you mean filesystem
labels".

To my implied question about your redundancy plans (if any), you
then complain that I have not given you "a syllable about how to do
it". Do *what*? I don't yet know what your plans are in that regard.
If you have questions, ask them.

Regards,
Andy

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

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

#267434

On Thu 15 Feb 2024 at 16:12:06 (+0000), Andy Smith wrote:
> On Wed, Feb 14, 2024 at 09:56:07PM -0500, gene heskett wrote:
> > > On 2/14/24 19:48, Andy Smith wrote:
> > > > I hope you are putting a level of redundancy under that LVM or are
> > > > using the redundancy features of LVM (which you need to go out of
> > > > your way to do). Otherwise by default what you'll have is not
> > > > redundant and a device failure will lose at least the contents of
> > > > that device, possibly more.
> > > > 
> > You pique my curiosity because this is going to be my backup system, but not
> > a syllable about how to do it. You tell me its fine 3 paragraphs up. then
> > tell me lvcreate will wipe it out.  I'm asking for answers, not more
> > connumdrums..
> 
> You've split your reply to my mail across three different emails and
> now you're replying to a part about redundancy, but asking questions
> about something completely different, all while referring to bits
> that are not proximal to where your text is, so it's unclear to me
> exactly what you are asking about.
> 
> You asked if "labels" would survive their associated partition being
> put into LVM.
> 
> I said, "yes if you mean partition names, no if you mean filesystem
> labels".
> 
> To my implied question about your redundancy plans (if any), you
> then complain that I have not given you "a syllable about how to do
> it". Do *what*? I don't yet know what your plans are in that regard.
> If you have questions, ask them.

I think the paste in
  https://lists.debian.org/debian-user/2024/02/msg00611.html
shows that SiPwr_1 is a filesystem LABEL, not a PARTLABEL,
lying as it does between an FSVER and a UUID.

Cheers,
David.

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

#267440

On 2/15/24 11:21, Andy Smith wrote:
> Hi,
> 
> On Wed, Feb 14, 2024 at 09:56:07PM -0500, gene heskett wrote:
>>> On 2/14/24 19:48, Andy Smith wrote:
>>>> I hope you are putting a level of redundancy under that LVM or are
>>>> using the redundancy features of LVM (which you need to go out of
>>>> your way to do). Otherwise by default what you'll have is not
>>>> redundant and a device failure will lose at least the contents of
>>>> that device, possibly more.
>>>>
>> You pique my curiosity because this is going to be my backup system, but not
>> a syllable about how to do it. You tell me its fine 3 paragraphs up. then
>> tell me lvcreate will wipe it out.  I'm asking for answers, not more
>> connumdrums..
> 
> You've split your reply to my mail across three different emails and
> now you're replying to a part about redundancy, but asking questions
> about something completely different, all while referring to bits
> that are not proximal to where your text is, so it's unclear to me
> exactly what you are asking about.
> 
> You asked if "labels" would survive their associated partition being
> put into LVM.
> 
> I said, "yes if you mean partition names, no if you mean filesystem
> labels".
> 
I'm still confused and it is not all the well clarified by looking at 
gparted, a shot of which I posted. Wikipedia seems to have the history 
but not the practice to the depth i'd like.

I also looked at XFS on wikipedia, looks good, but I note it says then 
linux version linux is not complete. 2 more of the big Si Pwr 3.64T's 
will be here tomorrow. So I'll be inclined to put it together and see 
what I can make it do.  There will no doubt be questions.

> To my implied question about your redundancy plans (if any), you
> then complain that I have not given you "a syllable about how to do
> it". Do *what*? I don't yet know what your plans are in that regard.
> If you have questions, ask them.
> 
Like which version of a raid is the best at tolerating a failed drive, 
which give he best balance between redundancy and capacity.

Take care & stay well, Andy.

> Regards,
> Andy
> 

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#267441

Hi,

On Thu, Feb 15, 2024 at 03:19:54PM -0500, gene heskett wrote:
> On 2/15/24 11:21, Andy Smith wrote:
> > You asked if "labels" would survive their associated partition being
> > put into LVM.
> > 
> > I said, "yes if you mean partition names, no if you mean filesystem
> > labels".
> > 
> I'm still confused and it is not all the well clarified by looking at
> gparted, a shot of which I posted.

This could all be answered easily if you'd just post the copy-paste
of your terminal scrollback for what you actually did. Hopefully you
don't now object to me asking what you meant since apparently even
you do not know if you mean partition names or filesystem labels.
>From what you posted it now sounds like labels on the ext4
filesystems that you created.

What you're trying to do (LVM on MD RAID?) is quite complicated and
you clearly don't have much experience in this area. That's okay but
it does mean that you're likely to make a lot of mistakes with a
thing that holds your data, so you need to be prepared for that.

For example, you mentioned only as an aside that you intended to get
two more drives and put the four of them into an LVM, but you did
not know that this would blow away the filesystems already on the
drives, and that this would not by itself provide you with any
redundancy. So if you hadn't said anything and I hadn't questioned
this, you could well have spent a lot of time creating something
that isn't correct and needs to be torn down again, possibly with
data loss.

Again that's okay — we learn by experimentation — but you're going
to have to prepare yourself for doing this over again many times.
And I also want to reiterate that you're going to have questions,
and that is good, but if we here on this list are not to be driven
insane by the ambiguities and misunderstandings, please, please,
PLEASE post logs of the commands you type on this adventure when you
ask them.

Please.

> > If you have questions, ask them.
> > 
> Like which version of a raid is the best at tolerating a failed drive, which
> give he best balance between redundancy and capacity.

This is a complex subject. Before we get into it, what are you
trying to achieve? Like, what is your end goal with these four
drives?

MD RAID isn't the only way to achieve redundancy. You also haven't
explained why you need LVM. Depending on your needs, maybe a
filesystem with redundancy and volume management features in it
would be better. Like btrfs or zfs.

Given the problems you had with MD RAID in the past I still maintain
that you'd likely be better off just getting a storage appliance of
some kind.

Thanks,
Andy

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

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

#267444

On Thu 15 Feb 2024 at 20:44:52 (+0000), Andy Smith wrote:
> On Thu, Feb 15, 2024 at 03:19:54PM -0500, gene heskett wrote:
> > On 2/15/24 11:21, Andy Smith wrote:
> > > You asked if "labels" would survive their associated partition being
> > > put into LVM.
> > > 
> > > I said, "yes if you mean partition names, no if you mean filesystem
> > > labels".
> > > 
> > I'm still confused and it is not all the well clarified by looking at
> > gparted, a shot of which I posted.
> 
> This could all be answered easily if you'd just post the copy-paste
> of your terminal scrollback for what you actually did. Hopefully you
> don't now object to me asking what you meant since apparently even
> you do not know if you mean partition names or filesystem labels.
> >From what you posted it now sounds like labels on the ext4
> filesystems that you created.

Gene effectively shoots himself in the foot by using gparted (GUI)
instead of, say, gdisk where it's easy to paste what was done, or
for someone, say me, to post an example:

  # gdisk /dev/sdz
  GPT fdisk (gdisk) version 1.0.3

  Partition table scan:
    MBR: not present
    BSD: not present
    APM: not present
    GPT: not present

  Creating new GPT entries.

  Command (? for help): o
  This option deletes all partitions and creates a new protective MBR.
  Proceed? (Y/N): y

  Command (? for help): p
  Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
  Model: Desktop         
  Sector size (logical/physical): 512/512 bytes
  Disk identifier (GUID): A1093790-9A1A-4A7E-A807-B9CC6F7CF77E
  Partition table holds up to 128 entries
  Main partition table begins at sector 2 and ends at sector 33
  First usable sector is 34, last usable sector is 3907029134
  Partitions will be aligned on 2048-sector boundaries
  Total free space is 3907029101 sectors (1.8 TiB)

  Number  Start (sector)    End (sector)  Size       Code  Name

  Command (? for help): n
  Partition number (1-128, default 1): 
  First sector (34-3907029134, default = 2048) or {+-}size{KMGTP}: 
  Last sector (2048-3907029134, default = 3907029134) or {+-}size{KMGTP}: 
  Current type is 'Linux filesystem'
  Hex code or GUID (L to show codes, Enter = 8300): 
  Changed type of partition to 'Linux filesystem'

  Command (? for help): c
  Using 1
  Enter name: Lulu01

  Command (? for help): i
  Using 1
  Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
  Partition unique GUID: 37CF9EDF-C695-428E-9889-2F52C40DFCA5
  First sector: 2048 (at 1024.0 KiB)
  Last sector: 3907029134 (at 1.8 TiB)
  Partition size: 3907027087 sectors (1.8 TiB)
  Attribute flags: 0000000000000000
  Partition name: 'Lulu01'

  Command (? for help): w

  Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
  PARTITIONS!!

  Do you want to proceed? (Y/N): y
  OK; writing new GUID partition table (GPT) to /dev/sdb.
  The operation has completed successfully.
  # 

  # gdisk -l /dev/sdz
  GPT fdisk (gdisk) version 1.0.3

  Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present

  Found valid GPT with protective MBR; using GPT.
  Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
  Model: Desktop         
  Sector size (logical/physical): 512/512 bytes
  Disk identifier (GUID): A1093790-9A1A-4A7E-A807-B9CC6F7CF77E
  Partition table holds up to 128 entries
  Main partition table begins at sector 2 and ends at sector 33
  First usable sector is 34, last usable sector is 3907029134
  Partitions will be aligned on 2048-sector boundaries
  Total free space is 2014 sectors (1007.0 KiB)

  Number  Start (sector)    End (sector)  Size       Code  Name
     1            2048      3907029134   1.8 TiB     8300  Lulu01
  # 

Cheers,
David.

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

#267456

On 2/15/24 16:20, David Wright wrote:
> On Thu 15 Feb 2024 at 20:44:52 (+0000), Andy Smith wrote:
>> On Thu, Feb 15, 2024 at 03:19:54PM -0500, gene heskett wrote:
>>> On 2/15/24 11:21, Andy Smith wrote:
>>>> You asked if "labels" would survive their associated partition being
>>>> put into LVM.
>>>>
>>>> I said, "yes if you mean partition names, no if you mean filesystem
>>>> labels".
>>>>
>>> I'm still confused and it is not all the well clarified by looking at
>>> gparted, a shot of which I posted.
>>
>> This could all be answered easily if you'd just post the copy-paste
>> of your terminal scrollback for what you actually did. Hopefully you
>> don't now object to me asking what you meant since apparently even
>> you do not know if you mean partition names or filesystem labels.
>> >From what you posted it now sounds like labels on the ext4
>> filesystems that you created.
> 
> Gene effectively shoots himself in the foot by using gparted (GUI)
> instead of, say, gdisk where it's easy to paste what was done, or
> for someone, say me, to post an example:
> 
>    # gdisk /dev/sdz
>    GPT fdisk (gdisk) version 1.0.3
> 
>    Partition table scan:
>      MBR: not present
>      BSD: not present
>      APM: not present
>      GPT: not present
> 
>    Creating new GPT entries.
> 
>    Command (? for help): o
>    This option deletes all partitions and creates a new protective MBR.
>    Proceed? (Y/N): y
> 
>    Command (? for help): p
>    Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
>    Model: Desktop
>    Sector size (logical/physical): 512/512 bytes
>    Disk identifier (GUID): A1093790-9A1A-4A7E-A807-B9CC6F7CF77E
>    Partition table holds up to 128 entries
>    Main partition table begins at sector 2 and ends at sector 33
>    First usable sector is 34, last usable sector is 3907029134
>    Partitions will be aligned on 2048-sector boundaries
>    Total free space is 3907029101 sectors (1.8 TiB)
> 
>    Number  Start (sector)    End (sector)  Size       Code  Name
> 
>    Command (? for help): n
>    Partition number (1-128, default 1):
>    First sector (34-3907029134, default = 2048) or {+-}size{KMGTP}:
>    Last sector (2048-3907029134, default = 3907029134) or {+-}size{KMGTP}:
>    Current type is 'Linux filesystem'
>    Hex code or GUID (L to show codes, Enter = 8300):
>    Changed type of partition to 'Linux filesystem'
> 
>    Command (? for help): c
>    Using 1
>    Enter name: Lulu01
> 
>    Command (? for help): i
>    Using 1
>    Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
>    Partition unique GUID: 37CF9EDF-C695-428E-9889-2F52C40DFCA5
>    First sector: 2048 (at 1024.0 KiB)
>    Last sector: 3907029134 (at 1.8 TiB)
>    Partition size: 3907027087 sectors (1.8 TiB)
>    Attribute flags: 0000000000000000
>    Partition name: 'Lulu01'
> 
>    Command (? for help): w
> 
>    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
>    PARTITIONS!!
> 
>    Do you want to proceed? (Y/N): y
>    OK; writing new GUID partition table (GPT) to /dev/sdb.
>    The operation has completed successfully.
>    #
> 
>    # gdisk -l /dev/sdz
>    GPT fdisk (gdisk) version 1.0.3
> 
>    Partition table scan:
>      MBR: protective
>      BSD: not present
>      APM: not present
>      GPT: present
> 
>    Found valid GPT with protective MBR; using GPT.
>    Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
>    Model: Desktop
>    Sector size (logical/physical): 512/512 bytes
>    Disk identifier (GUID): A1093790-9A1A-4A7E-A807-B9CC6F7CF77E
>    Partition table holds up to 128 entries
>    Main partition table begins at sector 2 and ends at sector 33
>    First usable sector is 34, last usable sector is 3907029134
>    Partitions will be aligned on 2048-sector boundaries
>    Total free space is 2014 sectors (1007.0 KiB)
> 
>    Number  Start (sector)    End (sector)  Size       Code  Name
>       1            2048      3907029134   1.8 TiB     8300  Lulu01
>    #
> 
> Cheers,
> David.
> 
> .
And this "partition" name survives?, and can be unique?, and can be used 
in a mount cmd?  That's how I'll do it then.  This if all 3 questions 
above can be answered with a yes is the answer I've been trying to 
squeeze out all along.  Thank you.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#267474

Hi,

On Fri, Feb 16, 2024 at 01:32:26AM -0500, gene heskett wrote:
> On 2/15/24 16:20, David Wright wrote:
> >    # gdisk -l /dev/sdz
> >    GPT fdisk (gdisk) version 1.0.3
> > 
> >    Partition table scan:
> >      MBR: protective
> >      BSD: not present
> >      APM: not present
> >      GPT: present
> > 
> >    Found valid GPT with protective MBR; using GPT.
> >    Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
> >    Model: Desktop
> >    Sector size (logical/physical): 512/512 bytes
> >    Disk identifier (GUID): A1093790-9A1A-4A7E-A807-B9CC6F7CF77E
> >    Partition table holds up to 128 entries
> >    Main partition table begins at sector 2 and ends at sector 33
> >    First usable sector is 34, last usable sector is 3907029134
> >    Partitions will be aligned on 2048-sector boundaries
> >    Total free space is 2014 sectors (1007.0 KiB)
> > 
> >    Number  Start (sector)    End (sector)  Size       Code  Name
> >       1            2048      3907029134   1.8 TiB     8300  Lulu01
> >    #
> > .
> And this "partition" name survives?

No, because it's a filesystem label for the ext4 fs created on
/dev/sdz1. If sdz1 is turned into an LVM Physical Volume, there
won't be an ext4 filesystem on it any more. If sdz1 is turned into a
member of an MD array, there won't be an ext4 filesystem on it any
more. The labels go with the filesystem.

> and can be unique?

I don't know what that means to you or why it is useful.

> and can be used in a mount cmd?

Once the RAID and/or LVM is set up and a filesystem put on it, that
filesystem can be mounted by label just like any filesystem can, but
that filesystem may have multiple devices underneath it owing to the
fact that it's on RAID and/or LVM, so there is no information you
can put in its label that will tell you anything about those
underlying devices.

> if all 3 questions above can be answered with a yes is the answer
> I've been trying to squeeze out all along.

You've not yet been clear about what you want, but from what little
information you have provided you've been told multiple times by
multiple people that filesystem labels won't help.

Thanks,
Andy

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

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

#267513

Hello,

On Fri, Feb 16, 2024 at 02:02:59PM -0600, David Wright wrote:
> On Fri 16 Feb 2024 at 14:48:12 (+0000), Andy Smith wrote:
> > No, because it's a filesystem label for the ext4 fs created on
> > /dev/sdz1. If sdz1 is turned into an LVM Physical Volume, there
> > won't be an ext4 filesystem on it any more. If sdz1 is turned into a
> > member of an MD array, there won't be an ext4 filesystem on it any
> > more. The labels go with the filesystem.
> 
> It isn't a filesystem LABEL.

Oh dear, I am lost. I don't use gparted but at least one person in
this thread has said that Gene created a filesystem label not a
partition name, and Gene doesn't know which he created, so I've gone
from guessing partition name to fs label and now back to partition
name again.

I'm totally willing to believe that you know what you've created
there though, so fair enough.

> > You've not yet been clear about what you want, but from what little
> > information you have provided you've been told multiple times by
> > multiple people that filesystem labels won't help.
>                        ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
> 
> … which would be moot if only Gene could create partition PARTLABELs
> successfully.

Sure, but we still don't know what Gene is trying to do or why
partition names would be useful to him so I am kind of sceptical
that this leads anywhere.

Thanks,
Andy

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

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

#267524

On 2/16/24 21:13, Andy Smith wrote:
> Hello,
> 
> On Fri, Feb 16, 2024 at 02:02:59PM -0600, David Wright wrote:
>> On Fri 16 Feb 2024 at 14:48:12 (+0000), Andy Smith wrote:
>>> No, because it's a filesystem label for the ext4 fs created on
>>> /dev/sdz1. If sdz1 is turned into an LVM Physical Volume, there
>>> won't be an ext4 filesystem on it any more. If sdz1 is turned into a
>>> member of an MD array, there won't be an ext4 filesystem on it any
>>> more. The labels go with the filesystem.
>>
>> It isn't a filesystem LABEL.
> 
> Oh dear, I am lost. I don't use gparted but at least one person in
> this thread has said that Gene created a filesystem label not a
> partition name, and Gene doesn't know which he created, so I've gone
> from guessing partition name to fs label and now back to partition
> name again.
> 
> I'm totally willing to believe that you know what you've created
> there though, so fair enough.
> 
>>> You've not yet been clear about what you want, but from what little
>>> information you have provided you've been told multiple times by
>>> multiple people that filesystem labels won't help.
>>                         ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
>>
>> … which would be moot if only Gene could create partition PARTLABELs
>> successfully.
> 
> Sure, but we still don't know what Gene is trying to do or why
> partition names would be useful to him so I am kind of sceptical
> that this leads anywhere.
> 
That part if the ^%$ drives ever get here, I just looked at the front 
deck and it has 2" of fresh white stuff on it.

To describe what I am building, this is a 5 slot bare drive cage. You 
could throw tom cats thru it from most angles so I printed pretty sides 
for it.

I've printed drawers to fill those slots.  The top slot has a bpi-m5 in 
it, the bottom slot has a 5 volt 10 amp psu in it. slot 2 will have 2 of 
those nearly 4T SSD's in a 2 drive adapter, with full disk partitions on 
them, so obviously I should name the top one as "si-pwr-s2t". the bottom 
one then s/b si-pwr-s2b
slot-3 then s/b si-pwr-s3t and si-pwr-s3b.
slot-4 then is giga-s4t1 and giga-s4t2. ditto for the bottom one. named 
giga-s4b1 and giga-s4b2.  1 partition to hold amanda's database and one 
to serve as amanda's holding disk.

Whats so meaningless to you that you can't see the utility in that? 
That has not been explained, so please educate me as to why you think 
its worthless?
> Thanks,
> Andy
> 

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#267530

On Sat, Feb 17, 2024 at 12:47 AM gene heskett <gheskett@shentel.net> wrote:
>
> On 2/16/24 21:13, Andy Smith wrote:
> > [...]
> > Sure, but we still don't know what Gene is trying to do or why
> > partition names would be useful to him so I am kind of sceptical
> > that this leads anywhere.
> >
> That part if the ^%$ drives ever get here, I just looked at the front
> deck and it has 2" of fresh white stuff on it.

Lol... More irrelevant chatter. Andy asked what you are trying to
accomplish, and you replied with your weather. It would be brilliant
comedy if it was not so sad to watch this thread torture the folks who
are trying to help you.

Painting with a broad brush, there are two types of people in the
world - those who listen, and those who wait to talk. I am pretty sure
you are one of those who wait to talk. It would behoove you to listen
more, talk less, and answer the questions that are asked of you. If
you don't, then folks like Andy, David and Max are not going to help
you.

Jeff

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

#267532 — Of irrelevant chatter and meta-chatter [was: f3tools vs Silicon Power 4T drive]

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

On Sat, Feb 17, 2024 at 01:32:29AM -0500, Jeffrey Walton wrote:
> On Sat, Feb 17, 2024 at 12:47 AM gene heskett <gheskett@shentel.net> wrote:

[...]

> > That part if the ^%$ drives ever get here, I just looked at the front
> > deck and it has 2" of fresh white stuff on it.
> 
> Lol... More irrelevant chatter [...]

[rest of irrelevant meta-chatter elided]

...and you are amplifying exactly what you're criticising.

Somehow this eminds one of DNS DDOS [1] attacks :-)

Cheers

[1] https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_DoS_attack
-- 
t

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web