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

#267543

Hi,

On Sat, Feb 17, 2024 at 12:46:25AM -0500, gene heskett wrote:

[38 lines of irrelevance snipped out of a 71 line email]

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

I've got no issue with putting a drive identifier on the physical
caddy/drawer that holds that drive. I do it myself. You have not
ever before in this thread mentioned this, so neither I nor anyone
else has objected to it.

What I question the value of, is putting a drive identifier into a
partlabel when the id of the partition will contain all of the same
information.

I have also asked you several times what it is you intend to do
with that information in the context of a RAID array or LVM LV and
you haven't yet been able to tell me. The closest you have come so
far is saying, "I want to identify a drive when the array has
problems". As you don't specify what those problems might be, all I
am able to say to that is that you can either find the problem
device from your logs or by listing the devices in the array/LV, and
from there map to exact model and serial number from what's in the
/dev/disk/by-id/.

Now, I understand that you have multiple drives that have the same
model and serial number. I accept that if you're going to use
multiple of these in the same machine then that makes using by-id/
impossible. I've advised that I would never use multiple of these in
the same machine because they are broken and will likely cause other
problems further down the line.

So if you want to say: despite the duplicate serial number issue I
am determined to use multiple of these drives, so by-id/ is useless
to me and I will instead replicate that info in partlabels and use
/dev/disk/by-partlabel/, then okay! I don't agree with that course
of action, but it is at least a cogent argument. So say if that's
the case and we can just move on.

Thanks,
Andy

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

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

#267554

On 2/17/24 00:47, gene heskett wrote:
> 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.

Which I have found can also be done with gparted, so the 1st 2 drives 
which will be put in slot 2 as the Top and Bottom drives in that 2 drive 
adaptor in slot 2, have had their partitions labeled as SIPWRS2T and 
SIPWRS2B. And labeled as such with a P-Touch. The other 2 that just 
walked in the door, are still cold enough to sweat if unsealed.

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

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]

#267497

On Fri 16 Feb 2024 at 01:32:26 (-0500), gene heskett wrote:
> 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:

[ … skipped over creating the partition table … ]

> >    # 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?, 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.

Yes, the partition name (PARTLABEL) is in the partition table, not
inside the partition itself. It's as unique as you make it, because
you choose it. I've scrawled the names of my disks on the casing with
a magic marker for 25 years, from adam (6.4GB fujitsu) to wick (2TB WD).
The PARTLABELs and LABELs use that name as the stem, capitalised and
lowercase respectively.

As for using it with the mount command, that depends on what the
partition contains. For a straightforward filesystem, you can, as
described by   man mount (under Indicating the device and filesystem).

But I wouldn't, and I don't think you want to, as I believe you want
to use the partition as /part/ of something larger.

Whether you /can/ use it to mount depends on what the partition
contains. I don't use LVM or RAID, so I can't advise you there, except
to say that you wouldn't want to mount one piece of a larger structure,
AFAIK. But in my case, I use LUKS encryption, and I can demonstrate
what happens:

  $ sudo udisksctl unlock --block-device /dev/disk/by-partlabel/Lulu01
  Passphrase: 
  Unlocked /dev/sdc1 as /dev/dm-2.
  $ 

  # mount /dev/disk/by-partlabel/Lulu01 /media/lulu01
  mount: /media/lulu01: unknown filesystem type 'crypto_LUKS'.
  # 

You don't want to mount the partition, but the filesystem /within/ the
partition:

  # mount LABEL=lulu01 /media/lulu01
  # 

Of course, I don't normally use mount as root because I have an entry
in /etc/fstab:

  LABEL=lulu01 /media/lulu01 ext4 rw,errors=remount-ro,user,noauto

and I use a bash function called, surprisingly, lulu, as there's only
one partition on the disk:

  $ type lulu
  lulu is a function
  lulu () 
  { 
    sudo udisksctl unlock --block-device /dev/disk/by-partlabel/Lulu01 && mount /media/lulu01
  }
  $ 

