Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #265863 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2024-01-13 03:50 +0100 |
| Last post | 2024-01-19 21:10 +0100 |
| Articles | 20 on this page of 167 — 25 participants |
Back to article view | Back to linux.debian.user
smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 03:50 +0100
Re: smartctl cannot access my storage, need syntax help "Gareth Evans" <donotspam@fastmail.fm> - 2024-01-13 04:00 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-13 04:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 06:00 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-13 16:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 18:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-13 18:30 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-13 19:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-14 00:30 +0100
Re: smartctl cannot access my storage, need syntax help Steve McIntyre <steve@einval.com> - 2024-01-14 14:40 +0100
Re: smartctl cannot access my storage, need syntax help Nicolas George <george@nsup.org> - 2024-01-14 11:40 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-14 17:30 +0100
Re: smartctl cannot access my storage, need syntax help Charles Curley <charlescurley@charlescurley.com> - 2024-01-13 06:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-14 13:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-14 20:50 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-15 01:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 02:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 14:50 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-15 19:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 23:00 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-15 21:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 00:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 01:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 01:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 00:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 01:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 01:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 02:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 03:20 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-16 04:00 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 07:00 +0100
Re: smartctl cannot access my storage, need syntax help Tom Furie <tom@furie.org.uk> - 2024-01-16 09:20 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 12:10 +0100
Re: smartctl cannot access my storage, need syntax help Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-16 13:40 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-17 01:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 03:00 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-16 16:00 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-16 15:10 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 15:40 +0100
Re: smartctl cannot access my storage, need syntax help Greg Wooledge <greg@wooledge.org> - 2024-01-16 15:50 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-17 01:20 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-16 17:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 03:20 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 07:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 15:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 18:10 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 18:30 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 20:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:40 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 22:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 22:40 +0100
normally start new xterms [was: Re: smartctl cannot access my storage, need syntax help] Max Nikulin <manikulin@gmail.com> - 2024-01-18 17:40 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-18 20:10 +0100
Re: normally start new xterms conover@panix.com (John Conover) - 2024-01-18 20:20 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-18 21:20 +0100
Re: normally start new xterms conover@panix.com (John Conover) - 2024-01-18 21:40 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 06:50 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 09:10 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 10:20 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 10:40 +0100
Re: normally start new xterms "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 09:10 +0100
Re: normally start new xterms David Wright <deblis@lionunicorn.co.uk> - 2024-01-19 18:10 +0100
Re: normally start new xterms Henning Follmann <hfollmann@itcfollmann.com> - 2024-01-19 15:20 +0100
Re: normally start new xterms <tomas@tuxteam.de> - 2024-01-19 16:10 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-18 04:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 22:20 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 08:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 16:40 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 17:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 22:10 +0100
Re: smartctl cannot access my storage, need syntax help Curt <curty@free.fr> - 2024-01-17 17:40 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-17 18:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 22:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 01:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 02:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 05:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 07:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 07:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 10:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-18 12:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-18 22:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-19 07:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-19 08:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-19 22:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-20 01:20 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-20 02:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-20 06:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-20 08:00 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-20 16:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-20 21:30 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-21 06:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-21 07:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-21 12:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-21 22:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-21 23:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-22 00:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-22 06:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-22 10:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-22 12:30 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-22 19:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-22 20:40 +0100
Re: smartctl cannot access my storage, need syntax help Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 22:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-23 00:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 03:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-23 04:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 05:00 +0100
Powered USB hub [was: Re: smartctl cannot access my storage, need syntax help] Max Nikulin <manikulin@gmail.com> - 2024-01-23 05:20 +0100
Re: Powered USB hub [was: Re: smartctl cannot access my storage, needsyntax help] gene heskett <gheskett@shentel.net> - 2024-01-23 06:10 +0100
Re: Powered USB hub [was: Re: smartctl cannot access my storage, need syntax help] Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-25 11:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-23 08:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:10 +0100
Re: smartctl cannot access my storage, need syntax help Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-23 04:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:50 +0100
Re: smartctl cannot access my storage, need syntax help Karl Vogel <vogelke@pobox.com> - 2024-01-23 06:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:10 +0100
Re: smartctl cannot access my storage, need syntax help Gremlin <scott-andrews@columbus.rr.com> - 2024-01-23 12:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-23 12:40 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-25 15:10 +0100
Re: smartctl cannot access my storage, need syntax help "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-01-25 18:20 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-26 12:50 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-29 06:20 +0100
Re: smartctl cannot access my storage, need syntax help Karl Vogel <vogelke@pobox.com> - 2024-01-24 09:30 +0100
Re: smartctl cannot access my storage, need syntax help Max Nikulin <manikulin@gmail.com> - 2024-01-21 10:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-21 18:40 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-19 05:10 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-18 08:40 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-19 09:20 +0100
Re: smartctl cannot access my storage, need syntax help "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 11:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-19 13:10 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-19 13:00 +0100
Re: smartctl cannot access my storage, need syntax help Curt <curty@free.fr> - 2024-01-18 17:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 21:20 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-17 18:10 +0100
Re: smartctl cannot access my storage, need syntax help Charles Curley <charlescurley@charlescurley.com> - 2024-01-18 08:20 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 02:10 +0100
Re: smartctl cannot access my storage, need syntax help David Wright <deblis@lionunicorn.co.uk> - 2024-01-17 03:00 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-17 05:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-15 08:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 15:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-15 23:00 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-16 00:40 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 00:50 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 07:10 +0100
Re: smartctl cannot access my storage, need syntax help Felix Miata <mrmazda@earthlink.net> - 2024-01-16 07:20 +0100
Re: smartctl cannot access my storage, need syntax help Andy Smith <andy@strugglers.net> - 2024-01-16 17:40 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 02:50 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-17 02:30 +0100
Re: smartctl cannot access my storage, need syntax help gene heskett <gheskett@shentel.net> - 2024-01-15 17:10 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 00:10 +0100
Re: smartctl cannot access my storage, need syntax help Franco Martelli <martellif67@gmail.com> - 2024-01-16 21:00 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-16 22:10 +0100
To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Andy Smith <andy@strugglers.net> - 2024-01-16 22:40 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Steve McIntyre <steve@einval.com> - 2024-01-18 02:00 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) gene heskett <gheskett@shentel.net> - 2024-01-18 04:40 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-18 17:30 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Andy Smith <andy@strugglers.net> - 2024-01-18 18:10 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Andy Smith <andy@strugglers.net> - 2024-01-18 15:20 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannot access my storage, need syntax help) Steve McIntyre <steve@einval.com> - 2024-01-18 17:10 +0100
Re: mdraid construction and testing (was: smartctl cannot access my stor...) Felix Miata <mrmazda@earthlink.net> - 2024-01-16 23:00 +0100
Testing storage performance (Was Re: mdraid construction and testing (was: smartctl cannot access my stor...)) Andy Smith <andy@strugglers.net> - 2024-01-17 04:40 +0100
Re: smartctl cannot access my storage, need syntax help Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-19 09:10 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Franco Martelli <martellif67@gmail.com> - 2024-01-19 20:10 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Nicolas George <george@nsup.org> - 2024-01-19 20:20 +0100
Re: To partition or not to partition MD arrays (Was Re: smartctl cannotaccess my storage, need syntax help) Franco Martelli <martellif67@gmail.com> - 2024-01-19 20:50 +0100
Re: smartctl cannot access my storage, need syntax help David Christensen <dpchrist@holgerdanske.com> - 2024-01-19 21:10 +0100
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | "Roy J. Tellason, Sr." <roy@rtellason.com> |
|---|---|
| Date | 2024-01-25 18:20 +0100 |
| Message-ID | <I0byp-5wfF-5@gated-at.bofh.it> |
| In reply to | #266584 |
On Thursday 25 January 2024 09:03:36 am Anssi Saari wrote: > Western Digital at least claims to have solved the leaking > problem with helium and since they've been making those drives for over > a decade, I think it's solved. Your source for this? -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> |
|---|---|
| Date | 2024-01-26 12:50 +0100 |
| Message-ID | <I0sSB-5GSx-1@gated-at.bofh.it> |
| In reply to | #266589 |
"Roy J. Tellason, Sr." <roy@rtellason.com> writes: > On Thursday 25 January 2024 09:03:36 am Anssi Saari wrote: >> Western Digital at least claims to have solved the leaking >> problem with helium and since they've been making those drives for over >> a decade, I think it's solved. > > Your source for this? The internet, of course. WDs blog, Backblaze, a bunch of news sites, basically whatever Qwant coughed up. Why?
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-29 06:20 +0100 |
| Message-ID | <I1sdP-6ira-3@gated-at.bofh.it> |
| In reply to | #266589 |
On Thu 25 Jan 2024 at 12:24:21 (-0500), Roy J. Tellason, Sr. wrote:
> On Thursday 25 January 2024 09:03:36 am Anssi Saari wrote:
> > On Tue 23 Jan 2024 at 06:32:54 (-0500), gene heskett wrote:
> > > On 1/23/24 06:12, Gremlin wrote:
> > > > On 1/23/24 06:04, gene heskett wrote:
> > > > > On 1/23/24 00:30, Karl Vogel wrote:
> > > > > > > > On 1/22/24 11:31, gene heskett wrote:
> > > > > >
> > > > > > G> How does an 8T backup server sound for another $200 in hdwe? Very
> > > > > > G> enticing and I do have the sheckel's.
> > > > > >
> > > > > > https://www.amazon.com/dp/B07CQJBSQL
> > > > > > Seagate Desktop 8TB external Hard Drive, 3.5 Inch, USB 3.0 STGY8000400
> > > > > > $168.18
> > > > > >
> > > > > > What if you buy two, use one for a complete backup and the other for
> > > > > > incrementals or differentials? (I know, more than $200...)
> > > > > >
> > > > > My disastrous experience with the last pair of seagates
> > > > > preclude exploring that path, ever again. I bought a couple
> > > > > 2T's to replace 2 1T's I had outgrown and had close to 70,000
> > > > > spining hours on the. They lasted a bit less than 30 days,
> > > > > dropping off the sata cables connecting then, never to be
> > > > > found again. Then I find they were shingled tech, and helium
> > > > > filled so the heads flew lower.
So the helium made the disks "drop off" the SATA cables?
How does that work?
> > > > https://www.howtogeek.com/803276/cmr-vs.-smr-hard-drives-whats-the-difference/
> > >
> > > I carefully note, the use of Helium and its problems is very carefully
> > > ignored.
What's the connection between shingled disks and helium?
> > Western Digital at least claims to have solved the leaking
> > problem with helium and since they've been making those drives for over
> > a decade, I think it's solved.
When were these leakage incidents? I haven't heard about them;
only Gene's wartime anecdotes about helium passing through inch-thick
walls of Monel with impunity.
> Your source for this?
Indeed, for any of this. As for facts from the internet, I read
this on one page selected at random — well, a top google hit:
https://recoverysquad.com.au/what-are-the-advantages-of-helium-sealed-hard-drives/
"Helium HDDs as compared to standard HDDs
Helium HDDs offer several advantages over traditional hard drives,
including:
[ … ]
· Their lower power consumption translates into longer battery life for portable devices.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
· And lastly, they generate less heat, which can be an issue with traditional HDDs.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
[ … ]
What are the challenges with Helium Hard Drives?
The challenges with helium hard drives are that they are expensive to produce and
they have a limited lifespan. The drives tend to run a bit hotter than traditional
hard drives, and they also use more power." ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
↑↑↑↑↑↑↑↑↑↑↑↑↑↑
WTF?
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Karl Vogel <vogelke@pobox.com> |
|---|---|
| Date | 2024-01-24 09:30 +0100 |
| Message-ID | <HZGNX-5dzB-1@gated-at.bofh.it> |
| In reply to | #266510 |
On Tue, Jan 23, 2024 at 06:05:29AM -0500, gene heskett wrote:
> On 1/23/24 00:30, Karl Vogel wrote:
> >>> On 1/22/24 11:31, gene heskett wrote:
> >
> > G> How does an 8T backup server sound for another $200 in hdwe? Very
> > G> enticing and I do have the sheckel's.
> >
> > https://www.amazon.com/dp/B07CQJBSQL
> > Seagate Desktop 8TB external Hard Drive, 3.5 Inch, USB 3.0 STGY8000400
> > $168.18
> >
> > What if you buy two, use one for a complete backup and the other for
> > incrementals or differentials? (I know, more than $200...)
>
> My disastrous experience with the last pair of seagates preclude exploring
> that path, ever again.
Sorry, the Seagate was just an example -- I prefer Western Digital myself.
My only point was using one or two external drives for backups.
--
Karl Vogel I don't speak for anyone but myself
And as we all know from experiments conducted during the Korean War, Diane,
sleep deprivation is a one-way ticket to temporary psychosis.
--FBI Special Agent Dale Cooper, "Twin Peaks"
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-21 10:40 +0100 |
| Message-ID | <HYCt3-4y3p-3@gated-at.bofh.it> |
| In reply to | #266349 |
On 21/01/2024 03:23, gene heskett wrote: > Right now nothing in the system is north of 32C, might get to 36C at > the end of a 9 minute build of something in OpenSCAD. I would say that 53°C and even 44°C is well above 36°C you expected: On 21/01/2024 12:48, gene heskett wrote: > > SCT Status Version: 3 > SCT Version (vendor specific): 256 (0x0100) > Device State: DST executing in background (3) > Current Temperature: 28 Celsius > Power Cycle Min/Max Temperature: 26/44 Celsius > Lifetime Min/Max Temperature: 24/53 Celsius > Specified Max Operating Temperature: 70 Celsius > Under/Over Temperature Limit Count: 0/0 > Device Statistics (GP Log 0x04) > > 0x05 ===== = = === == Temperature Statistics (rev 1) == > 0x05 0x008 1 28 --- Current Temperature > 0x05 0x020 1 53 --- Highest Temperature > 0x05 0x028 1 24 --- Lowest Temperature > 0x05 0x058 1 70 --- Specified Maximum Operating Temperature
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-21 18:40 +0100 |
| Message-ID | <HYJXA-4CBp-5@gated-at.bofh.it> |
| In reply to | #266356 |
On 1/21/24 04:35, Max Nikulin wrote: > > On 21/01/2024 03:23, gene heskett wrote: >> Right now nothing in the system is north of 32C, might get to 36C at >> the end of a 9 minute build of something in OpenSCAD. > > I would say that 53°C and even 44°C is well above 36°C you expected: > > On 21/01/2024 12:48, gene heskett wrote: >> >> SCT Status Version: 3 >> SCT Version (vendor specific): 256 (0x0100) >> Device State: DST executing in background (3) >> Current Temperature: 28 Celsius >> Power Cycle Min/Max Temperature: 26/44 Celsius >> Lifetime Min/Max Temperature: 24/53 Celsius >> Specified Max Operating Temperature: 70 Celsius >> Under/Over Temperature Limit Count: 0/0 > >> Device Statistics (GP Log 0x04) >> >> 0x05 ===== = = === == Temperature Statistics (rev 1) == >> 0x05 0x008 1 28 --- Current Temperature >> 0x05 0x020 1 53 --- Highest Temperature >> 0x05 0x028 1 24 --- Lowest Temperature >> 0x05 0x058 1 70 --- Specified Maximum Operating >> Temperature > IIRC the fan in the front of an upper drive cage got unplugged for a while, half an hour maybe, about a year ago while I was doing my annual D&C on it. These SSD's all of them have a label claiming they need 5 volts and 1 amp, that is 5 watts, but I don't think that is a steady load, probably only when writing at 500+ mhz, ! watt or less of heat is much closer to normal operation. Thank you, take care, stay warm, dry and well, Max. Having a heat wave here, its up to 21F out at 12:25 pm here, 16" of white stuff on the front deck, got cold & had to replace the battery's in my smart t-stat about an hour ago. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-19 05:10 +0100 |
| Message-ID | <HXOmB-43Nh-3@gated-at.bofh.it> |
| In reply to | #266181 |
On Thu 18 Jan 2024 at 00:57:07 (-0800), David Christensen wrote: > On 1/17/24 22:44, gene heskett wrote: > > One thing that bothers me is there is no way the installers parted > > shows partition names for non-raid disks. To me that is a serious > > bug. It appears from the help that it can LABEL a partition but > > can't read that LABEL. > > When installing to UEFI/GPT, I am able to label partitions in the > Debian Installer, the labels are visible in the installer, and the > labels persist on disk after installation is complete. Agreed, and that doesn't depend on UEFI; MBR/GPT disks show the same behaviour. But those are PARTLABELS. But it may be that Gene meant filesystem LABELs. Gene, to check/display the LABELs, just place, in turn, the highlight on the line for each partition, like: │ > #5 31.5 GB ext4 Viva-B ▒ │ press Return for it to display: │ Partition settings: │ │ │ │ Name: Viva-B │ │ Use as: Ext4 journaling file system │ │ │ │ Format the partition: yes, format it │ │ Mount point: / │ │ Mount options: defaults │ │ Label: viva05 ←←←←←← │ │ Reserved blocks: 5% │ │ │ │ Done setting up the partition │ where Name: ⇒ PARTLABEL and Label: ⇒ LABEL. Then select "Done setting up …" or <Go Back> to back out each time. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-01-18 08:40 +0100 |
| Message-ID | <HXvah-3S7G-3@gated-at.bofh.it> |
| In reply to | #266166 |
Hi,
gene heskett wrote:
> > where did the extra 19.4G's come from? Can filesystem
> > ext4's overhead account for that?
In an earlier mail:
> > > command line: rsync -a --bwlimit=10m --fsync --progress /home/ /mnt/homevol
David Christensen wrote:
> Please RTFM rsync(1) to choose your options. These look
> useful:
> --archive, -a (-rlptgoD)
> --delete
> --hard-links, -H
> --one-file-system, -x
> --sparse, -S
I bet on --hard-links and --sparse as means to avoid the extra disk space
consumption. (--archive is important for other reasons, but it was
already in use as -a with your successful rsync run. --delete will be
of importance if the rsync run gets repeated on the already filled target
directory tree.)
man rsync:
-H, --hard-links
This tells rsync to look for hard-linked files in the source and
link together the corresponding files on the destination. With‐
out this option, hard-linked files in the source are treated as
though they were separate files.
[...]
-S, --sparse
Try to handle sparse files efficiently so they take up less
space on the destination. [...]
One can observe a similar inflation effect when copying the files of a
Debian installation ISO to hard disk. In the original disk directory
on the machine which created the ISO there were hardlinked kernels and
firmware packages. In the ISO these link siblings share the same file
content storage.
But when mounted, the siblings get treated as separate files with
different inode numbers. So the 8,135,584 bytes of the hardlink siblings
/install.amd/gtk/vmlinuz
/install.amd/vmlinuz
/install.amd/xen/vmlinuz
get triplicated when these three files get copied out of the ISO.
I am somewhat astonished that --hard-links is not default in rsync,
as it is quite important for backup fidelity.
(On the other hand it is some effort to find all siblings on the disk.)
Sparse files are files with large areas of 0-bytes. Many filesystems
don't store the zeros but rather an instruction to hand out the given
number of 0-bytes when requested by a reader.
If i were you, i'd let rsync make a complete new copy with --hard-links
--sparse, and --delete, but without --bwlimit= in order to get a higher
copy fidelity and also to check whether the transfer speed really was not
to blame for the appearance of the OOM killer.
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> |
|---|---|
| Date | 2024-01-19 09:20 +0100 |
| Message-ID | <HXSgx-468z-3@gated-at.bofh.it> |
| In reply to | #266142 |
gene heskett <gheskett@shentel.net> writes: > The OOM death of the system was the xfce4 terminal apparently being > set for unlimited scrollback and that was eating the memory. Switching > to Konsole with has the ability to control the scrollback to 200 > lines, and its taken all 32G's as .cache and 1536 1k blocks of swap, > and its working w/o any OOM actions I've detected. It does seem strange to me, even in MS-DOS era I was able to set a terminal scrollback to 5000 lines without issue, when RAM was maybe 4 MB and a DOS terminal program probably had access to way less than that. So does rsync really generate gigabytes of verbose output? Or is xfce-terminal storing the scrollback in a very inefficient way?
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-01-19 11:00 +0100 |
| Message-ID | <HXTPj-46SA-3@gated-at.bofh.it> |
| In reply to | #266258 |
Hi, Anssi Saari > It does seem strange to me, even in MS-DOS era I was able to set a > terminal scrollback to 5000 lines without issue, when RAM was maybe 4 MB > and a DOS terminal program probably had access to way less than that. I have no problems with 130 xterms of 10,000 lines each. > So does rsync really generate gigabytes of verbose output? rsync can be extremely verbose when the number of transferred files is very high. > Or is xfce-terminal storing the scrollback in a very inefficient way? I would not be astonished to learn that the luxury ornamented terminals of the various desktops waste many extra bytes when memorizing plain text. But the real bug is the fact that the scroll back memory is unlimited and can summon the OOM killer. (I imagine it like the Discworld Death of Rats.) If i were a user of Xfce i would report this as bug to its Debian maintainer. Bug title "xfce-terminal: A landmine on the kids' playground". Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-19 13:10 +0100 |
| Message-ID | <HXVR7-48gi-1@gated-at.bofh.it> |
| In reply to | #266267 |
On 1/19/24 04:50, Thomas Schmitt wrote: > Hi, > > Anssi Saari >> It does seem strange to me, even in MS-DOS era I was able to set a >> terminal scrollback to 5000 lines without issue, when RAM was maybe 4 MB >> and a DOS terminal program probably had access to way less than that. > > I have no problems with 130 xterms of 10,000 lines each. > > >> So does rsync really generate gigabytes of verbose output? > > rsync can be extremely verbose when the number of transferred files is > very high. > > >> Or is xfce-terminal storing the scrollback in a very inefficient way? > > I would not be astonished to learn that the luxury ornamented terminals > of the various desktops waste many extra bytes when memorizing plain text. > But the real bug is the fact that the scroll back memory is unlimited and > can summon the OOM killer. (I imagine it like the Discworld Death of Rats.) > > If i were a user of Xfce i would report this as bug to its Debian > maintainer. Bug title "xfce-terminal: A landmine on the kids' playground". > > > Have a nice day :) > > Thomas > > . Excellent description Thomas. Love it. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-19 13:00 +0100 |
| Message-ID | <HXVHr-47XS-3@gated-at.bofh.it> |
| In reply to | #266258 |
On 1/19/24 03:12, Anssi Saari wrote: > gene heskett <gheskett@shentel.net> writes: > >> The OOM death of the system was the xfce4 terminal apparently being >> set for unlimited scrollback and that was eating the memory. Switching >> to Konsole with has the ability to control the scrollback to 200 >> lines, and its taken all 32G's as .cache and 1536 1k blocks of swap, >> and its working w/o any OOM actions I've detected. > > It does seem strange to me, even in MS-DOS era I was able to set a > terminal scrollback to 5000 lines without issue, when RAM was maybe 4 MB > and a DOS terminal program probably had access to way less than that. So > does rsync really generate gigabytes of verbose output? Or is > xfce-terminal storing the scrollback in a very inefficient way? > That I can't answer, other than -v outputs a full from / pathlist to everyfile it touchs, and if storing that in ram, I can sure see it eating 32G very quickly when it is moving 335G, it only got around 13G moved before OOM struck and killed the system, on each of probably 15 attempts. Knowing that the tech of an SSD and the common micro-sd has a relatively limited actual write speed after in has used up its input cache of fast ram, I took the v off the -av, and them limited it to 10megs a second, it took around 9 hours and the system acted normally, no OOM problens. I have edited the /etc/stab and am now running on that copy for /home. The raid is now automounted to /raid10 and says its valid, despite the 4th drives log being a mess. My thoughts are to reverse the copy and put it in crontab to keep an uptodate backup of /home until I can re-invent my wrappers for amanda. /home is by far the biggest glop of data, and none of my printers or cnc machines will use more that 10G reach, so I'm inclinded to think of the other 8T of drives as an lvm managed 8T, which should give me room enough to keep 30 days worth of amanda's way of doing things. But I'm hibernating for the nonce, I woke up at 6 with 6" of new snow on the deck, and the weather fabricators are promising another 24 hours of that, might wind up with 3 or 4 feet of it. I've got coffee, the freezers are well stocked. Boring but safe. All the messy logs were at hour 21027 so that was a single actual event, probably caused by OOM. Take care Anssi, stay warm, dry and well where ever you are. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2024-01-18 17:40 +0100 |
| Message-ID | <HXDAS-3XbX-5@gated-at.bofh.it> |
| In reply to | #266126 |
On 2024-01-17, Thomas Schmitt <scdbackup@gmx.net> wrote: > Hi, > > Curt wrote: >> I discovered a couple of discussions of the phenomenon, the upshot of which >> were: >> 1) That's what you get when you purchase cheap SSDs. >> https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/ >> 2) SSDs belonging to the same software RAID show identical serial numbers >> in software, but these numbers don't match the serial numbers printed on the >> SSDs themselves. >> https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/ > > Those URLs are identical. (OMG ! Is it contageous ?) Human error may very be: https://www.reddit.com/r/synology/comments/18fe6ez/how_to_fix_2_drives_with_same_serial_number/ > Number 2 would match my suspicion that some layer in the disk driving > gets confused and mixes up the serial numbers. > > >> But you said *similar*. > > By "colliding serial numbers" i mean indeed "identical serial numbers". > > How cheap the disks may ever be, that would be no excuse for not making > them individually distinguishable. > > >> As Gene's threads have too many movable parts >> for me to follow, on that point I couldn't say. > > This one begins to gain presence in the web. So one can use search engines > and AI to untangle its sub-threads. I meanwhile participate in two of them: > serial number collision, rsync caused OOM killer (solved now, but how ?). > > > Have a nice day :) > > Thomas > > --
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-17 21:20 +0100 |
| Message-ID | <HXkyd-3LLz-7@gated-at.bofh.it> |
| In reply to | #266122 |
On 1/17/24 11:38, Curt wrote: > On 2024-01-17, Thomas Schmitt <scdbackup@gmx.net> wrote: >> >> This is just weird. >> I still have difficulties to believe that any disk manufacturer would >> hand out disks with colliding serial numbers. I googled for this >> phenomenon, but except two mails of Gene nothing similar popped up. > > I discovered a couple of discussions of the phenomenon, the upshot of which > were: > > 1) That's what you get when you purchase cheap SSDs. > > https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/ > > 2) SSDs belonging to the same software RAID show identical serial numbers > in software, but these numbers don't match the serial numbers printed on the SSDs themselves. But the drives in question are not yet and never have been in a raid just plugged in awaiting my putting them to work. > > https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/ > > But you said *similar*. As Gene's threads have too many movable parts > for me to follow, on that point I couldn't say. > > . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-01-17 18:10 +0100 |
| Message-ID | <HXhAl-3K1Z-7@gated-at.bofh.it> |
| In reply to | #266105 |
On 1/16/24 23:46, Thomas Schmitt wrote:
> Gene Heskett wrote:
> One of these mails from a thread in december reveals that the three
> unique serial numbers GSTD02TB230102, GST02TBG221146, GSTG02TB230206
> each come with a different version of "1C0", "7A0", "5A0", respectively.
> https://www.mail-archive.com/debian-user@lists.debian.org/msg799307.html
> That's unexpected, too, as the disk properties look identical elsewise.
Thank you for locating the lshw(1) output. It appears to have been run
when one Gigastone SSD was on the motherboard SATA controller and four
Gigastone SSD's were on the 6-port HBA:
2024-01-17 08:58:54 dpchrist@laalaa ~
$ egrep 'sata|disk|product|version|serial' gene-heskett-coyote-lshw.out
| grep -B 1 -A 2 Gigastone
*-disk:1
product: Gigastone SSD
version: 7A0
serial: GST02TBG221146
--
*-disk:0
product: Gigastone SSD
version: 7A0
serial: GST02TBG221146
--
*-disk:1
product: Gigastone SSD
version: 5A0
serial: GSTG02TB230206
--
*-disk:2
product: Gigastone SSD
version: 5A0
serial: GSTG02TB230206
--
*-disk:3
product: Gigastone SSD
version: 1C0
serial: GSTD02TB230102
David
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2024-01-18 08:20 +0100 |
| Message-ID | <HXuQV-3S1K-1@gated-at.bofh.it> |
| In reply to | #266099 |
On Tue, 16 Jan 2024 21:10:28 -0500 gene heskett <gheskett@shentel.net> wrote: > gene@coyote:~/src/klipper-docs$ lsblk -d -o > NAME,MAJ:MIN,MODEL,SERIAL,WWN /dev/sd[hijkl] > NAME MAJ:MIN MODEL SERIAL WWN > sdh 8:112 Gigastone SSD GSTD02TB230102 > sdi 8:128 Gigastone SSD GST02TBG221146 > sdj 8:144 Gigastone SSD GST02TBG221146 > sdk 8:160 Gigastone SSD GSTG02TB230206 > sdl 8:176 Gigastone SSD GSTG02TB230206 Something is seriously wrong here. I worked at Maxtor for a while. They went out of their way to be sure there were no duplicate serial numbers. Gene, I suggest you check these SNs with the SN on the packages (if there is one) and on the label on the drive. Also, take each drive, one at a time, attach it to another computer with a fresh installation of Debian, one you haven't mucked with in any way, and only one other drive already in it, and read the SNs there. I also went looking for Gigastone's web site. Every page I tried at gigastone.com led to what I presume was an Error 404 page. I say presume because most of the text was in non-English, probably Chinese, characters. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-17 02:10 +0100 |
| Message-ID | <HX2Bj-3ASX-1@gated-at.bofh.it> |
| In reply to | #266038 |
On 1/16/24 00:56, Felix Miata wrote: > gene heskett composed on 2024-01-15 17:56 (UTC-0500): > >> Thanks for that composition: but it will be word wrapped: >> root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' >> "$(realpath "$j")" "$j" ; done >> /dev/sr0 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865 >> /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 >> /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 >> /dev/sdh /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 >> /dev/sdh1 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 >> /dev/sdk /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 >> /dev/sdk1 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 >> /dev/sdf /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T >> /dev/sdf1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 >> /dev/sdf2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 >> /dev/sdf3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 >> /dev/sde /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E >> /dev/sde1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 >> /dev/sde2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 >> /dev/sde3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 >> /dev/sdd /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V >> /dev/sdd1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 >> /dev/sdd2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 >> /dev/sdd3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 >> /dev/sdg /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W >> /dev/sdg1 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 >> /dev/sdg2 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 >> /dev/sdg3 >> /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 >> /dev/sda /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V >> /dev/sda1 >> /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 >> /dev/sda2 >> /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 >> /dev/sda3 >> /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 >> /dev/md0 /dev/disk/by-id/md-name-coyote:0 >> /dev/md0p1 /dev/disk/by-id/md-name-coyote:0-part1 >> /dev/md2 /dev/disk/by-id/md-name-coyote:2 >> /dev/md1 /dev/disk/by-id/md-name-_none_:1 >> /dev/md0 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb >> /dev/md0p1 >> /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 >> /dev/md1 /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 >> /dev/md2 /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 >> /dev/sdc /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 >> /dev/sdb /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0 >> /dev/sdf /dev/disk/by-id/wwn-0x5002538f413394a5 >> /dev/sdf1 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 >> /dev/sdf2 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 >> /dev/sdf3 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 >> /dev/sde /dev/disk/by-id/wwn-0x5002538f413394a9 >> /dev/sde1 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 >> /dev/sde2 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 >> /dev/sde3 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 >> /dev/sdd /dev/disk/by-id/wwn-0x5002538f413394ae >> /dev/sdd1 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 >> /dev/sdd2 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 >> /dev/sdd3 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 >> /dev/sdg /dev/disk/by-id/wwn-0x5002538f413394b0 >> /dev/sdg1 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 >> /dev/sdg2 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 >> /dev/sdg3 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 >> /dev/sda /dev/disk/by-id/wwn-0x5002538f42205e8e >> /dev/sda1 /dev/disk/by-id/wwn-0x5002538f42205e8e-part1 >> /dev/sda2 /dev/disk/by-id/wwn-0x5002538f42205e8e-part2 >> /dev/sda3 /dev/disk/by-id/wwn-0x5002538f42205e8e-part3 >> root@coyote:~# >> but like I wrote, 2 pairs with identical "serial numbers", so the >> assunption is that the last one overwrites the first on by udev, when >> IMO it should be yelling about the duplicats. > > I straightened out the wrapping mess, and gave each entry a line number. I see > nothing I recognize as representing serial number duplication among /dev/sdX > (physical device) names: > > /dev/md0 1 /dev/disk/by-id/md-name-coyote:0 > /dev/md0 2 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb > /dev/md0p1 3 /dev/disk/by-id/md-name-coyote:0-part1 > /dev/md0p1 4 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 > /dev/md1 5 /dev/disk/by-id/md-name-_none_:1 > /dev/md1 6 /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 > /dev/md2 7 /dev/disk/by-id/md-name-coyote:2 > /dev/md2 8 /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 > /dev/sda 9 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V > /dev/sda 10 /dev/disk/by-id/wwn-0x5002538f42205e8e > /dev/sda1 11 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 > /dev/sda1 12 /dev/disk/by-id/wwn-0x5002538f42205e8e-part1 > /dev/sda2 13 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 > /dev/sda2 14 /dev/disk/by-id/wwn-0x5002538f42205e8e-part2 > /dev/sda3 15 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 > /dev/sda3 16 /dev/disk/by-id/wwn-0x5002538f42205e8e-part3 > /dev/sdb 17 /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0 > /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 # How does a printer get a storage device assignment??? > /dev/sdd 19 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V > /dev/sdd 20 /dev/disk/by-id/wwn-0x5002538f413394ae > /dev/sdd1 21 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 > /dev/sdd1 22 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 > /dev/sdd2 23 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 > /dev/sdd2 24 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 > /dev/sdd3 25 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 > /dev/sdd3 26 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 > /dev/sde 27 /dev/disk/by-id/wwn-0x5002538f413394a9 > /dev/sde 28 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E > /dev/sde1 29 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 > /dev/sde1 30 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 > /dev/sde2 31 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 > /dev/sde2 32 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 > /dev/sde3 33 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 > /dev/sde3 34 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 > /dev/sdf 35 /dev/disk/by-id/wwn-0x5002538f413394a5 > /dev/sdf 36 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T > /dev/sdf1 37 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 > /dev/sdf1 38 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 > /dev/sdf2 39 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 > /dev/sdf2 40 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 > /dev/sdf3 41 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 > /dev/sdf3 42 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 > /dev/sdg 43 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W > /dev/sdg 44 /dev/disk/by-id/wwn-0x5002538f413394b0 > /dev/sdg1 45 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 > /dev/sdg1 46 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 > /dev/sdg2 47 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 > /dev/sdg2 48 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 > /dev/sdg3 49 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 > /dev/sdg3 50 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 > /dev/sdh 51 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 > /dev/sdh1 52 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1 > /dev/sdi 53 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > /dev/sdj1 54 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 > /dev/sdk 55 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 > /dev/sdk1 56 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1 > /dev/sr0 57 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865 > > Exactly which line numbers represent duplication among the physical drives? lsblk, which I've published several times, shows 5 drives. by-id listing only shows 3. The drive I've been trying to use bounces from /dev/sdd to sde to sdh dependin on which controller it is curently plugged into. And I've since tried cp in addition to rsync, does the same thing, killing the sysytem with the OOM but much quicker. cp using all system memory (32Gb) in 1 minute, another 500K into swap adds another 15 secs, and the OOM kills the system. So both cp and rsync act broken. rsync, with a --bwlimit=3m set, takes much longer to kill the system but the amount of data moved is very similar, 13.5G from clean disk to system freeze for rsync, 13.4G for cp. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-17 03:00 +0100 |
| Message-ID | <HX3nH-3B7R-3@gated-at.bofh.it> |
| In reply to | #266094 |
On Tue 16 Jan 2024 at 20:08:12 (-0500), gene heskett wrote: > On 1/16/24 00:56, Felix Miata wrote: > > gene heskett composed on 2024-01-15 17:56 (UTC-0500): > > > > > Thanks for that composition: but it will be word wrapped: > > > root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' > > > "$(realpath "$j")" "$j" ; done [ … ] > > I straightened out the wrapping mess, and gave each entry a line number. I see > > nothing I recognize as representing serial number duplication among /dev/sdX > > (physical device) names: > > [ … ] > > /dev/sdd 19 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V > > /dev/sdd 20 /dev/disk/by-id/wwn-0x5002538f413394ae > > /dev/sdd1 21 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 > > /dev/sdd1 22 /dev/disk/by-id/wwn-0x5002538f413394ae-part1 > > /dev/sdd2 23 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 > > /dev/sdd2 24 /dev/disk/by-id/wwn-0x5002538f413394ae-part2 > > /dev/sdd3 25 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 > > /dev/sdd3 26 /dev/disk/by-id/wwn-0x5002538f413394ae-part3 > > /dev/sde 27 /dev/disk/by-id/wwn-0x5002538f413394a9 > > /dev/sde 28 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E > > /dev/sde1 29 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 > > /dev/sde1 30 /dev/disk/by-id/wwn-0x5002538f413394a9-part1 > > /dev/sde2 31 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 > > /dev/sde2 32 /dev/disk/by-id/wwn-0x5002538f413394a9-part2 > > /dev/sde3 33 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 > > /dev/sde3 34 /dev/disk/by-id/wwn-0x5002538f413394a9-part3 > > /dev/sdf 35 /dev/disk/by-id/wwn-0x5002538f413394a5 > > /dev/sdf 36 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T > > /dev/sdf1 37 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 > > /dev/sdf1 38 /dev/disk/by-id/wwn-0x5002538f413394a5-part1 > > /dev/sdf2 39 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 > > /dev/sdf2 40 /dev/disk/by-id/wwn-0x5002538f413394a5-part2 > > /dev/sdf3 41 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 > > /dev/sdf3 42 /dev/disk/by-id/wwn-0x5002538f413394a5-part3 > > /dev/sdg 43 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W > > /dev/sdg 44 /dev/disk/by-id/wwn-0x5002538f413394b0 > > /dev/sdg1 45 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 > > /dev/sdg1 46 /dev/disk/by-id/wwn-0x5002538f413394b0-part1 > > /dev/sdg2 47 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 > > /dev/sdg2 48 /dev/disk/by-id/wwn-0x5002538f413394b0-part2 > > /dev/sdg3 49 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 > > /dev/sdg3 50 /dev/disk/by-id/wwn-0x5002538f413394b0-part3 > lsblk, which I've published several times, shows 5 drives. by-id > listing only shows 3. The drive I've been trying to use bounces from > /dev/sdd to sde to sdh dependin on which controller it is curently > plugged into. I take it that you're trying to copy to one Gigastone SSD. Presumably the kernel favours some controllers over others in the race to name them. This is why using the kernel's device names is no longer recommended. > And I've since tried cp in addition to rsync, does the same thing, > killing the sysytem with the OOM but much quicker. cp using all system > memory (32Gb) in 1 minute, another 500K into swap adds another 15 > secs, and the OOM kills the system. So both cp and rsync act broken. I'd be tempted to bisect the problem by copying to another machine though a cat5 cable. > rsync, with a --bwlimit=3m set, takes much longer to kill the system > but the amount of data moved is very similar, 13.5G from clean disk to > system freeze for rsync, 13.4G for cp. I don't know enough about how rsync behaves to interpret that coincidence, but it seems ominous on its face. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2024-01-17 05:10 +0100 |
| Message-ID | <HX5pv-3CFN-1@gated-at.bofh.it> |
| In reply to | #266094 |
gene heskett composed on 2024-01-16 20:08 (UTC-0500): > Felix Miata wrote: >> I straightened out the wrapping mess, and gave each entry a line number. I see >> nothing I recognize as representing serial number duplication among /dev/sdX >> (physical device) names: >> /dev/sda 9 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V >> /dev/sdd 19 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V >> /dev/sde 28 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E >> /dev/sdf 36 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T >> /dev/sdg 43 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W >> /dev/sdh 51 /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102 >> /dev/sdi 53 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 >> /dev/sdk 55 /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206 >> Exactly which line numbers represent duplication among the physical drives? > lsblk, which I've published several times, shows 5 drives. by-id listing > only shows 3. The drive I've been trying to use bounces from /dev/sdd to > sde to sdh dependin on which controller it is curently plugged into. >From your 2024-01-15 17:56 -0500 post, I see 8 unique serial numbers from SATA SSDs, 5 Samsung, 3 Gigastone. I ignore all your posts with lsblk that didn't use the -f option to facilitate identifying individual SSDs. > And I've since tried cp in addition to rsync, does the same thing, > killing the sysytem with the OOM but much quicker. cp using all system > memory (32Gb) in 1 minute, another 500K into swap adds another 15 secs, > and the OOM kills the system. So both cp and rsync act broken. > rsync, with a --bwlimit=3m set, takes much longer to kill the system but > the amount of data moved is very similar, 13.5G from clean disk to > system freeze for rsync, 13.4G for cp.-- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-01-15 08:50 +0100 |
| Message-ID | <HWpTk-3cT5-1@gated-at.bofh.it> |
| In reply to | #265949 |
On 1/14/24 11:48, gene heskett wrote: > On 1/14/24 07:42, David Christensen wrote: >> Re-ordered for clarity -- David. > And snipped by Gene as I updated >> >> On 1/12/24 18:42, gene heskett wrote: >>> I just found an mbox file in my home directory, containing about 90 >>> days worth of undelivered msgs from smartctl running as root. >> Do you know how the mbox file got there? > No, it just appeared. >> >>> smartctl says my raid10 is dying, ... >> >> >> Please post a console session with a command that displays the message. > This is a copy/paste of the second message in that file, the first from > smartctl, followed by the last message in that file: > > From root@coyote.coyote.den Wed Nov 02 00:29:05 2022 > Return-path: <root@coyote.coyote.den> > Envelope-to: root@coyote.coyote.den > Delivery-date: Wed, 02 Nov 2022 00:29:05 -0400 > Received: from root by coyote.coyote.den with local (Exim 4.94.2) It looks like you configured Exim to put root's mailbox in your home directory, to make it easier to read (?). > (envelope-from <root@coyote.coyote.den>) > id 1oq5NB-000DBx-15 > for root@coyote.coyote.den; Wed, 02 Nov 2022 00:29:05 -0400 > To: root@coyote.coyote.den > Subject: SMART error (SelfTest) detected on host: coyote > MIME-Version: 1.0 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: 8bit > Message-Id: <E1oq5NB-000DBx-15@coyote.coyote.den> > From: root <root@coyote.coyote.den> > Date: Wed, 02 Nov 2022 00:29:05 -0400 > Content-Length: 513 > Lines: 16 > Status: RO > X-Status: > X-Keywords: > X-UID: 2 > > This message was generated by the smartd daemon running on: > > host name: coyote > DNS domain: coyote.den > > The following warning/error was logged by the smartd daemon: > > Device: /dev/sde [SAT], Self-Test Log error count increased from 0 to 1 > > Device info: > Samsung SSD 870 EVO 1TB, S/N:S626NF0R302507V, WWN:5-002538-f413394ae, > FW:SVT01B6Q, 1.00 TB > > For details see host's SYSLOG. > ... > I also note they are now very old messages but the file itself is dated > Jan 7nth. And syslog has been rotated several times since. > > I'm not expert at interpreting smartctl reports, but I do not see such > in the smarttcl output now. going backwads thru the list, the 4th drive > in the raid has had 3334 errors, as had the third drive with 3332 > ettors, the 1st and 2nd are clean. > > One stanza of the error report: > Error 3328 occurred at disk power-on lifetime: 21027 hours (876 days + 3 > hours) I believe "3328" is an error number, not the quantity of errors -- the smartd mail said the count increased from 0 to 1. > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Extended offline Completed: read failure 50% 10917 > 1847474376 > # 2 Extended offline Completed: read failure 50% 10586 > 1847474376 > > So half the samsung 870's are on their way out. But nothing recent... So > I am now trying to get a good rsync copy on another drive. Before you conclude that two of the Samsung 870 1 TB's are dying, please run a SMART short test on all four: # smartctl -t short /dev/disk/by-id/... What a few minutes for the test to complete (10 minutes should be more than enough). Then get full SMART reports and save them to files: # smartctl -x /dev/disk/by-id/... > YYYYMMDD-HHMM-smartctl-x-MANF-MODEL-SERIAL.out Then upload the SMART reports someplace we can see them and post the URL's. >> * /home is on a RAID 10 with 2 @ mirror of 2 @ 1 TB Samsung 870 SSD? > > I think thasts what you call a raid10 Okay. >> * 4 @ 2 TB Gigastone SSD for a new RAID 10? > > just installed, not mounted or made into a raid yet. WIP? Okay. >> What drives are connected to which ports? > > 4 Samsung 870 1T's are on the 1st added controller. > ATM 5, 2T gigastone's are on the 2nd, 16 port added controller > smarttcl says all 5 of those are fine. Okay. >> What is on the other 20 ports? > On the mobo? A big dvd writer and 2 other half T or 1T samsung drives > from earlier 860 runs, not currently mounted. > No spinning rust anyplace > now. ... > A current lsblk: > gene@coyote:~$ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > sda 8:0 0 931.5G 0 disk > ├─sda1 8:1 0 838.2G 0 part / > ├─sda2 8:2 0 46.8G 0 part [SWAP] > └─sda3 8:3 0 46.6G 0 part /tmp > > sdb 8:16 1 0B 0 disk is probably my camera, currently > plugged in > > sdc 8:32 1 0B 0 disk is probably my brother > MFP-J6920DW printer, always plugged in So, your OS disk is a Samsung 1 TB SSD on port /dev/sda. I do not see the second Samsung SSD (?). I would use dmesg(1) and grep(1) to figure out what /dev/sdb and /dev/sdc are: # dmesg | egrep '/dev/sd[bc]' > first controller, 6 port > sdd 8:48 0 931.5G 0 disk > ├─sdd1 8:49 0 900G 0 part > │ └─md0 9:0 0 1.7T 0 raid10 > │ └─md0p1 259:0 0 1.7T 0 part /home > ├─sdd2 8:50 0 30G 0 part > │ └─md1 9:1 0 60G 0 raid10 [SWAP] > └─sdd3 8:51 0 1.5G 0 part > └─md2 9:2 0 3G 0 raid10 > sde 8:64 0 931.5G 0 disk > ├─sde1 8:65 0 900G 0 part > │ └─md0 9:0 0 1.7T 0 raid10 > │ └─md0p1 259:0 0 1.7T 0 part /home > ├─sde2 8:66 0 30G 0 part > │ └─md1 9:1 0 60G 0 raid10 [SWAP] > └─sde3 8:67 0 1.5G 0 part > └─md2 9:2 0 3G 0 raid10 > sdf 8:80 0 931.5G 0 disk > ├─sdf1 8:81 0 900G 0 part > │ └─md0 9:0 0 1.7T 0 raid10 > │ └─md0p1 259:0 0 1.7T 0 part /home > ├─sdf2 8:82 0 30G 0 part > │ └─md1 9:1 0 60G 0 raid10 [SWAP] > └─sdf3 8:83 0 1.5G 0 part > └─md2 9:2 0 3G 0 raid10 > sdg 8:96 0 931.5G 0 disk > ├─sdg1 8:97 0 900G 0 part > │ └─md0 9:0 0 1.7T 0 raid10 > │ └─md0p1 259:0 0 1.7T 0 part /home > ├─sdg2 8:98 0 30G 0 part > │ └─md1 9:1 0 60G 0 raid10 [SWAP] > └─sdg3 8:99 0 1.5G 0 part > └─md2 9:2 0 3G 0 raid10 Okay. Those are the 4 @ Samsung 870 1 TB SSD's. It looks like you partitioned them for three RAID10'sP: 1. 900 GB first partitions for /home RAID10. 2. 30 GB second partitions for swap RAID10. 3. What are the 1.5 GB third partitions for? > 2nd controller, 16 ports, all 5 2T gigastone's > sdh 8:112 0 1.9T 0 disk > └─sdh1 8:113 0 1.9T 0 part > sdi 8:128 0 1.9T 0 disk > └─sdi1 8:129 0 1.9T 0 part > sdj 8:144 0 1.9T 0 disk > └─sdj1 8:145 0 1.9T 0 part > sdk 8:160 0 1.9T 0 disk > └─sdk1 8:161 0 1.9T 0 part > sdl 8:176 0 1.9T 0 disk > └─sdl1 8:177 0 1.9T 0 part > sr0 11:0 1 1024M 0 rom The internal dvd writer > gene@coyote:~$ Those are the 5 @ Gigastone 2 TB SSD's, with one big partition on each. >> > blkid does not sort them in order either. And of coarse does not list >> > whats unmounted, forcing me to ident the drive by gparted in order to >> > get its device name. From that I might be able to construct another >> raid >> > from the 8T of 4 2T drives but its confusing as hell when the first of >> > those 2T drives is assigned /dev/sde and the next 4 on the new >> > controller are /dev/sdi, j, k, & l. Use /dev/disk/by-id/* paths when referring to drives. >> > So it appears I have 5 of those gigastones, and sde is the odd one > Which when it was /dev/sde1, was plugged into the 1st extra controller > When the data cable was plugged into a motherboard port, it became > /dev/sdb1. So I've relabeled it, and about to test it on the second 16 > port controller. >> >> >> I am confused -- do you have 4 or 5 Gigastone 2 TB SSD? > > 5, ordered in 2 separate orders. >> >> > So that one could be formatted ext4 and serve as a backup of the >> raid10. > What I am trying to do now, but cannot if it is plugged into a > motherboard port, hence the repeat of this exercise on the 2nd sata card. >> >> > how do I make an image of that >> > raid10 to /dev/sde and get every byte? That seems like the first >> step >> > to me. > This I am still trying to do, the first pass copied all 350G of /home > but went to the wrong drive, and I had mounted the drive by its label. > It is now /dev/sdh and all labels above it are now wrong. Crazy. > These SSD's all have an OTP serial number. I am tempted to use that > serial number as a label _I_ can control. When I built and ran a Debian 2 @ HDD RAID1 using mdadm(8), I did not partiton the HDD's -- I gave mdadm(8) the whole drives. > And according to gparted, > labels do not survive being incorporated into a raid as the raid is all > labeled with hostname : partition number. So there really is no way in > linux to define a drive that is that drive forever. Unreal... Do what I did -- forget partitions and give the whole SSD's to mdadm(8). Make sure you zero or secure erase them first. >> Please get a USB 3.x HDD, do a full backup of your entire computer, >> put it off-site, get another USB 3.x HDD, do another full backup, and >> keep it nearby > > That, using amanda is the end target of this. But I have bought 3 such > spinning rust drives over the years and not had any survive being hot > plugged into a usb port more than twice. > > With that track record, I'll not waste any more money down that rabbit > hole. Okay. I would not mind two big USB 3.x SSD's for backups, but I cannot justify the expense. >> > But since I can't copy a locked file, >> >> What file is lock? Please post a console session that demonstrates. > > A file that is opened but not closed is exclusive to that app and its > lock, and cannot be copied except by rsync, or so I have been told. AIUI that depends upon how locks are implemented -- advisory or enforced. That said, you want to backup files when they are closed. Coordinating applications, services, and backups such that you obtain correct and consistent backup files every time is non-trivial. My SOHO network is easy -- I close all apps, do not use any services, and run my backup script. > And there are quite a few such open locks on this system right now. If you installed Debian onto a USB drive (flash or SSD), you could boot that, mount your disks/ RAID's read-only, and run your backups without any open or locked files. > This > killed my full housed amiga when the boot drive with all its custom > scripts died, and I found the backups I had were totally devoid of any > of those scripts. That is a good reason to validate your backup/ restore processes. > I still have about 20 QIC tapes from that machine, but > now no drives to read them. I need to cull the midden heap. That is a good reason to backup/ archive onto multiple media types. David
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | linux.debian.user
csiph-web