Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #267123 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2024-02-07 21:40 +0100 |
| Last post | 2024-02-09 14:20 +0100 |
| Articles | 18 on this page of 98 — 20 participants |
Back to article view | Back to linux.debian.user
Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-07 21:40 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-08 05:30 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 11:00 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 11:40 +0100
shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-10 13:50 +0100
Re: shred bug? [was: Unidentified subject!] tomas@tuxteam.de - 2024-02-10 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 15:00 +0100
Re: shred bug? <tomas@tuxteam.de> - 2024-02-10 15:40 +0100
Re: shred bug? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-10 14:40 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 14:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 01:20 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-11 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 14:30 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 08:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 15:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 15:50 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] Curt <curty@free.fr> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-12 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 06:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:20 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 13:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 14:00 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-13 16:40 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 17:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-13 18:50 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-14 06:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 19:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 20:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:50 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 21:30 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 22:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-15 06:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:50 +0100
Re: shred bug? [was: Unidentified subject!] Max Nikulin <manikulin@gmail.com> - 2024-02-13 03:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Michael Stone <mstone@debian.org> - 2024-02-16 16:00 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 18:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 19:40 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 20:30 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:10 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 21:50 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:40 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 11:10 +0100
Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-11 11:30 +0100
Re: Fast Random Data Generation "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-11 13:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 07:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-12 17:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-13 18:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-12 22:30 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:20 +0100
Re: Unidentified subject! Jeffrey Walton <noloader@gmail.com> - 2024-02-11 16:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:00 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-10 15:40 +0100
Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 16:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 17:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 17:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Ralph Aichinger <ra@h5.or.at> - 2024-02-08 18:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-08 20:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 23:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 14:00 +0100
Re: Things I don't touch with a 3.048m barge pole "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-09 14:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-10 07:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage(WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-10 18:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Arno Lehmann <al@its-lehmann.de> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Max Nikulin <manikulin@gmail.com> - 2024-02-08 18:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-08 23:50 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-09 00:10 +0100
Re: Unidentified subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 00:50 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 05:50 +0100
Re: Unidentified flying subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 07:50 +0100
Re: Unidentified flying subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 14:20 +0100
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Date | 2024-02-08 23:10 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5kKJ-8Pj7-5@gated-at.bofh.it> |
| In reply to | #267163 |
On 2/8/24 16:28, Andy Smith wrote: > Hello, > > On Thu, Feb 08, 2024 at 04:22:49PM -0500, Gremlin wrote: >> On Thu, Feb 08, 2024 at 08:43:17PM +0000, Andy Smith wrote: >>> I really do mean all forms of USB that come over a USB port. >> >> That line was meant to read >> >> I really do mean all forms of storage that come over a USB port. >> >> Changing the goal post now are we..... > > Erm no, it was a simple mistaken repetition of the word "USB" that I > only noticed when I read it back. It would be clearly very difficult > to refuse to use any kind of USB device at all! I have been > consistently talking about storage devices. > > You have been very clear that you do not agree though, so let's just > agree to disagree. > > Thanks, > Andy > You back pedal really well don't you! Where did you learn that?
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Date | 2024-02-08 22:30 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5k81-8OQh-1@gated-at.bofh.it> |
| In reply to | #267162 |
On 2/8/24 16:16, Andy Smith wrote:
> On Thu, Feb 08, 2024 at 03:56:19PM -0500, Gremlin wrote:
>> On 2/8/24 15:43, Andy Smith wrote:
>>> I wouldn't have much issue with taking a USB drive out of its caddy
>>> to get the SATA drive from inside, except that it would have to be
>>> an amazingly good deal to make it worth voiding the warranty, so I
>>> generally wouldn't bother.
>>
>> Why would it void the warranty? I put it in the caddy
>
> I mean the USB drives that come as a sealed unit that you can
> sometimes find a lot cheaper than the same model SATA drive that is
> actually inside them. Some people do enjoy taking those apart to get
> the SATA drive out.
>
> Thanks,
> Andy
>
On Thu, Feb 08, 2024 at 08:43:17PM +0000, Andy Smith wrote:
> I really do mean all forms of USB that come over a USB port.
That line was meant to read
I really do mean all forms of storage that come over a USB port.
Thanks,
Andy
Changing the goal post now are we.....
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-09 14:00 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) |
| Message-ID | <I5yE1-8Xys-1@gated-at.bofh.it> |
| In reply to | #267158 |
On 2/8/24 15:43, Andy Smith wrote:
> Hello,
>
> On Thu, Feb 08, 2024 at 02:20:59PM -0500, Jeffrey Walton wrote:
>> On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger <ra@h5.or.at> wrote:
>>> How does a breaking USB disk differ from a breaking SATA disk?
>>
>> I may be mistaken, but I believe AS is talking about USB thumb drives,
>> SDcards and the like. I don't think he's talking about external SSD's
>> and NVME's over USB. But I don't want to put words in his mouth.
>
> I really do mean all forms of USB that come over a USB port.
>
> I wouldn't have much issue with taking a USB drive out of its caddy
> to get the SATA drive from inside, except that it would have to be
> an amazingly good deal to make it worth voiding the warranty, so I
> generally wouldn't bother.
>
> If I need directly attached storage I'd much rather explore options
> like SAS and eSATA, or even networked storage, before I would ever
> consider USB for a permanent installation.
>
> Thanks,
> Andy
>
OTOH. I have a couple sata-II SSD's, a kingston 256G and an adata 120G
plugged into the usb-3 ports of what was an rpi3b with usb2, rigged it
up first in 2016 IIRC, but swapped the rpi3b for an rpi4b in Feb 2020.
I can build linuxcnc from master in around an hour, and a 4.19.120 or so
kernal for the pi in a little less. And was doing that linuxcnc thing 4
to 8 times a week for several years but have stopped that with armhf
since it may be dropped in favor of arm64 which isn't as good for
latency, but is good enough to run linuxcnc w/o making the machine
stutter from lack of data.
I have had one failure, the adapter for the 120G adata, wasn't a
startech, is now for around 5 years. That's beats the performance of
spinning rust like a white mouthed mule. I'd had Spinning rust failures
have totaled around around a dozen in triple that time frame. I built my
first linux box with a 30G drive in 1998. 26 years ago. I've paid the
window tax once, buying a lappy in 2002 to run a road map gps thing as I
did a decade and change worth of consulting since I retired, but that
lappy got its windows replaced in 2 weeks by mandrake when I found the
windose xp install could not run the radio in it but mandrake could.
Long found the out bin, bad ac adapter. but I got most of a decade out
of it. Kept me company from the passengers seat for around 20k miles
though.
If these $23 drives pass the A. M. test, they will get mounted in
adapters I'll have to design and print, plugged into a 8 port usb3 hub,
plugged into a usb3 port of an bpi-m5, making a drive cage into a 12TB
with 6 of these I bought into an amanda backup server I may hide in the
bookshelves surrounding me. Headless, probably running it all on a 5v5a
psu. There is a 5v8a psu being rowed across the big pond just in case.
My scope watching the 5 volt line will determine the need.
If they pass the test. That is YTBD.
Interesting report from gdisk however:
GPT fdisk (gdisk) version 1.0.9
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Command (? for help):
Command (? for help): p
Disk /dev/sdm: 4096000000 sectors, 1.9 TiB
Model: SSD 3.0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 3230045D-589D-4601-8C4D-E9C4684B9657
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 4095999966
Partitions will be aligned on 64-sector boundaries
Total free space is 30 sectors (15.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 64 4095999999 1.9 TiB 0700 Microsoft
basic data
Command (? for help): q
What do we make of that? Some sort of NTFS?
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]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-09 14:50 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole |
| Message-ID | <I5zqp-8Y45-9@gated-at.bofh.it> |
| In reply to | #267182 |
Hi, gene heskett wrote: > GPT fdisk (gdisk) version 1.0.9 > > Partition table scan: > MBR: MBR only > [...] > Found invalid GPT and valid MBR; converting MBR to GPT format > in memory. > [...] > Warning! Secondary partition table overlaps the last partition by 33 blocks! > You will need to delete this partition or resize it in another utility. > [...] > Disk /dev/sdm: 4096000000 sectors, 1.9 TiB > Number Start (sector) End (sector) Size Code Name > 1 64 4095999999 1.9 TiB 0700 Microsoft basic data It wants to say "found no GPT at all and cannot easily convert the MBR partition table". > What do we make of that? Some sort of NTFS? NTFS would be a possible candidate for the filesystem inside the partition. What does this command report: file -s /dev/sdm1 But the complaint from gdisk is just about an MBR partitioned stick with no unclaimed room at the end for storing the GPT backup table. Indeed if you want to convert the MBR partition table to GPT you will have to delete or shrink the single partition number 1. (Shrinking would of course depend on what kind of filesystem is in the partition and whether Debian has shrink software for it.) The same will be necessary if you want more than one partition. Whatever, there is nothing suspicious about the gdisk behavior with that particular disk. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-10 07:00 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) |
| Message-ID | <I5Oz7-99k8-1@gated-at.bofh.it> |
| In reply to | #267182 |
On 2/9/24 04:53, gene heskett wrote: > Interesting report from gdisk however: > GPT fdisk (gdisk) version 1.0.9 > > Partition table scan: > MBR: MBR only > BSD: not present > APM: not present > GPT: not present > > > *************************************************************** > Found invalid GPT and valid MBR; converting MBR to GPT format > in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by > typing 'q' if you don't want to convert your MBR partitions > to GPT format! > *************************************************************** > > > Warning! Secondary partition table overlaps the last partition by > 33 blocks! > You will need to delete this partition or resize it in another utility. > > Command (? for help): > Command (? for help): p > Disk /dev/sdm: 4096000000 sectors, 1.9 TiB > Model: SSD 3.0 > Sector size (logical/physical): 512/512 bytes > Disk identifier (GUID): 3230045D-589D-4601-8C4D-E9C4684B9657 > 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 4095999966 > Partitions will be aligned on 64-sector boundaries > Total free space is 30 sectors (15.0 KiB) > > Number Start (sector) End (sector) Size Code Name > 1 64 4095999999 1.9 TiB 0700 Microsoft > basic data > > Command (? for help): q > > What do we make of that? Some sort of NTFS? Do these commands produce any clues or error messages? # fdisk -l /dev/sdm # tail /var/log/messages # dmesg | tail David
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-10 18:40 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage(WasRe: Unidentified subject!) |
| Message-ID | <I5Zuy-9fVv-1@gated-at.bofh.it> |
| In reply to | #267213 |
On 2/10/24 00:54, David Christensen wrote: > On 2/9/24 04:53, gene heskett wrote: >> Interesting report from gdisk however: >> GPT fdisk (gdisk) version 1.0.9 >> >> Partition table scan: >> MBR: MBR only >> BSD: not present >> APM: not present >> GPT: not present >> >> >> *************************************************************** >> Found invalid GPT and valid MBR; converting MBR to GPT format >> in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by >> typing 'q' if you don't want to convert your MBR partitions >> to GPT format! >> *************************************************************** >> >> >> Warning! Secondary partition table overlaps the last partition by >> 33 blocks! >> You will need to delete this partition or resize it in another utility. >> >> Command (? for help): >> Command (? for help): p >> Disk /dev/sdm: 4096000000 sectors, 1.9 TiB >> Model: SSD 3.0 >> Sector size (logical/physical): 512/512 bytes >> Disk identifier (GUID): 3230045D-589D-4601-8C4D-E9C4684B9657 >> 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 4095999966 >> Partitions will be aligned on 64-sector boundaries >> Total free space is 30 sectors (15.0 KiB) >> >> Number Start (sector) End (sector) Size Code Name >> 1 64 4095999999 1.9 TiB 0700 Microsoft >> basic data >> >> Command (? for help): q >> >> What do we make of that? Some sort of NTFS? > > > Do these commands produce any clues or error messages? > > # fdisk -l /dev/sdm > > # tail /var/log/messages > > # dmesg | tail > They suggested an exfat format ootb, which matches most sd cards. Thanks David, Take care. > > David > > . 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]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 21:40 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jlD-8OkJ-1@gated-at.bofh.it> |
| In reply to | #267143 |
Hello, On Thu, Feb 08, 2024 at 05:40:54PM +0100, Ralph Aichinger wrote: > On Thu, 2024-02-08 at 15:36 +0000, Andy Smith wrote: > > I learned not to go there a long time ago and have seen plenty of > > reminders along the way from others' misfortunes to not ever go > > there again myself. > > How does a breaking USB disk differ from a breaking SATA disk? In my experience it happens more often and also brings with it frequent issues of poor performance and other reliability issues like just dropping off the USB bus. There is almost always a better way. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Arno Lehmann <al@its-lehmann.de> |
|---|---|
| Date | 2024-02-09 09:50 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5uK5-8VfA-3@gated-at.bofh.it> |
| In reply to | #267154 |
Hi all, Am 08.02.2024 um 21:38 schrieb Andy Smith: > Hello, > > On Thu, Feb 08, 2024 at 05:40:54PM +0100, Ralph Aichinger wrote: >> On Thu, 2024-02-08 at 15:36 +0000, Andy Smith wrote: >>> I learned not to go there a long time ago and have seen plenty of >>> reminders along the way from others' misfortunes to not ever go >>> there again myself. >> >> How does a breaking USB disk differ from a breaking SATA disk? My own experience is that it's often harder to notice and diagnose -- because on top of the actual storage and its "native" interface such as SATA or NVMe/PCIe, you have the whole stack of USB things. And misbehaving USB devices usually result in first working on the USB end -- try different port, port directly on mainboard, or a powered hub, watch out for native USB 3 or 3.0 Gen 1 -- we can see this on this mailing list, too. Then, USB storage is usually a single device single, if it breaks, it's data is lost, whereas SATA/SAS/NVMe can more easily be integrated into redundancy providing systems. On top of all that, my own, admittedly anecdotal, experience is that USB/Firewire-to-IDE/SATA adapters and their power supplies are more fragile than actual disks. Most of the external hard disks I ever used have been replaced because of their enclosures or power supplies failing. So, I tend to agree with Andy, and I also don't notice any moving goalposts in his statements... > In my experience it happens more often and also brings with it > frequent issues of poor performance and other reliability issues > like just dropping off the USB bus. There is almost always a better > way. For home users / small office environments, that leaves the problem of how to do backups -- USB drives are the most appealing storage system for such purposes, but also seem to be less reliable than the primary storage. What do you do? Throw more of the USB disks onto the problem? Or is "public" cloud the solution? Whatever you do, even purely personal storage requirements become a bit of a nightmare when you start thinking about how to make sure your photos and videos are around when your kids are grown up... Cheers, Arno > Thanks, > Andy > -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-02-08 18:30 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5gnL-8MCa-1@gated-at.bofh.it> |
| In reply to | #267137 |
On 08/02/2024 22:36, Andy Smith wrote: > On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: >> [629241.074187] scsi host37: usb-storage 1-2:1.0 > > USB storage is for phones and cameras etc, not for serious > computing. Do you mean that a proper backup drive should use uas (USB Attached Storage) instead of usb-storage driver?
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 21:40 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jlE-8OkJ-17@gated-at.bofh.it> |
| In reply to | #267144 |
Hello, On Fri, Feb 09, 2024 at 12:23:45AM +0700, Max Nikulin wrote: > On 08/02/2024 22:36, Andy Smith wrote: > > On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: > > > [629241.074187] scsi host37: usb-storage 1-2:1.0 > > > > USB storage is for phones and cameras etc, not for serious > > computing. > > Do you mean that a proper backup drive should use uas (USB Attached Storage) > instead of usb-storage driver? No, I just mean I advise to never ever use storage that comes to you via a USB port for anything you care about. I might consider it okay for temporary shifting of data about, but I would never use it as part of a permanent setup without fully expecting one day to find it just not working. But then that is also how I feel about any storage device. It's just worse when USB is added to the mix. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Date | 2024-02-08 22:10 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jOF-8OK0-5@gated-at.bofh.it> |
| In reply to | #267156 |
On 2/8/24 15:35, Andy Smith wrote: > Hello, > > On Fri, Feb 09, 2024 at 12:23:45AM +0700, Max Nikulin wrote: >> On 08/02/2024 22:36, Andy Smith wrote: >>> On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: >>>> [629241.074187] scsi host37: usb-storage 1-2:1.0 >>> >>> USB storage is for phones and cameras etc, not for serious >>> computing. >> >> Do you mean that a proper backup drive should use uas (USB Attached Storage) >> instead of usb-storage driver? > > No, I just mean I advise to never ever use storage that comes to you > via a USB port for anything you care about. > > I might consider it okay for temporary shifting of data about, but I > would never use it as part of a permanent setup without fully > expecting one day to find it just not working. But then that is also > how I feel about any storage device. It's just worse when USB is > added to the mix. > I have been using USB attached HDDs and SSDs for 10 years now and have never had one unexpectedly go off line. Your postings suggest you don't know what your talking about.
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 22:20 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jYl-8ON5-1@gated-at.bofh.it> |
| In reply to | #267160 |
Hello, On Thu, Feb 08, 2024 at 04:00:01PM -0500, Gremlin wrote: > I have been using USB attached HDDs and SSDs for 10 years now and > have never had one unexpectedly go off line. Your postings > suggest you don't know what your talking about. Okay then. Despite this uncharitable comment, I do still wish you what I consider to be continued good fortune! Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Richmond <dnomhcir@gmx.com> |
|---|---|
| Date | 2024-02-08 23:50 +0100 |
| Message-ID | <I5lns-8Pw8-11@gated-at.bofh.it> |
| In reply to | #267123 |
gene heskett <gheskett@shentel.net> writes: > Well the 2T memory everybody was curious about 3 weeks ago got here early. > > From dmesg after plugging one in: > [629240.916163] usb 1-2: new high-speed USB device number 39 using xhci_hcd > [629241.066221] usb 1-2: New USB device found, idVendor=048d, > idProduct=1234, bcdDevice= 2.00 > [629241.066234] usb 1-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [629241.066239] usb 1-2: Product: Disk 3.0 > [629241.066242] usb 1-2: Manufacturer: USB > [629241.066246] usb 1-2: SerialNumber: 2697241127107725123 > [629241.069485] usb-storage 1-2:1.0: USB Mass Storage device detected > [629241.074187] scsi host37: usb-storage 1-2:1.0 > [629242.100738] scsi 37:0:0:0: Direct-Access SSD 3.0 > 2.00 PQ: 0 ANSI: 4 > [629242.100959] sd 37:0:0:0: Attached scsi generic sg13 type 0 > [629242.101190] sd 37:0:0:0: [sdm] 4096000000 512-byte logical blocks: > (2.10 TB/1.91 TiB) > [629242.101289] sd 37:0:0:0: [sdm] Write Protect is off > [629242.101290] sd 37:0:0:0: [sdm] Mode Sense: 03 00 00 00 > [629242.101409] sd 37:0:0:0: [sdm] No Caching mode page found > [629242.101410] sd 37:0:0:0: [sdm] Assuming drive cache: write through > [629242.103927] sdm: sdm1 > [629242.104047] sd 37:0:0:0: [sdm] Attached SCSI disk > gene@coyote: > > Looks like a reasonable facsimile of a 2T disk to me. > > Cheers, Gene Heskett, CET. Test it with Validrive. https://www.grc.com/validrive.htm
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-02-09 00:10 +0100 |
| Message-ID | <I5lGN-8PUQ-7@gated-at.bofh.it> |
| In reply to | #267166 |
> Test it with Validrive.
> https://www.grc.com/validrive.htm
Looks like proprietary software for Windows.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2024-02-09 00:50 +0100 |
| Message-ID | <I5mjv-8Q76-1@gated-at.bofh.it> |
| In reply to | #267167 |
On Thu, 08 Feb 2024 18:02:36 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > Test it with Validrive. > > https://www.grc.com/validrive.htm > > Looks like proprietary software for Windows. badblocks, available in a Debian repo near you, might be a suitable replacement. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | Richmond <dnomhcir@gmx.com> |
|---|---|
| Date | 2024-02-09 05:50 +0100 |
| Message-ID | <I5qZP-8SY9-3@gated-at.bofh.it> |
| In reply to | #267168 |
Charles Curley <charlescurley@charlescurley.com> writes: > On Thu, 08 Feb 2024 18:02:36 -0500 > Stefan Monnier <monnier@iro.umontreal.ca> wrote: > >> > Test it with Validrive. >> > https://www.grc.com/validrive.htm >> >> Looks like proprietary software for Windows. > > badblocks, available in a Debian repo near you, might be a suitable > replacement. I am not sure badblocks would do the same thing. "The drive appears to be the 1 or 2 terabyte drive you purchased. You plug it into your computer and everything looks fine. You can even copy files to the drive; as many as you want. And when you look at the drive's contents the files are there. But what's insidious is that the files' contents may have never been stored. " So you need to store a lot of data and then verify that it has written with 'diff'.
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2024-02-09 07:50 +0100 |
| Subject | Re: Unidentified flying subject! |
| Message-ID | <I5sRX-8Uad-1@gated-at.bofh.it> |
| In reply to | #267171 |
On Fri, 09 Feb 2024 04:30:14 +0000 Richmond <dnomhcir@gmx.com> wrote: > So you need to store a lot of data and then verify that it has written > with 'diff'. Yeah. I've been thinking about this. Yeah, I know: dangerous. What I would do is write a function to write 4096 bytes of repeating data, the data being the block number being written to. So the first block is all zeros, the second all ones, etc.. For convenience they would be 64 bit unsigned ints. And, given the block number, a function to verify that block number N is full of Ns and nothing else. By doing it this way, we don't have to keep copies of what we've written. We only have to keep track of which block got written to which LBA so we can go back and check it later. Now, divide the drive in half. Write block zero there. Divide the two halves each in half, and write blocks one and two. Divide again, and write blocks three through five. Etc., a nice binary division. Every once in a while, I would go back and verify the blocks already written. Maybe every time I subdivide again. If we're really lucky, and the perpetrators really stupid, the 0th block will fail, and we have instant proof that the drive is a failure. We don't care why the drive is failing, only that the 0th block (which is clearly not at the end of the drive) has failed. Here's a conjecture: This was designed to get people who use FAT and NTFS. I know that FAT starts writing at the beginning of the partition, and goes from there. This is because floppy disks (remember them?) have track 0 at the outside, which is far more reliable than the tracks at the hub simply because each each flux reversal is longer. So the first 64G should be fine; only after you get past there do you see bad sectors. I believe NTFS does similarly. But I don't think that's what they're doing. Other operating systems have put the root directory and file allocation table (or equivalent) in the middle of the disk (for faster access), Apple DOS for one. mkfs.extX write blocks all over the place. I think that they are re-allocating sectors on the fly, regardless of the LBA, until they run out of real sectors. So we write 64G+ of my 4096 byte blocks. It'll take a while, but who cares? If Gibson is correct that these things only have 64 gig of real memory, and my arithmetic is correct, we should start seeing failures after writing 16777216 of my 4096 blocks. Of course, these things might allocate larger sectors than 4096 bytes. In which case we'll hit the limit sooner. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | Richmond <dnomhcir@gmx.com> |
|---|---|
| Date | 2024-02-09 14:20 +0100 |
| Subject | Re: Unidentified flying subject! |
| Message-ID | <I5yXn-8XUn-1@gated-at.bofh.it> |
| In reply to | #267173 |
Charles Curley <charlescurley@charlescurley.com> writes: > On Fri, 09 Feb 2024 04:30:14 +0000 > Richmond <dnomhcir@gmx.com> wrote: > >> So you need to store a lot of data and then verify that it has written >> with 'diff'. > > Yeah. > > I've been thinking about this. Yeah, I know: dangerous. > > What I would do is write a function to write 4096 bytes of repeating > data, the data being the block number being written to. So the first > block is all zeros, the second all ones, etc.. For convenience they > would be 64 bit unsigned ints. > > And, given the block number, a function to verify that block number N > is full of Ns and nothing else. > > By doing it this way, we don't have to keep copies of what we've > written. We only have to keep track of which block got written to which > LBA so we can go back and check it later. > > Now, divide the drive in half. Write block zero there. Divide the two > halves each in half, and write blocks one and two. Divide again, and > write blocks three through five. Etc., a nice binary division. > > Every once in a while, I would go back and verify the blocks already > written. Maybe every time I subdivide again. > > If we're really lucky, and the perpetrators really stupid, the 0th block > will fail, and we have instant proof that the drive is a failure. > We don't care why the drive is failing, only that the 0th block (which > is clearly not at the end of the drive) has failed. > > Here's a conjecture: This was designed to get people who use FAT and > NTFS. I know that FAT starts writing at the beginning of the partition, > and goes from there. This is because floppy disks (remember them?) have > track 0 at the outside, which is far more reliable than the tracks at > the hub simply because each each flux reversal is longer. So the first > 64G should be fine; only after you get past there do you see bad > sectors. I believe NTFS does similarly. > > But I don't think that's what they're doing. Other operating systems > have put the root directory and file allocation table (or equivalent) > in the middle of the disk (for faster access), Apple DOS for one. > mkfs.extX write blocks all over the place. > > I think that they are re-allocating sectors on the fly, regardless of > the LBA, until they run out of real sectors. So we write 64G+ of my > 4096 byte blocks. It'll take a while, but who cares? > > If Gibson is correct that these things only have 64 gig of real memory, > and my arithmetic is correct, we should start seeing failures after > writing 16777216 of my 4096 blocks. > > Of course, these things might allocate larger sectors than 4096 bytes. > In which case we'll hit the limit sooner. I tried validrive on a 64G drive and it was very fast to run. Another older drive with 32G was much slower. This is due to the design of drives expecting to be written to sequentially. Note this in the FAQ: "Q:How much of the storage of a drive does ValiDrive test? "A:ValiDrive's drive map contains 32 x 16 squares. So it tests 576 evenly-spaced 4k byte regions of any drive for a total of 2,359,296 bytes, or about 2.36 megabytes. If a drive contains internal RAM caching, ValiDrive will detect that and may increase its testing region size, as necessary, to bypass such caching; but this is not commonly encountered. " This would be considerably quicker than your 64G write, and also cause less wear. But you need a friend with Windows to run it. :)
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | linux.debian.user
csiph-web