thus:

  $ lulu
  Passphrase: 
  Unlocked /dev/sdc1 as /dev/dm-2.
  $ 

But I would emphasise that, having unlocked the partition, I mount
the filesystem because it stands alone. It's not part of a RAID,
LVM, or whatever, that might need assembling with other components
before mounting the whole ensemble.

Cheers,
David.

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

#267445

On 2/15/24 15:45, Andy Smith wrote:
> 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.
> 
That is how we learn Andy  Any data I put on this stuff while testing 
as normal files will be expected to be lost.  So that possibility is 
expected. Experience is how I got where I am on an 8th grade education.

> Again that's okay — we learn by experimentation — but you're going
> to have to prepare yourself for doing this over again many times.

Expected.

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

I'll try.

> Please.
> 
>>> If you have questions, ask them.

When I get it assembled. Last 2 drives s/b here tom. Then I need to shut 
down and extract 4 of the gisastones which are plugged in atm but 
unmounted, the 5th one is now my /home partition. And I am rsync'ing 
/home back to that now idle raid10 about every other day.

>> 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
> 
Thank you 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]

#267447

On 2/15/24 15:45, Andy Smith wrote:
> 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.
May I miss-understood the wiki, xfs is stated as not being complete for 
linux, a zfx is I think commercial?
Can you update that?


> 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.
One of the 1T samsungs in the md raid10 isn't entirely happy but mdadm 
has not fussed about it, and smartctl seems to say its ok after testing. 
  Other than that the gui access delay (30+ seconds) problems I have did 
NOT go away when I moved /home off the raid to another SSD, so I may 
move it back. One of the reasons I ma rsync'ing this /home back to it 
every other day or so, takes < 5 minutes.
> 
> 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]

#267464

gene heskett <gheskett@shentel.net> wrote:
> On 2/15/24 15:45, Andy Smith wrote:
> 
> > 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.  
> May I miss-understood the wiki, xfs is stated as not being complete
> for linux, a zfx is I think commercial?
> Can you update that?

Sorry, which wiki page do you think says XFS is not complete?

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

#267479

On 2/16/24 07:46, debian-user@howorth.org.uk wrote:
> gene heskett <gheskett@shentel.net> wrote:
>> On 2/15/24 15:45, Andy Smith wrote:
>>
>>> 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.
>> May I miss-understood the wiki, xfs is stated as not being complete
>> for linux, a zfx is I think commercial?
>> Can you update that?
> 
> Sorry, which wiki page do you think says XFS is not complete?
> 
> .
I wasn't awake enough to bookmark it. I'm not done with wiki yet, if I 
run across it again I'll post the link.

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]

#267477

Hi,

On Thu, Feb 15, 2024 at 08:44:26PM -0500, gene heskett wrote:
> On 2/15/24 15:45, Andy Smith wrote:
> > 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.
> May I miss-understood the wiki, xfs is stated as not being complete for
> linux, a zfx is I think commercial?
> Can you update that?

I'd rather not try to explain XFS and ZFS to you when it's not even
clear what you're trying to achieve. In all likelihood you will not
need to use either XFS or ZFS.

Also we can't correct a wiki article without knowing what it is…

> the gui access delay (30+ seconds) problems I have did NOT go away
> when I moved /home off the raid to another SSD

More evidence that those problems had nothing to do with RAID or the
storage devices you used in your RAID, but is something broken in
your desktop software setup. Unfortunately I have no idea how to
debug that.

Thanks,
Andy

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

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

#267498

On 2/15/24 17:44, gene heskett wrote:
> One of the 1T samsungs in the md raid10 isn't entirely happy but mdadm 
> has not fussed about it, and smartctl seems to say its ok after testing. 
>   Other than that the gui access delay (30+ seconds) problems I have did 
> NOT go away when I moved /home off the raid to another SSD, so I may 
> move it back. One of the reasons I ma rsync'ing this /home back to it 
> every other day or so, takes < 5 minutes.


Please get a small SSD, do a fresh install, and test for the access 
delay.  If the delay is not present, incrementally add and test 
applications.  If you encounter the delay, please stop and post the 
details; console sessions are best.  If not, then connect the disks with 
/home and test.  If you encounter the delay, then please stop and post 
the details.  If you do not encounter the delay, then your system is 
fixed.  Take a Clonezilla image.


David

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

#267501

>> One of the 1T samsungs in the md raid10 isn't entirely happy but mdadm has
>> not fussed about it, and smartctl seems to say its ok after testing.
>>  Other than that the gui access delay (30+ seconds) problems I have did
>> NOT go away when I moved /home off the raid to another SSD, so I may move
>> it back. One of the reasons I ma rsync'ing this /home back to it every
>> other day or so, takes < 5 minutes.
> Please get a small SSD, do a fresh install, and test for the access delay.
> If the delay is not present, incrementally add and test applications.
> If you encounter the delay, please stop and post the details; console
> sessions are best.  If not, then connect the disks with /home and test.
> If you encounter the delay, then please stop and post the details.  If you
> do not encounter the delay, then your system is fixed.
> Take a Clonezilla image.

FWIW, my crystal ball says "30s => software timeout rather than hardware
problem"


        Stefan

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

#267504

On 2/16/24 12:46, Stefan Monnier wrote:
>>> One of the 1T samsungs in the md raid10 isn't entirely happy but mdadm has
>>> not fussed about it, and smartctl seems to say its ok after testing.
>>>   Other than that the gui access delay (30+ seconds) problems I have did
>>> NOT go away when I moved /home off the raid to another SSD, so I may move
>>> it back. One of the reasons I ma rsync'ing this /home back to it every
>>> other day or so, takes < 5 minutes.
>> Please get a small SSD, do a fresh install, and test for the access delay.
>> If the delay is not present, incrementally add and test applications.
>> If you encounter the delay, please stop and post the details; console
>> sessions are best.  If not, then connect the disks with /home and test.
>> If you encounter the delay, then please stop and post the details.  If you
>> do not encounter the delay, then your system is fixed.
>> Take a Clonezilla image.
> 
> FWIW, my crystal ball says "30s => software timeout rather than hardware
> problem"


+1


David

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

#267505

On 2/16/24 15:47, Stefan Monnier wrote:
>>> One of the 1T samsungs in the md raid10 isn't entirely happy but mdadm has
>>> not fussed about it, and smartctl seems to say its ok after testing.
>>>   Other than that the gui access delay (30+ seconds) problems I have did
>>> NOT go away when I moved /home off the raid to another SSD, so I may move
>>> it back. One of the reasons I ma rsync'ing this /home back to it every
>>> other day or so, takes < 5 minutes.
>> Please get a small SSD, do a fresh install, and test for the access delay.
>> If the delay is not present, incrementally add and test applications.
>> If you encounter the delay, please stop and post the details; console
>> sessions are best.  If not, then connect the disks with /home and test.
>> If you encounter the delay, then please stop and post the details.  If you
>> do not encounter the delay, then your system is fixed.
>> Take a Clonezilla image.
> 
> FWIW, my crystal ball says "30s => software timeout rather than hardware
> problem"
> 
> 
>          Stefan

We are on the same page, but what is causing the timeout?
> .

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]

#267546

gene heskett <gheskett@shentel.net> wrote:
> On 2/16/24 15:47, Stefan Monnier wrote:
> >>> One of the 1T samsungs in the md raid10 isn't entirely happy but
> >>> mdadm has not fussed about it, and smartctl seems to say its ok
> >>> after testing. Other than that the gui access delay (30+ seconds)
> >>> problems I have did NOT go away when I moved /home off the raid
> >>> to another SSD, so I may move it back. One of the reasons I ma
> >>> rsync'ing this /home back to it every other day or so, takes < 5
> >>> minutes.  
> >> Please get a small SSD, do a fresh install, and test for the
> >> access delay. If the delay is not present, incrementally add and
> >> test applications. If you encounter the delay, please stop and
> >> post the details; console sessions are best.  If not, then connect
> >> the disks with /home and test. If you encounter the delay, then
> >> please stop and post the details.  If you do not encounter the
> >> delay, then your system is fixed. Take a Clonezilla image.  
> > 
> > FWIW, my crystal ball says "30s => software timeout rather than
> > hardware problem"
> > 
> > 
> >          Stefan  
> 
> We are on the same page, but what is causing the timeout?

You have to follow the steps David suggested including posting the
details here as asked, before anybody will be able to answer your
question!

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

#267514

Hello,

On Fri, Feb 16, 2024 at 03:46:54PM -0500, Stefan Monnier wrote:
> FWIW, my crystal ball says "30s => software timeout rather than hardware
> problem"

Back in a previous thread Gene was saying that it's only evident
when some GUI app brings up a file requester to load or save
something so that was my thought too. In particular that it might be
doing some kind of failed network activity looking for network
shares or something.

The thing is, we've also seen Gene's computers with strange things
like syntax errors in /etc/nsswitch.conf and /etc/hosts, avahi bits
manually rm'd, resolv.conf whacked with chattr +i and so on, so
it's also no surprise to me that this is difficult to debug.

David's suggestion of starting with a minimal install might be the
only way to do it.

Thanks,
Andy

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

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

#267523

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

On Fri, Feb 16, 2024 at 03:46:54PM -0500, Stefan Monnier wrote:

[...]

> FWIW, my crystal ball says "30s => software timeout rather than hardware
> problem"

and whithin that, a network thingy. Ah, were it 90s, it'd be a DNS thingy.
But 30s...

Cheers
-- 
t

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

#267522

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

On Fri, Feb 16, 2024 at 12:12:06PM -0800, David Christensen wrote:
> On 2/15/24 17:44, gene heskett wrote:

[...]

> >  Other than that the gui access delay (30+ seconds) problems I have did
> > NOT go away when I moved /home off the raid to another SSD [...]

I think at this point few are surprised by that. Last round of debugging
we pretty much eliminated disk access as likey cause of those delays.

The most hopeful cause for a candidate, IIRC, was some thingy deep in the DE
trying to access an unavailable resource.

Cheers
-- 
t

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

#267553

On 2/17/24 00:35, tomas@tuxteam.de wrote:
> On Fri, Feb 16, 2024 at 12:12:06PM -0800, David Christensen wrote:
>> On 2/15/24 17:44, gene heskett wrote:
> 
> [...]
> 
>>>   Other than that the gui access delay (30+ seconds) problems I have did
>>> NOT go away when I moved /home off the raid to another SSD [...]
> 
> I think at this point few are surprised by that. Last round of debugging
> we pretty much eliminated disk access as likey cause of those delays.
> 
> The most hopeful cause for a candidate, IIRC, was some thingy deep in the DE
> trying to access an unavailable resource.
> 
> Cheers
Is there some way to identify that roadblock?

It sure seems to me there ought to be a way to identify whatever it is 
that is causing it..

Take care, stay warm and well Tomas

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]

#267563

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

On Sat, Feb 17, 2024 at 07:59:52PM -0500, gene heskett wrote:
> On 2/17/24 00:35, tomas@tuxteam.de wrote:
> > On Fri, Feb 16, 2024 at 12:12:06PM -0800, David Christensen wrote:
> > > On 2/15/24 17:44, gene heskett wrote:
> > 
> > [...]
> > 
> > > >   Other than that the gui access delay (30+ seconds) problems I have did
> > > > NOT go away when I moved /home off the raid to another SSD [...]
> > 
> > I think at this point few are surprised by that. Last round of debugging
> > we pretty much eliminated disk access as likey cause of those delays.
> > 
> > The most hopeful cause for a candidate, IIRC, was some thingy deep in the DE
> > trying to access an unavailable resource.
> > 
> > Cheers
> Is there some way to identify that roadblock?
> 
> It sure seems to me there ought to be a way to identify whatever it is that
> is causing it..

No single path, alas. The most pin-pointed description we have is some
editor blocking while trying to "open a file" (whatever those gooey
thingies do in that situation). So perhaps stracing it and seeing whether
it's blocking in a system call might give a clue.

Wading through the logs around that delay might, too. One trick I sometimes
use in those cases is to have a teminal open and create syslog messages
(with logger) to have timestamps marking the start/end of the perceived
delays.

> Take care, stay warm and well Tomas

First signs of spring around here.

Take care
-- 
tomás

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

#267492

On 2/15/24 12:19, gene heskett wrote:
> On 2/15/24 11:21, Andy Smith wrote:
>> ... redundancy plans ...
>>
> Like which version of a raid is the best at tolerating a failed drive, 
> which give he best balance between redundancy and capacity.


Given a small number of disks, N (say, 4 to 8), the obvious choices are 
RAID5, RAID6, and RAID10.


Regarding redundancy:

* RAID5 can tolerate the loss of any one disk.

* RAID6 can tolerate the loss of any two disks.

* RAID10 can tolerate the loss of any one disk.  If you get lucky, 
RAID10 can tolerate the loss of multiple disks if each lost disk is in a 
different mirror.


Regarding capacity, if each disk stores B bytes:

* RAID5 gives you (N-1) * B capacity.

* RAID6 gives you (N-2) * B capacity.

* RAID10 gives you (N/2) * B capacity.


If each disk has performance P:

* RAID5 has performance ranging from P to (N-1) * P.

* RAID6 has performance ranging from P to (N-2) * P.

* RAID10 with M mirrors of D disks each has write performance M * P and 
read performance M * D * P.


Other factors to consider:

* All of the above needs to be reconsidered when one or more disks fail 
-- e.g. the array is operating in degraded mode.

* All of the above needs to be reconsidered when a failed disk has been 
replaced -- e.g. the array is resilvering.

* All of the above needs to be reconsidered when disk(s) fail during 
resilvering (!).

* RAID5 and RAID6 typically do not allow changes to topology -- e.g. the 
number of disks in the array and the number of bytes used in each disk.

* RAID0, RAID1, and JBOD may allow some changes to topology.  What is 
allowed depends upon implementation.

* With more disks, you may be able to create hierarchies -- e.g. stripe 
of mirrors (RAID10).  Redundancy, capacity, and/or performance under 
operational, degraded, resilvering, etc., modes all need to be reconsidered.

* Hot spares can be added.  Again, reconsider everything.

* And more.


So, it's a multi-dimensional problem and there are many combinations and 
permutations.  The more disks you have, the more possibilities you have. 
  I suggest picking two or three, and exploring them using a dedicated 
computer, a snapshot of your data, and your workload.


I am currently using ZFS and a stripe of 2 mirrors with 2 @ 3 TB HDD's 
each and SSD read cache.  I expect the same could be implemented with 
mdadm(8), lvm(8), bcache, dm-cache, btrfs, and others.


David

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

#267432

Hi,

On Wed, Feb 14, 2024 at 08:48:31PM -0500, 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"

Okay, thanks for clarifying. This, or preferably a copy-paste of the
actual parted command session would suffice.

I don't know what the relevance is of the rest of the following
paragraph - your life story is not required and you were not accused
of lying, just asked to clarify.

Do remember that this mailing lists does not accept attachments (and
very few mailing lists in general do), so any time you are tempted
to send a photo to a mailing list it is probably an error. We did
not see whatever it was, but it doesn't sound relevant.

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

Regards,
Andy

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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web